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 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....
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
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