spf-discuss
[Top] [All Lists]

RE: [spf-discuss] The problems with SPF

2005-08-29 12:03:51
From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: Monday, August 29, 2005 9:27 AM

<...>

By contrast, as I understand SES, it requires receivers to do work
for senders to gain any benefit,

Not exactly.  Senders benefit by gaining the ability to reject forged
bounces with no action by anyone else.  The work done by the recipient to
give the sender protection against domain forgery is a small increment to
what an SPF-checking recipient already does.  In the typical case, this only
happens when no other SPF mechanism matches.  Depending on the particular
way it is set up, it is either an exists: macro or a modifier that the
recipient evaluates as part of their SPF record.  Either way, the work by
the recipient is similar:  one DNS A record request to get the validation
server IP, one DNS A record request per the exists: macro (or one UDP
validation request packet sent) followed by evaluating the DNS response (or
UDP reply).  As a SPF-checking recipient, you have a choice to manually
whitelist non-SRS forwarders or implement SES (or something similar).
Implementing SES is a lot easier than whitelisting.  The form of
whitelisting that does you the most good is per user, and that is also the
hardest to maintain.


and it requires senders to do work
for receivers to benefit.  This is a major hurdle to getting SES
deployed.

I don't agree with your conclusion at all.  Signing a return-path with SES
is a similar amount of work to rewriting a return-path with SRS.  If you
don't mind the latter, what's the problem with the former?  The signature
consists of an HMAC-SHA1 plus a SHA-1 body hash.  The signature plus
answering a validation request is a small amount of work compared to
creating a RSA signature for DK/DKIM.  If this amount of work by the sender
is a major adoption hurdle, DK/DKIM ought to be DOA by the same standard.



SPF has the same problem but to a far lesser degree.  The work
required from senders (publishing an SPF record) is very small, so
they aren't being asked to do much for little immediate gain.  Even
so, only a small percentage of domains publish SPF records.

Yes, the issue of where does the workload belong to validate an address is
important.  Right now, the load is 100% on the recipient, who has to use a
combination of DNSBL's, local policy (i.e. EHLO requirement, FCrDNS, A ==
connect IP, etc.) and content analysis (SpamAssassin).  The last step,
content analysis, is particularly expensive.  Is this fair?  No, but
considering the alternative, it is necessary.  Since most email is
unsolicited junk that should be rejected, it is reasonable to expect senders
of legitimate mail to do some work to help recipients validate mail from
them.  All signature schemes and sender policy schemes require both sender
and recipient to do some work with the expectation that the recipient's
total load will be somewhat reduced.  When used as an extension to SPF, SES
allows a non-SRS forwarded message (most of them, today) to generate a SPF
pass rather than a softfail or fail.  Getting the SPF pass results in less
work for both sender and recipient than a bounce due to forwarding.

SES allows SPF to work as intended whether of not the forwarders implement
SRS.  I view the adoption hurdles differently than you have stated.  Most
forwarders, to date, have resisted deploying SRS.  This has been a huge
problem for SPF.  A recipient that wants to reject on SPF fail must
implement a forwarder whitelisting system.  This obviously does not affect
SPF publishing, however, it _does_ impact SPF checking where the result is
used for anything more than a clue for SpamAssassin.  That usage does not
justify the SPF effort and is not where we want to be.  Nor do we want to
wait for the whole range of forwarders, over whom the user typically has no
control, to decide that they have to implement SRS.



(As an aside, I think one of SPF's public relations problems is that
much of its evolution seems guided by people who perceive its benefit
as preventing senders' domains from being forged.  A "receiver should
do work to benefit sender" attitude it not a good idea when trying to
promote something.  SPF requires substantial work by receivers, so its
benefits to receivers should be up front.)

That's one way of looking at it, but another perspective is "receiver should
do work to reject forgeries so that it does not abuse others when sending
DSN's".  Another way of saying this is "receiver should do work to only
accept messages with a valid return-path, since it may need to send a DSN
later".



Mind you, I like the SES concept.  I just don't see it overcoming its
deployment hurdle, at least not for a long time.  What I want is
reliable trustworthy email, and I don't much care how we get there as
long as we get there sooner rather than later.

We are very much in agreement on the second sentence.  I believe that SPF is
more "deployable" than other schemes, and I suggest that SES will speed
deployment of SPF.  The forwarding problem is very prominent as a reason why
sites don't implement SPF checking on incoming.  For SPF to be useful,
having lots of domains publishing records is not enough.

There is a chicken vs. egg problem with recipient SPF checking that has not
changed much since SPF + SRS was created.  Most forwarders have not
implemented SRS because they don't have to in order to get their mail
delivered.  Most recipients have not implemented SPF checking because they
know SPF has a forwarding problem that they will have to deal with.  How do
we resolve this deadlock?  I propose that it will not resolve itself, nor
can we do it by proselytizing.  An adjunct protocol such as SES that
resolves the forwarding issue might be just what we need to get recipients
to start checking SPF and rejecting on fail.



Users may not care about the return-path, but mail system operators do.

We are in massive agreement on that.

I'm glad for that.  I guess that's why we're all here.

--

Seth Goodman

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