From: terry(_at_)ashtonwoodshomes(_dot_)com
Sent: Thursday, December 16, 2004 7:00 AM
From: Seth Goodman
Sent: Thursday, December 16, 2004 1:32 AM
<...>
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?
The SES website is at http://ses.codeshare.ca though the documentation is
not quite up-to-date. There are two benefits that senders implementing SES
get even if recipients don't implement it.
1) Rejection of forged bounce spam. Since the return-path bears a
cryptographic signature, the sender will reject any DSN that does not bear a
return-path that it created. This capability is not airtight, since DSN's
vary as to structure and content, and it is difficult to use the message
digest to verify the returned message content, if it is returned at all.
Therefore, it is subject to replay of harvested return-paths. Until most
systems adopt a relatively uniform style for DSN's, that is the best that
any cryptographic system can do.
2) A number of large providers today use SMTP callbacks to the return-path
address before accepting a message. Such systems will automatically reject
messages with forged return-paths for a sending domain that implements SES.
All SES senders MUST implement SMTP callback validation so they can reject
bogus DSN's, so this capability is automatic.
<...>
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)
If this is not a common problem, I completely agree. As this could be a
general issue for SPF, does anyone have any comments as to what DNS packages
do not cache text records by default? If it is simply a matter of
configuration, perhaps that should be included in any SPF implementation
recommendations that wind up on the official SPF site.
<...>
[Terry}
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 agree that most of a large site's load is in the reception side. The SPF
records will cache, as will the SES policy records. The ancillary records
invoked by both protocols, MX, A and PTR records, will also cache, though
SES has less recursion so it uses less DNS cache per domain. Thus, a given
SES record set is somewhat more likely to generate a cache hit for a given
cache size. Just because a recipient is large doesn't mean that all its
senders are large. A large recipient will most likely spend most of its DNS
resources on queries for domains that only send it a few message per day.
Large senders will already be cached (or whitelisted). I believe that,
based on this reality, the incremental load of doing SES validations will be
minimal. If SES is deployed as a forwarding solution for SPF, all first-hop
messages will authenticate using SPF mechanisms and only forwarded messages
will require SES validation. In the case of large senders, the complete
caching of SPF records will make this a win. In the case of small senders,
who generate the majority of the DNS load for the large recipient but a
minority of the message traffic, the incremental load of SES validation for
forwarded messages is minimal. The benefit of end-to-end validation,
however, is quite large.
What is worth keeping in mind is that what we are talking about is DNS
overhead. In all cases, this is far less than the overhead caused the
recipient by PK signature validation as required by DK and IIM.
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.
Agreed for large senders, but small senders will often not be in the cache.
<...>
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?)
Speaking for myself, I would contrast the two protocols as follows. I hope
Wayne gives his point of view here.
SRS tells the recipient that the current SMTP sender is a designated sender
for the domain in the return-path. This may be a forwarder or the message
originator. If it is a forwarder, SRS can make no assertion about the
originating domain. SRS can make no assertions about 2822 identities.
SES validation of the 2821 signature tells the recipient that the message is
identical to one sent out by the originating domain. SES validation of a
2822 signature tells the recipient that the beginning of the message is an
identical copy of the one signed by the 2822 address, but there may be added
content after the signed part. This permissiveness allows the 2822
signatures to survive mailing lists, as in IIM.
--
Seth Goodman