From: wayne
Sent: Sunday, April 18, 2004 12:30 AM
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.
Point well taken. Just as things work today, people who harvest SES
addresses and spam them will end up on blacklists, if they are not already
listed. Under SPF, the mailservers of these same Fortune 500 companies send
mail with unsigned return-paths, which may be harvested in the exact same
way. With straight SPF, those servers have _no_ protection against bounce
spam except for existing blacklists. Furthermore, an SES address expires
after a week or two, whereas unsigned addresses are good forever. Dying
doesn't even get you off the spam lists :) I think SES wins in this area.
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.
It sounds like we agree on this. To stop a bounce spam attack with SPF you
have to deny all DSN's, including legitimate ones. With SES, we could take
the same approach but we don't have to. We can continue to reject bounce
spam while accepting legitimate DSN's.
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.
Perhaps you could list some of the things that SPF does that SES doesn't do?
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.
You have a few tools at your disposal to distinguish legitimate use of CBV's
and a DOS. Legitimate CBV's pass, forged CBV's don't. If you are being
deluged with CBV's from a site that don't pass, you can deal with it just
like any other DOS attack. SES doesn't prevent DOS attacks, nor does SPF.
Answering a CBV that doesn't verify is very similar in terms of overhead to
receiving an incoming SMTP connection that generates an SPF fail. They can
both be abused as an attack and sysadmins will have to deal with this abuse
potential in either case.
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.
The _recipient_ does the CBV to validate the MAIL FROM:. If the recipient
does a CBV, they are getting the answer from the domain MX itself rather
than some uninterested third party, such as a forwarder. Furthermore, if
there have been one or more forwarders in the chain, each site must accept
the previous site's assertion that the incoming message passed SPF when they
received it. Under SPF+SRS with forwarding, there is no way for the
recipient to "go back to the source" and avoid relying on this chain of
assertions. IMHO, that is a fundamental design flaw in SPF. This is
particularly problematic if anyone in the transport chain did not do SPF
checks on incoming messages (i.e. they were whitelisted) or did SPF checks
but chose not to reject with an SPF fail result (the present draft does not
require rejection on SPF fail).
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.
We don't need to use wild-card accept domains in SES. Neil Brown proposed a
method that we discussed and hopefully refined that permitted a secure back
door for designated forwarders using a cryptographic cookie in the
return-path. The cookie is static, so the forwarder does not need to
implement anything. However, if the cookie should be discovered, which is
as likely as an SRS forwarder's return path being harvested, the cookie can
be changed in an automated manner (for the ISP, not the user).
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.
Using your example of a Fortune 500 company, are they going to publish a
record in the domain DNS for every user? That would be quite a DNS record.
Reading that record would give you the email address of everyone in the
company. That doesn't sound like a good idea at all.
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.
And I'll repeat the answer again. You can tell when CBV's are being used as
a DOS, just as you can tell when SMTP connections that result in SPF fail
are being used as a DOS. The overhead of a CBV that fails is almost
identical with the overhead of an SMTP connection that results in an SPF
fail. If anything, the CBV overhead is less since we don't need to look up
and evaluate an SPF record, which may generate further DNS requests and
execute a lot more code. In the case of a CBV, if a given user has sent out
any mail that day, the first CBV causes the MTA to do a hash calculation and
then the result can be cached. For that matter, the outgoing return-paths
could be cached assuming that CBV's will occur so CBV's will rarely or never
result in a hash calculation if cache size is adequate. Both protocols
could be used as a DOS tool, and it is equally detectable and requires
similar measures to deal with in both cases.
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.
See my earlier post.
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.
The sender-auth list was to discuss various cryptographic means to verify
other message headers and the message body. That list has also been
inactive for months. I am discussing some deficiencies in SPF and I believe
this is the proper place to discuss it.
--
Seth Goodman