Today I run across a MTA which refused to accept mail because it could not detect an MX record for the reverse mapping of the IP address of the server which tried to deliver mail. Is this correct? Or: if A is the IP Address of server trying to deliver mail, does mx(reverse(A)) have to exist? -- Arnold
* arnold@nipper.de (Arnold Nipper) [Mon 05 Apr 2004, 23:04 CEST]:
Today I run across a MTA which refused to accept mail because it could not detect an MX record for the reverse mapping of the IP address of the server which tried to deliver mail. Is this correct?
Any mail server operator is of course free to implement such a policy, but no RFC exists to back it up. MX records aren't needed to send mail; an A record is enough. -- Niels. -- Today's subliminal thought is:
On Mon, 05 Apr 2004 23:03:05 +0200, Arnold Nipper <arnold@nipper.de> said:
Today I run across a MTA which refused to accept mail because it could not detect an MX record for the reverse mapping of the IP address of the server which tried to deliver mail. Is this correct?
Depends on your definition of "correct". Checking that there's a PTR and A record that match has become common, although not strictly standard. Checking that said PTR points to a hostname that has an MX is certainly "way out there".
Or: if A is the IP Address of server trying to deliver mail, does mx(reverse(A)) have to exist?
There's no RFC requirement that an MX exist at all (only that you check for an MX before using the A record). The last 2 AOL boxes I got mail from were omr-m07.mx.aol.com and rly-ye05.mail.aol.com. I'm not seeing an MX for either of those. Draw your own conclusions as to whether a Randy Bush quote is needed....
On Mon, 5 Apr 2004, Arnold Nipper wrote:
Today I run across a MTA which refused to accept mail because it could not detect an MX record for the reverse mapping of the IP address of the server which tried to deliver mail. Is this correct?
Not if you want to get mail, no. :)
Or: if A is the IP Address of server trying to deliver mail, does mx(reverse(A)) have to exist?
This is yet another misguided effort to semi-telepathically tell if a sender is "suspicious". Personally, I see nothing odd about a largish operation having one set of servers accepting mail and another set exclusively acting as smtp relays for customer mail. People that choose to do the "does it have an mx check" are hopefully blocking some really large amount of legit mail with the spam, as I can think of dozens of reasons why someone might wish to have their inbound mxers seperate from their outbound relays... Charles
-- Arnold
Charles Sprickman wrote:
This is yet another misguided effort to semi-telepathically tell if a sender is "suspicious". Personally, I see nothing odd about a largish operation having one set of servers accepting mail and another set exclusively acting as smtp relays for customer mail. People that choose to do the "does it have an mx check" are hopefully blocking some really large amount of legit mail with the spam, as I can think of dozens of reasons why someone might wish to have their inbound mxers seperate from their outbound relays...
A simple one would be that my outbound relays have queue and retry schedules different to my inbound SMTP listeners, which may more simply be configured for checking for SPAM etc. Also SMTP authentication for customers relaying may only be enabled on my outbound relays. Peter
participants (5)
-
Arnold Nipper -
Charles Sprickman -
Niels Bakker -
Peter Galbavy -
Valdis.Kletnieks＠vt.edu