-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Seth
Goodman
Sent: Thursday, December 16, 2004 1:32 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: RFC 2821 and responsibility for
forwarding
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.
You have peaked my interest. Can you refer me to a URL for those benefits?
<...>
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.
Nor should we care. You will be crippled if you try to build enhancements
around existing buggy
non-compliant software. Unless the buggy software has significant
deployment/impact, then it should
be ignored, seriously. (albeit mentioned in the FAQ)
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.
Thank you for clearing that up.
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?
Valid point, but remember that the load issue appears for large email
providers. And large email
providers will be caching the SPF queries on DNS servers close to the email
servers. Therefore it
is effectively only the SES queries that will always require connections that
"go out the network
pipe". Whether or not that is an issue, well, depends on an ESP. Most ESP's I
expect have plenty
of bandwidth (it is so cheap today).
I would argue that overall, the SES validation process is
less overhead for
the recipient than an SPF check.
Agreed, unless you make the reasonable assumption that for large load servers
much of the SPF
queries will be cached locally.
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.
I have heard Wayne say that SRS and SES solve tow different problems.
Presumably that means SRS
solvers something that SES does not. If that is the case, I would like to have
feedback on that.
(Wayne?)
Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com