You make a number of good points, and there's really only one point
which troubles me.
From: "Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com>
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Security Paper on forgery bounce DDoS
Date: Sat, 17 Apr 2004 23:30:25 -0500
-------------------------------------
I put forward the proposition that SES does everything that SPF+SRS does,
delivers more confidence in the end result and causes less breakage. Here
are some arguments to support this position.
1) SES asks if a particular message originated from a designated sender for
the domain by doing a CBV to the MX for that domain. The result of this
query is always definitive. SPF delivers a variety of intermediate results,
including 'neutral', 'unknown' and 'softfail', which may be treated in
various ways at intermediate sites.
The dependence upon callback verification is fairly expensive; far more
expensive even than the recent suggestion of fetching SPF via HTTP
rather than DNS. Is there perhaps a way to verify a signed envelope
sender with information from DNS?
2) SES depends on the domain's MSA and MTA to determine who may use the
domain name in a return path. SPF+SRS depends on third parties not under
the domain owner's control to interpret and implement the policy expressed
in the SPF record. Therefore, SES gives the domain owner more control over
the use of the domain name.
In practical terms, perhaps not all domain name owners have complete
control over the contents of their DNS entries, but the efficiency
and scalability of DNS inquiries is a powerful factor in favor of
DNS versus any other method of retrieving information about a domain.
Also, any domain owner who doesn't control their DNS entries probably
has an equal lack of control over their mail server's behavior.
3) SES allows the final recipient to directly query the domain MX for
verification and have high confidence in the result. SPF+SRS requires the
final recipient to trust a chain of assertions by third parties who are
unknown at the time a decision must be made (right after MAIL FROM:). This
chain of assertions is only as strong as its weakest link and is out of the
domain owner's control.
I'll grant you this point.
4) SES can verify not only the domain part of the return path but also the
local part. SPF can only verify the domain part.
Yes, but only by performing an expensive callback verifaction.
5) SES performs verification using CBV's, which put a greater burden on the
originating MTA than the recipient. This is where most anti-spam advocates
have long argued the burden belongs. SPF+SRS puts the burden entirely on
the recipient. While this is historically the direction anti-spam
techniques have gone, it makes spam increasingly cheaper to send than to
reject. SES reverses that trend.
It also makes legitimate email more expensive to send.
6) SES does not require changes to RFC2821. SRS violates RFC2821 by
changing the return-path in transit and requires changes to RFC2821 to be
compliant.
I think you're probably right on this one, too.
7) SES does not break forwarding, which makes it very easy to phase in. SPF
breaks forwarding and requires SRS to fix it, which is a hindrance to
adoption and will make phase-in more chaotic.
Yes, although "chaotic" may be overstating the case.
8) SES gives senders who adopt it immediate protection from bounce spam
while still accepting valid DSN's without anyone else adopting anything.
SPF+SRS requires wide adoption before achieving a significant reduction in
bounce spam.
Yes.
9) SES does not require publishing DNS TXT records, which the majority of
U.S. ISP's and hosting services do not currently support. While the U.S. is
only a single country, it does represents the largest spam source so this is
germane.
I'm not sure about this.
10) SES designated sender policy changes take place immediately, since the
policy is implemented at the originating end. SPF policy changes must
propagate through the DNS system before they take effect. Since network
changes cannot always be anticipated, it will not always be possible to
lower TTL far enough in advance to avoid this problem.
I'm dubious about this point as well. How often are sender policies likely
to change? Name servers rarely cache every single entry they ever fetch
for the entire TTL duration.
I encourage a healthy discussion on this topic.
--
Seth Goodman
Here's my contribution. -- George Mitchell