[I already posted this on Friday, but it never appered in the archive.
I did not get a copy myself, nor a reply, so I assume it got lost.]
Hi,
I've had this problem that my ISP's POP3 server kept timing out on
fetchmail while it was waiting for an SMTP response. (Fetchmail only
noticed when the SMTP response finally came.)
I had configured my exim, as one anti-spam measure, to call back on
the envelope sender to make sure it exists. (Exim then behaves like
it wanted to send a bounce email to it, but if MAIL FROM:<> and RCPT
TO:<envelope-sender-of-incoming-email> are OKed, it QUITs instead of
sending DATA.)
It all worked fine until I got a particular email (no spam!) from a
particular sender domain, which had several higher priority MX entries
with no servers listing, and only a lower priority MX actually
working. By the time the callback attempt got to the working MX, the
POP server had timed out. This was reproducible, so the message
blocked my queue.
Sure, I temporarily decreased the timeout in exim to get the message
off the queue, but that is not actually what I want.
In my case, SMTP took longer on the MAIL FROM:, but I could also
imagine some SMTP servers needing time on RCPT TO: (mailing list
expansion) or the DATA's final dot (virus scanning, onward delivery).
Wouldn't it be useful if fetchmail could send regular NOOP commands to
the incoming server to keep it alive while it was waiting for an SMTP
reply? Maybe with a new option 'keepalivetimeout'? What do you think?
My first idea was you could do that in a plugin, but to do it
correctly, a plugin would need to interpret both sides of the
protocol, while fetchmail itself already knows what it is doing.
Regards,
Marco