From: terry(_at_)ashtonwoodshomes(_dot_)com
Sent: Tuesday, December 07, 2004 3:00 PM
From: David Woodhouse
Sent: Tuesday, December 07, 2004 1:19 PM
On Tue, 2004-12-07 at 12:46 -0500, terry(_at_)ashtonwoodshomes(_dot_)com
wrote:
Forget about SRS, there are some serious problems with it: even Meng
has admitted to such.
I think most people can see the problems in getting SRS widely deployed, in
addition to its technical flaws.
<...>
Please refute the argument with more recent and seemingly better SES
solution.
I don't see SES documented on spf.pobox.com. Perhaps the council can
address that omission, if people really see SES as a successor to SRS?
This is a serious omission, as SES is, IMHO, the most likely successor to
SRS. It requires the least change to existing infrastructure and there are
benefits to the sender even if recipients don't participate.
<...>
Anyone can argue that an old solution is bad, but truly
one needs to argue against the most recent version of the
solution.
I'm was trying to avoid mentioning SES too much -- I've been
accused of advocating that purely because it's based on my own
idea. Not that said idea wasn't fairly obvious once I was
looking at SPF and SRS together.
I don't see SES as a fix for SPF's forwarding problem though;
I see SES more as an _alternative_ to SPF, just like DK, IIM
and the others.
My position is different from David's here. While SES is competitive with
DK and IIM in that it is a cryptographic solution that gives end-to-end
authentication, it also happens to be an excellent means to fix SPF's
inherent forwarding problem. While we have designed in the ability to
operate without SPF, it will happily perform as a forwarding protocol for
SPF.
I say this because when used with SES, SPF is _purely_ an
optimisation.
A significant optimization, because:
1) SPF DNS queries are cached
I am told that some resolvers do not properly cache text records. All other
SPF-related queries are cached. I don't know how common this problem is.
2) SES requires building/tearing down a TCP/IP (or at least some
form of) connection to the originating server for every email
There is no need for a TCP connection to do SES signature validation. The
preferred callback mechanism is a UDP service, much like DNS only simpler.
A validation request is one UDP packet and the response is one UDP packet.
There is no TCP overhead and no socket plus thread per message penalty, as
TCP often incurs.
You can do the IP-address-based checking and bypass the
actual SES check for some mail, but for the 'suspect' mail
you still have to do SES checking.
The SPF check should succeed for all direct-delivery (non-forwarded) mail.
The SES check would only be needed when none of the SPF mechanisms match,
which would be forwarded mail.
But in general, no load of _valid_ mail is going to
constitute a denial of service attack; it's the _invalid_
mail which is going to cause the
I think your hypothesis is incorrect. Servers that process
gigabytes of legit email (such as some of mine) would be
impacted by the overhead of SES that SPF does not cause and
SPF can handle. Not to say they cannot handle it, but they
would be a lot closer to needing more hardware then without
doing SES on every message.
I come to a different conclusion here. SES requires fewer DNS queries to
resolve the policy record than the average SPF record and none of them are
text records. Thus, the responses are shorter, interpretation is easier and
they are always cached. SES validation through UDP adds one UDP packet out
and one UDP packet in. These results are not cached, though the callback is
lighter weight than a single DNS query. How many DNS queries does the
average message require before we even get to the point of doing the SES
validation request?
I would argue that overall, the SES validation process is less overhead for
the recipient than an SPF check. In any case, since SRS is generally
unsuitable because it does not allow recipients to reject forwards that
forge the original recipient, we have to do something. SRS prevents us from
accomplishing the goal that lured us all to SPF in the first place: enable
us to reject domain forgeries at SMTP time, including forwarded mail. The
fact that forwarded mail currently has less volume than directly delivered
mail is immaterial. If we widely implement SRS, forwarded mail will become
the forgers method of choice, since SPF cannot detect when an SRS forwarder
has forged the originating address.
loads we care about. So to use SPF in addition would be optimising the
case we _don't_ care about, while leaving the real SES check
in the case we _do_ care about. Using SPF with SES doesn't really buy
you much over and above what you get from just using SES alone. And
the SES check is lightweight enough that it isn't a problem.
That is incorrect: SES is not lightweight enough (it requires a
callback per email).
It does require a callback per message, but on average, I maintain that an
SES validation is lighter weight for the recipient than an SPF check. The
main reason for this is that the SPF record has numerous mechanisms that,
while convenient, can cause a significant number of DNS queries to resolve.
<...>
So you are pushing pure SES. Cool. Go spread the good word by
advocating SES on SES lists. Don't push SES by beating up SPF
please. There ARE solutions to the forwarding issues, you
clearly condone one of them: SES
David's views on SPF are well-known. If you disagree with those views,
don't throw out the baby with the bathwater. I take a somewhat different
position than David on this point: SES is a suitable replacement for SRS
and it is a particularly good fit with SPF. There is no need to bash SPF to
make this assertion, and I am not bashing SPF. SPF does its job as
advertised on the first hop, particularly if the sending domain has enough
control of their mail setup to avoid using the "?" prefix. Though SES is
only one of several possible solutions to SPF forwarding, my position is
that it is particularly synergistic with SPF, lighter weight than the others
and deserves serous consideration as a replacement to SRS.
--
Seth Goodman