From: wayne
Sent: Saturday, April 17, 2004 8:52 PM
In <MHEGIFHMACFNNIMMBACAMECCHMAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>
"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:
On Fri, Apr 16, 2004 at 03:55:37PM -0500, Dustin D. Trammell wrote:
| http://www.techzoom.net/paper-mailbomb.asp
[SPF can't prevent this attack until high rates of adoption] On the
other hand, any one of the Signed Envelope Sender approaches
that have been
mentioned on this list and SRS-discuss will stop all of it
today, without
anyone else adopting anything.
This is true, although it assumes that the attacker can't grab even a
few correctly created SRS addresses. In many cases, with Fortune 500
companies, this could be easy to do.
If this is easy to do, it is equally easy to harvest SRS0 signed addresses
from forwarders. These can be used to successfully route bounce spam to the
target. Both SES and SRS are equally vulnerable to playback attacks of this
type. In reality, I think it would be difficult to harvest such return
addresses in either case. There is no clear advantage in this regard for
either system.
It also assumes that the victim doesn't just stop acceptancing DSNs
until the attack disappears.
Yes, but that requires throwing out the baby with the bath water. This can
be done with or without SES, SPF, DK, etc. It is equally effective and
equally painful whether or not you implement an anti-forgery scheme. SES
does not require the victim to stop accepting valid DSN's.
They also deliver all the other
functionality that SPF+SRS does.
We have been through this before and SES/SRS doesn't do everything
SPF+SRS does, and it is often far more expensive, requiring an SMTP
callback.
This last statement is not quite accurate. Though several people have
proposed SES schemes on this list and I've repeatedly asked for comments,
there have been none from the primary SPF proponents. I think an open
discussion on this topic would be beneficial to all. If SPF+SRS is truly
better, we can all see how and why.
-------------------------------------
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 encourage a healthy discussion on this topic.
--
Seth Goodman