In <MHEGIFHMACFNNIMMBACACECLHMAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>
"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:
From: wayne
Sent: Saturday, April 17, 2004 8:52 PM
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.
*sigh*.
No. Forwarders send email to specific known people who have
registered and such. SES requires sending all email with the special
envelope froms. Fortune 500 companies will often send email to almost
anyone who requests sales information and such.
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.
Exactly.
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've read quite a few of your posts on the subject. I have said
before that I think SES has valid uses and is an interesting
idea. That doesn't change the fact that it doesn't do everything that
SPF does and is often far more expensive.
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.
Oh, good, right in the first sentence you show why SES is far more
expensive than SPF. So expensive that there are people who consider
CBV to be a DoS attack on the domain name that is being verified.
This has been mentioned many times.
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.
Uh, no. SES depends on a third party to do a CBV.
3) SES allows the final recipient to directly query the domain MX for
verification and have high confidence in the result.
SES will only give certain results when the verification fails.
Because of wild-card accept domains, any CBV that passes is going to
be indeterminate.
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.
No. exists:%{l}.spf.%{d} has been mentioned many times.
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.
No, it does not put the burden on the originating MTA, it puts the
burden on the MTA of the *claimed* envelope-from. HUGE difference and
has been mentioned many times.
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 know of nothing that using SRS violates RFC2821. The folks on the
IETF working group don't seem to think so either. It is certainly
ugly, but that's a different subject.
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.
Well, when reality conflicts with a theory, the theory loses. SPF is
being adopted just fine, thanks.
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.
True, and this is the thing I like about SES. When I get time, I may
well use David Woodhouse's Exim patches to implement SES on my
system.
I encourage a healthy discussion on this topic.
Yes, and I believe you have set up a mailing list for just such
discussions.
Let's keep SRS discussions on the SRS lists, SPF discussions here, and
SES discussions on the sender-auth list.
-wayne