On Tue, 6 Sep 2005, paddy wrote:
PTR (reverse DNS) should not be used for email authentication because
it is not under the control of the domain owner.
How is it any more or less under the control of the domain owner than
the A record ?
Because I as a domain owner have ABSOLUTELY NO ACCESS to the PTR records
for my IP addresses. I am a domain owner, not an IP address owner. I am
completely at the mercy of the competence and attention (or lack
thereof) of my ISP. Broadband ISPs are a (rant deleted) monopoly in most
areas, and so switching ISPs is not an option. This is true even
for "business" accounts.
I have boxes with PTR records set (what I hope is) correctly.
Wasn't hard to do. Certainly felt as much like being in control as
having a DNS domain does ...
It is very easy to do IF your ISP happens to delegate them to your
domain. For instance, AT&T knows how to do this. Other ISPs
either can't or won't.
Validating EHLO FQDN does not use PTR records.
I'm not sure that validating in 2821 terms is anything more than a
syntax check, but I assume you mean:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
depends on your interpretation.
See my other posts here.
Go and look at implementations.
I'm interested to hear arguments that it _shouldn't_
The SMTP server domain owner can directly provide A records.
Lookup the A records for the EHLO FQDN, and verify that the
the set includes the connect IP. Why would you look up the PTR record
for the IP when you already have the name from EHLO! All you have
to do is validate it. You wouldn't use the PTR records without
validating them - you need to lookup the A record for the PTR name
to check that is matches or the PTR name is worthless. Well, you already have
the name from EHLO, and can validate it. Why look it up again in PTR?
Especially since most SMTP servers that don't own an entire class C IP block
can't do anything about PTR records. Spammers are much more likely to own an
entire class C than legitimate senders (and I have quite
a few spammer class C blocks in my IP blacklist).
It simply looks up
the A record for the FQDN (standard name to IP lookup) and checks
that one of the IP addresses for that name is indeed the client IP.
a useful check in itself, albeit at the cost of a dns lookup.
A spammer with a class C (or a competent spammer friendly ISP) can publish any
PTR name he wants for an IP, and use an EHLO to match. Matching the PTR name
against EHLO accomplishing NOTHING is the way of validation.
Suppose SpamsRUs owns the 10.1.2.0 block. He simply sets:
1.2.1.10.in-addr.arpa. IN PTR mail.trustedbank.com.
then connects from 10.1.2.1 and uses
EHLO mail.trustedbank.com.
You have not validated mail.trustedbank.com UNLESS you look up its
A records. If you do that, you might find:
mail.trustedbank.com IN A 10.100.2.3
which does not match 10.1.2.1 - showing that the EHLO is a forgery.
A very, very simple requirement. There really is no excuse not
to meet it. The multi-home example is not a problem because you
can either use a distinct name for each interface, or use one name
for all interfaces.
That's certainly the way it seems to me.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com