From: Scott Kitterman [mailto:spf2(_at_)kitterman(_dot_)com]
Sent: Saturday, August 20, 2005 6:57 PM
Yes. The tricky part of "once the forwarding issue is dealt with
properly". What is properly?
You can validate that a designated sender for the claimed source domain
originated the message, regardless of the forwarding arrangements of the
individual recipient. In other words, SPF can validate the return-path
domain in the presence of an unknown number and identities of forwarders.
Right now it can't.
I think the DKIM and SPF have the potential to complement each
other nicely.
Yes, they can, but there are other much lighter weight methods of solving
the forwarding problem. If you really like DK, then you should definitely
implement it. It doesn't really solve the problem of validating the 2821
sending domain, it validates a 2822 sending domain and says that's good
enough. To get it right, I think we need to validate both, when they are
not the same. When you can validate the 2821 sender domain and the 2822
sender domain is the same, you have just validated both with one test. This
describes the great majority of private email traffic. Mailing lists are
the major exception, while greeting card sites and "send this article to a
friend" functionality are minor exceptions. I argue below that mailing
lists don't need 2822 protection, so that just leaves the minor exceptions,
and there are practices that easily make them SPF-compliant. This suggests
that the most efficient strategy is to validate the 2821 return-path on all
messages before data, whether forwarded or not. SPF almost does that, but
we need to plug the forwarding hole.
I suggest SES as a very efficient replacement for SRS that solves the
forwarding problem without the cooperation of any forwarders. Even though
one _could_ use it as a standalone 2821 validation protocol, when used in
combination with SPF, you only use the SES mechanism if you are unable to
get an SPF pass otherwise. The sender controls when an SES validation query
is issued by where they put it in their SPF record. They can put it first,
last or not at all.
Some examples:
- Direct point to point e-mail: both work fine
- Traditional forwarding: DKIM works fine, but SPF has issues
DKIM never allows you to reject before data. SPF + SES validates the 2821
identity at very low overhead regardless of the number of forwards. This
still allows you to reject before data most of the time.
- Mailing lists: SPF works fine, but DKIM has issues if content is
modified.
Relatively unimportant. I don't see any pressing need to validate the
original authors on mailing list posts. If it was that critical of a list,
it should probably use GPG or S/MIME.
Now this is assuming that DKIM actually ends up being an anti-forgery
technology. There are those on the DKIM lists that are actively opposing
that. They just want anybody to be able to sign anything.
Yes, that is unfortunate. With the line count parameter that allows the
signature to survive mailing list additions, a DKIM-signed post distributed
and archived by a public mailing list is a very nice header for any spam
payload you care to append. Just put a legitimate throw-away domain with a
good SPF record in the return-path and you will get a pass both from SPF and
DKIM. The time limit parameter is of little use, as most spam campaigns can
start and finish within the five days that you have to allow for a
single-hop delivery.
So I'm thinking that if you look for a Pass (or non-Fail) from
SPF and then
from DKIM if the sender has promised you DKIM as an option in his sender
policy, then you've got almost all the bases covered without the
whole world having to upgrade.
Since virtually no one does DK now, how do they get it without upgrading?
<...>
I realize that there are other ways to solve the forwarding problem, but
DKIM happens to be one that has a lot of momentum behind it right now.
That depends on whom you ask. Microsoft claims SID has a lot of momentum.
Some people think SRS has a lot of momentum. Some even think RMX has a lot
of momentum (after all, it was there first!). I think they're mistaken, but
time will tell. Rather than just getting behind whatever protocol looks
like it is popular at the moment, how about carefully outlining what problem
really needs to be solved, and _then_ deciding which method solves it with
the least breakage and with the lowest resource usage.
--
Seth Goodman