Matthias Andree wrote:
(demoting to serious, tagging upstream, retitling)
Additional info:
fetchmail 6.3.4 and older do NOT log out of the upstream server after
SIGPIPE (I don't know the rationale behind this - it's not in the
comments), which prevents the deletions from happening properly.
Retitling the bug accordingly.
Thank you for the response. I got around the problem temporarily by
reconfiguring exim to accept many more malformed adresses
in a session before hanging up. (I now allow 100 instead of the
default 3).
I agree that "grave" was exaggregating, given that it was solveable
with a config change. I was a bit desperate at the moment, worrying that
I might be unable to download email at all for some time.
There is no need to provide a special package just for me, as I
worked around it by relaxing exim. Please use the time to
work on a fix instead. My suggestion is to have fetchmail disconnect in
an orderly way, so that the messages actually downloaded are deleted.
This would solve the problem - I would get first 115 messages, then
a hangup. After 10min, I'd get some more messages until exim trips up,
and after a few more rounds I'd get all my mail.
Thanks for all the tips on workarounds and configuration, there is
clearly a lot I could do to avoid downloading that spam in the first place.
Still, rejecting on TO address is tricky, mailing list mail is usually not
addressed to me.
Helge Hafting
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
