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.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
