Rob wrote:
You're right, then. If I explicitly block inbound connections to the outbound mail server (instead of redirecting them), that might fix the problem ... depending on just what kind of check the recipient's mail server is doing.
A sending MTA is not required to accept SMTP connections, only those listed with DNS MX records should do so. I guess the superfluous redirect is causing the trouble. The outbound server must TCP block inbound connections with pf or the OS, do not use the MTA to 55x reject the connection.
Slightly off topic; but as you know, sender verification schemes work by looking up the sender's domain's MX records and attempting to "send" a mail to that sender. Should not matter which IP the mail is coming from. Compare gmail's vast array of outbound MTA ip address blocks, they are not listed in the MX records.
I'm a little concerned about just blocking those connections per your suggestion, though.
Sounds like the right thing to do to me.
It might end up just changing the affected recipients; if someone's dumb enough not to correctly check for an open relay, someone else is certainly dumb enough to reject mail if they can't connect back to the inbound IP.
But you said that they are connecting to the outbound IP and that you are redirecting them to the inbound IP, so this is not an issue if you reject the connection instead of redirecting it.
Best you can do is give it a go and send them a mail while watching the logs! Its only mail, not as if gold bullion is getting lost.....
