This is one of Exim's more cryptic errors:
Mar 29 11:22:52 114075-web1 postfix/smtp[20589]: 9E0142FC589: to=
When you send e-mail to an Exim server with a sender verify callout enabled, the Exim server will connect back into your server and verify that your server accepts mail for the sender's e-mail address. For example, if you send e-mail from orders@somehost.com, the Exim server will connect back into your server and do this:
HELO someotherhost.com
250 somehost.com
MAIL FROM: test@someotherhost.com
250 2.1.0 Ok
RCPT TO: orders@somehost.com
250 2.1.5 Ok
Exim will make sure that it gets a 250 success code before it will allow the e-mail to come into its server. Some situations that cause problems with this process are:
- Port 25 is blocked inbound on the sender's server
- Something else is filtering port 25 inbound on the sender's server
- The sender's server uses blacklists which delay the responses to Exim's commands
The most obvoius problem is missing:
If the sender is using sender callout verify himself, the verify will never succeed as the verification targat wants a verification from the verifier first.
Besides it can be used conveniently for DOS attacks.
This is why sender callout verification should NEVER be enabled (and not even offered by EXIM)!
This is what's going on in our case
I sent an email from mike@my.dom to my_distro_list@myother.dom
One of the recipients on the my_distro_list has a server which apparently performs this "sender verify callout" which is another name for a callback, that is a reverse check to make sure the sending server -ALSO- accepts email for the original sender (i.e., mike@my.dom).
The "fix" was to make the outgoing server for myother.dom act as backup MX for my.dom
That way, when the recipient server gets the email I sent to my_distro_list, it can verify that the sending server for myother.dom also accepts email for my.dom
Presumably this check/verify helps thwart spammers, but not clear how -- if some stupid server acts as an open relay then it acts as an open relay and in so doing answers affirmative, that it does accept email for whatever initial sender domain(s).
So this whole business seems right now like a giant waste of time and it probably is, as others have asserted, a mechanism for DoS, as someone could basically make a server performing these silly "sender verify callouts" do extraneous work along with whatever unwitting target server(s) respond to those callouts.
Another problem that is missing is if the sending mail server is not set up to receive emails to the domain in the from address. I send mail from my own mail server but let Google Apps handle the incoming mail, so anybody who's mail server has this enabled can't receive mail from me.