From: George Mitchell
Sent: Saturday, April 17, 2004 11:52 PM
You make a number of good points, and there's really only one point
which troubles me.
Thanks for the thoughtful comments. I'll try to address the CBV cost issue
below.
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?
In fact, there is, but it involves asymmetric crypto. The sender would sign
the return path with the appropriate private key and the recipient would
validate the signature and return-path content using the public key
published in the domain DNS. This keeps network bandwidth low, but has a
high CPU cost at the receiving end. In all other respects, it has the same
benefits as SES done with CBV. If this variation sounds more attractive, it
is not hard to put the SES address in this format.
With regard to HTTP, I'd be surprised if the cost of a CBV to the message
recipient MTA is nearly as high as anything based on HTTP. While it is
certainly more expensive than a UDP DNS query, it is about as short an SMTP
session as is possible. Since I would argue that you get higher quality
information than with SPF, "you get what you pay for" is the watchword.
Now, we should certainly ask, "is the benefit worth the cost"? I think it
is, but that is really what we should be discussing with regard to every
proposed anti-forgery scheme.
When considering the cost of any scheme, we really need to look at the
incremental cost, since there is a certain amount of overhead that is
present even if we don't implement any of these schemes. Just like SPF or
any other higher-level protocol, you only process messages that pass all
other tests, i.e. FCrDNS on the SMTP-client IP, HELO/EHLO string checks,
DNSBL's, local blacklists/whitelists, RCPT TO: validity, etc. Just as with
today's best commercial practice, only some of the incoming mail stream
would pass all these tests (less and less as time goes on) and then we would
do a CBV only if there is an SES return-path. I would suggest the
incremental cost of SES is the overhead of the CBV's that we actually do
divided by the overhead of the sum of all these other tests.
There are really two numbers here, network bandwidth and CPU cycles. While
CBV's use more network bandwidth than DNS queries, I bet that the net effect
on network bandwidth of a busy mailserver would be negligible, just at Theo
Schlossnagle showed was the case with SPF. I am guessing that this would be
the case for the same reason that I think Theo's numbers came out as they
did: the accepted messages themselves, which are large and transmitted via
TCP, far outstrip the sum total of all the other protocol overhead,
including rejected messages. CPU cycles is another question, but in the
end, rejecting more messages at SMTP time may result in a net gain rather
than a loss.
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.
Yes, I agree that domain owners should have control over their DNS. That is
a completely reasonable expectation. What domain owners don't have control
over is how other parties interpret their SPF records. Due to various SPF
implementations and local SPF policies, the domain owner who published the
SPF record may or may not like the way their published policy was carried
out. SES returns a binary result, pass or fail, from the domain MX, which
the domain owner generally has more control over than SPF implementations at
other sites.
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.
This is part of what I meant by "you get what you pay for". A CBV is more
expensive than a DNS lookup, though as James Couzens described in his
outline of SPF processing, there is quite a bit more logic (CPU cycles) and
often additional DNS lookups, so it is not simply issuing a single DNS query
and getting a yes/no answer. In addition to having higher confidence in the
end result, the recipient gets validation that the local part of the
return-path is good. Might that not be worth the extra cost?
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.
Yes it does, but it also eliminates bounce spam for your site, so this may
offset the added cost of sending legitimate mail. For spammers, there's no
offsetting benefit. It just makes their operation more expensive.
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.
I think the difficulty of this one has been underestimated or largely
ignored.
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.
Agreed, it was a poor choice of words. What I was trying to convey was that
since SRS adoption will not happen all at once, there will be a very
'dynamic' situation for a significant period of time that will be a
challenge for sysadmins to keep up with. Keeping track of which forwarders
are doing what on a daily basis is not a challenge that I would look forward
to. Wayne's trustedforwarders.org is a step in the right direction, but it
will be a challenge regardless.
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.
My comment about lack of support for TXT records is admittedly anecdotal.
Looking at the control panels of a number of the largest U.S. hosting
companies showed a lack of support for TXT records. Similarly, the
mainstream U.S. registrars I've looked at don't support TXT records in their
DNS control panels. My claim is weakest for ISP's, since they vary all over
the map and their control panels are not often available online for a "test
drive". However, this has at least been my experience and others have told
me of similar experience.
As far as where the spam comes from, what I was referring to was the end of
the money trail. While the spam itself sometimes comes from offshore MTA's
(less so now that hijacked broadband boxes are plentiful locally) and the
spamvertised sites are sometimes hosted in offshore "bulletproof hosting"
facilities, they are being paid for primarily by U.S. companies. Sadly,
this is one area where the U.S. can legitimately make a claim to world
leadership: being the largest source of spam. I believe that SpamHaus
recently estimated that 80% of spam received in Europe was of U.S. origin.
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.
If your company is medium or large and you use the 'exists' mechanism to
qualify individual users, it could change quite frequently. Consider
intra-company transfers, new hires, retirements and layoffs. I'm no t
knowledgeable enough about DNS to comment on your last observation, except
that if the caching time is often shorter than TTL, this is obviously less
of a problem. I imagine this would vary widely with the nameserver you are
querying, but perhaps not.
I encourage a healthy discussion on this topic.
Here's my contribution. -- George Mitchell
Greatly appreciated.
--
Seth Goodman