----- Original Message -----
From: "Paul Howarth" <paul(_at_)city-fan(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, July 20, 2004 12:18 PM
Subject: *****SPAM***** Re: [spf-discuss] Re: SPF is not usable as legal
measure against spammers.
Nico Kadel-Garcia wrote:
Sorry, I have repeatedly explained elsewhere that the PTR records cannot
be
relied on to match the A record. It's a common and recommended practice
to
do so, but it's hardly mandatory nor should it be.
And as stated by others, and which I can affirm: the check for a PTR in
most
MTA's is merely a check that a PTR exists to avoid random email forgery
from
unmanaged networks which are often used by viruses and spammers, not a
check
against the A record, the published name in the "FROM" line of the SMTP
transaction, or anything else.
I know you've repeatedly said this, but the fact remains that a PTR record
is
completely untrustable for the purposes of the SPF "ptr" mechanism unless
the
name it points to has an A record with the original IP address. Domains
that
cannot manage to have forward-confirmed reverse DNS should simply not use
the
"ptr" mechanism.
Note that section 4.5 of the current spec.
(http://spf.pobox.com/draft-ietf-marid-protocol-00.txt) explicitly
requires
that this check is done, as does section 4.6 of the "classic SPF" spec.
(http://spf.pobox.com/spf-draft-200406.txt).
If any implementation of SPF does not do the forward check, I would like
to
know, so that I can avoid it (as it's non-compliant with the spec.).
OK, here's the spec in the new proposal:
[ From http://spf.pobox.com/draft-ietf-marid-protocol-00.txt ]
=== start quote ===
4.5 "ptr"
This mechanism tests if <ip>'s name is within a particular domain.
PTR = "ptr" [ ":" domain-spec ]
First the <ip>'s name is looked up using this procedure: perform a
PTR lookup against <ip>. For each record returned, validate the host
name by looking up its IP address. If <ip> is among the returned IP
addresses, then that host name is validated. In pseudocode:
sending-host_names := ptr_lookup(sending-host_IP);
for each name in (sending-host_names) {
IP_addresses := a_lookup(name);
if the sending-host_IP is one of the IP_addresses {
validated_sending-host_names += name;
} }
Check all validated hostnames to see if they end in the <target-name>
domain. If any do, this mechanism matches. If no validated hostname
can be found, or if none of the validated hostnames
=== end quote ===
OK, looks programatically stable. We actually do a single loop of PTR->
hostnames -> IP addresses and get the IP of the PTR. Good stuff, no
recursion (the bane of my existence in some programs!), and it all works
out. If they haven't got the PTR matching the ISP, great. We can use this
way, and it's reasonable.
Now, unfortunately, try this. I publish multiple PTR's for an IP address.
1.1.168.192.in-addr.arpa. PTR mx.spammerdomain.com.
1.1.168.192.in-addr.arpa. PTR spammer-faked.mx.aol.com.
I pretend, in the "FROM" line, to be spammer-faked.mx.aol.com, and my IP
address is 192.168.1.1.
I do a PTR lookup, and get "mx.spammerdomain.com" and
"spammer-faked.mx.aol.com".
I do an A record lookup of "spammer-faked.mx.aol.com", and that fails
miserably. So far, so good.
I also do an A record lookup of "mx.spammerdomain.com", and voila! It
matches a valid IP address. ***This is where many MTA's stop, because it's
too damned much work to do the extra testing and because it's unreliable in
and of itself as a validity test.*** However, this is SPF and we consider
this important as do the managers, and we've got a well-defined "domain" to
check against, and the owners of the domain promised that it meant something
by publishing the "ptr" SPF record, so we do a suffix comparison and then
drop "mx.spammerdomain.com".
All well and good, and it does precisely what you described. It's an SPF
specific usage: it's not a general requirement of DNS, and I really consider
it important that people be clear on that.