I'm having a strange problem with sender callouts with some slow
mailservers. Exim version 4.20.
verify = sender/callout=10s,defer_ok,random
There are some mail servers out there that respond to failed RCPT
TO commands slowly (and probably intentionally, to slow down
dictionary attacks, as it's not nearly that slow with GOOD addresses).
I'm running into the problem that the callout conversation goes
like this (debugging callouts with Exim is nearly impossible; this
was extracted from tcpdump):
Other MTA: 220 mail.othermta.com
My Exim: HELO mail.mydomain.com
Other MTA: 250 othermta.com
My Exim: MAIL FROM:<>
Other MTA: 250 ok
My Exim: RCPT TO:<mail.mydomain.com-84398439@???>
(10 second pause)
My Exim: <10 seconds has passed - TIMEOUT>
My Exim: RSET
(3 second pause)
Other MTA: 551 not our customer
Other MTA: 250 ok
I would expect the timeout on response to RCPT to to cause a defer.
Since I am using defer_ok, the mail should be accepted.
Instead, Exim doesn't seem to notice the error, and continues with
the RSET, out of sync in the conversation. It then takes the reply
to RCPT TO as the reply to RSET, and bounces the mail.
Am I correct in interpreting the way it SHOULD work?
Yes, I can increase the timeout. 40s still doesn't remove all the
issues, although the major ISPs with this issue seem to be handled
properly with this. If I go much higher with the timeouts, the calling
MTA is going to time out waiting for my server to give a response,
and retry.
Any ideas? I haven't gotten into the code enough to find where the
timeout error is getting ignored. Any good workarounds, preferably
besides turning off random?
Gordon L. Burditt
