spf-discuss
[Top] [All Lists]

Re: Re: SPF implementations

2005-08-16 15:39:40
On Tue, 16 Aug 2005, Dennis Willson wrote:

Actually it DID have a PASS. The <return-path> had a domain with a valid SPF
record in it which PASSED. The From address was PayPal.com so the user sees
the PayPal.com in their email clients from address but they don't see the
<return-path> in their mail client.

Right there is the problem.  They don't see Return-Path in their mail client.
They don't see PRA in their mail client either.

As an end user, you are probably frustrated, and wondering why us
email authentication gurus can't authenticate something your email
client actually shows you (like From:).

The answer is what is efficient and won't break things.

The most efficient and simple thing to check is the HELO name - the
public name of the SMTP client.

RFC2821 compliant mail specifies a HELO name that is authenticated by checking
that looking up the name returns an IP that matches the connection.
Nothing ought to break by insisting on a valid HELO name.  However,
for years, nobody ever enforced this, so now a good percentage of
email has a bogus HELO name, and rejecting on bogus HELO will
reject otherwise valid mail.  Also, your email client doesn't bother
to show you the HELO name.

The next most efficient and simple thing is CSA (part of CSV) - look for SRV
records that explicitly block or allow HELO names.  This gives you
"pass" and "fail" for domains that opt-in and "neutral" for others.
All very fine, but your MUA won't show you the HELO name.

The next level is SPF, which validates the MAIL FROM.  This is more complex
than CSA or the RFC, but still is evalatued before wasting time and
bandwidth on any actual data for the message.  Your MUA really *ought*
to show you MAIL FROM (Return-Path), and it probably actually does
as some secret menu option somewhere.  Nevertheless, most naive end users
will never see it.

All the things you might want to authenticate beyond MAIL FROM belong
to RFC2822, and all methods will have to download and parse the entire
message before proceding.  This is because SMTP doesn't allow you
to abort a message once the DATA phase has started.  (You
could just drop the connection, but the sender will treat it as an
I/O error and keep trying.)  Furthermore, any RFC2822 authentication 
method not based on connect IP will probably want to create some kind of hash
of the entire message to prevent header replay attachs (reuse authenticated
headers with body replaced by spam).  Body hashes cause problems at
least at severe as the SPF forwarding problem.  Microsoft is pushing
Sender-ID, which authenticates something called the PRA - which is 
supposed to be less troubled by forwarding problems than using the
straight From header.  (Many disagree.) Your MUA doesn't show you the
PRA either - although one hopes that Microsoft clients will show it
soon.

So you see, there is a big leap in complexity and fragility when we
go beyond rfc2821 authentication and tackle rfc2822.  It is a
historical accident that MUAs no longer display Return-Path (MAIL FROM) -
early MUAs did.  Obtaining or patching an MUA that does display
Reuturn-Path is really the best solution - but this is of course difficult to
explain to end users.  It would be nice if the MUA also displayed the HELO
name and whether it is valid according to RFC2821 and/or CSA.

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