[Mimedefang] Potential for Business mail servers to not havereverse DNS

[John Rudd]

Kevin A. McGrail wrote:
>
> The consensus, IMO at least but largely driven by AOL's policy, has 
> been that a reverse ptr that isn't blank and others as suspect is not 
> a completely bad idea. Here is AOL's full policy.  The emphasis is mine.
>
>  a.. AOL does *require* that all connecting Mail Transfer Agents have 
> established reverse DNS, regardless of whether it matches the domain.
>  b.. Reverse DNS must be in the form of a fully-qualified domain name. 
> Reverse DNS containing in-addr.arpa are not acceptable, as these are 
> merely placeholders for a valid PTR record. Reverse DNS consisting of 
> IP addresses are also not acceptable, as they do not correctly 
> establish the relationship between domain and IP address. 
It's not just AOL policy, it's a strict interpretation of RFC 1912, 
section 2.1:

#   2.1 Inconsistent, Missing, or Bad Data
#
#   Every Internet-reachable host should have a name.  The consequences
#   of this are becoming more and more obvious.  Many services available
#   on the Internet will not talk to you if you aren't correctly
#   registered in the DNS.
#
#   Make sure your PTR and A records match.  For every IP address, there
#   should be a matching PTR record in the in-addr.arpa domain.  If a
#   host is multi-homed, (more than one IP address) make sure that all IP
#   addresses have a corresponding PTR record (not just the first one).
#   Failure to have matching PTR and A records can cause loss of Internet
#   services similar to not being registered in the DNS at all.  Also,
#   PTR records must point back to a valid A record, not a alias defined
#   by a CNAME.  It is highly recommended that you use some software
#   which automates this checking, or generate your DNS data from a
#   database which automatically creates consistent data.


So:

1) every host on the internet should have a name
2) every IP address should have a PTR record
3) PTR records must point to a valid A record, and not a CNAME record
4) it's a good idea for the A record to match the PTR record (resolve 
back to the IP addr)

By "strict interpretation", I mean "enforce all of these as MUST 
directives, instead of mere SHOULD directives/suggestions".

My mimedefang-filter enforces these in filter_sender, along with 
something like the "c" requirement from AOL's policy (about names that 
look dynamic).  And I interpret #1 as meaning "must have a name which is 
listed in DNS" (in otherwords, it must be the key for an A or CNAME 
record).  This translates into:

Every system which wishes to deliver email to me must have:

* A PTR record for its IP address ("the connecting IP address").  
Failure leads to a temporary rejection of the message.
* The PTR record must resolve to a name which is they key for an A 
record.  Failure leads to a temporary rejection of the message.
* The A record must have at least 1 IP address which matches the 
connecting IP address.  Failure leads to a permanent failure of the message.
* The name from the PTR record must not look dynamic.  Failure is a 
permanent rejection of the message.
* The above restrictions can be avoided via SMTP-AUTH.


I have yet to find out that any such rejection was a valid email message.