I quote the entire context of my original query and Sunil's reply, as it's
been a while.
The original problem has been fixed, but is replaced with a new (less
serious) one.
On Tue, 23 Dec 2003, Sunil Shetye wrote:
Quoting from Michael Abbott's mail on Tue, Dec 16, 2003 at 09:29:27AM +0000:
Here's an interesting fetchmail problem that blocked my fetchmail
processing for several days. Alas, once again fetchmail is stuck on a
dodgy incoming mail.
For what it's worth, I include the output of `fetchmail -v -v`, but I
think I know where it is failing.
After reading one (clearly spam) message from
undxf703rz(_at_)microbitnet(_dot_)com,
fetchmail tries to hand this on to my local sendmail. Attempting (and
failing) to resolve microbitnet.com takes one minute, by which time it
seems my ISP has become bored. At least, that's how I interpret these
lines:
Try reducing the value of timeout. The default of 300 is too high for
you. Something like:
poll server
timeout 55
You will have to experiment with the option to get the ideal timeout.
If you set it high, you will still have the same problem. If you set
it low, there will be disconnections from your side! On using the
ideal timeout, fetchmail will get bored just before your ISP!
So I have implement this suggestion, and it works... with an odd side
effect. The offending message is never retrieved from the POP3 server.
Here are the relevant lines from running `fetchmail -d0 -vv`:
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<natasha_h(_at_)needtodateaperson(_dot_)com>
SIZE=2225
fetchmail:
.fetchmail: not flushed
fetchmail: POP3> QUIT
I'm presuming the "smtp listener protocol error" is a consequence of the
timeout setting.
Unfortunately, fetchmail will *never* succeed in trying to unload this
particular message, so it hangs around for ever. Fortunately there only
seems to be one of them at the moment, but I think it has been in my POP
inbox for quite a long time now.
This strikes me as incorrect behaviour: fetchmail should either 1. drop
this message on the ground (is there a setting to enable this behaviour?);
or 2. forward it as an attachment to the configured postmaster (I can cope
with that).
So: another message to manually retrieve and discard. I'll leave it in
the system for a bit in case anyone can suggest a relevant configuration
change.