On Thu, 2005-02-03 at 11:20 -0500, Marc Sherman wrote:
> And there goes your AWL score, David... :)
:)
> I'm curious, David. You've made your opinion on SPF quite clear... how
> do feel about DK in comparison? Just as bad, flawed-but-fixable, or the
> one true path? Do you see anything better out there that can be made to
> work? Or are we basically screwed until the world-wide SMTP network
> falls into a spam-induced black hole and is replaced whole-cloth?
DK has potential problems which are related to what I've just been
discussing with Tom -- you can't guarantee that it'll survive through
mailing lists, so you can't reliably reject mail simply on the grounds
that the signature from the address in the From: header is invalid. But
that's a detail which looks fixable, not a fundamental flaw in the
approach.
There are a couple of options for fixing the problem. The first option
is "don't do that then". If a mail is resent by a mailing list or a
user, then a Sender: or Resent-From: header will be added. You detect
the presence of these and behave accordingly because you know that the
mail in question _didn't_ come directly from the address(es) listed in
the From: header. You check for a valid signature from the Sender: or
Resent-Sender: address, instead.
Another option is to try to make it work thought mailing lists. That's
hard, but Cisco's Identified Internet Mail tries -- it gives the signer
an option to say how many lines were present in the original mail. So
even if a mailing list adds a few lines to the end of the mail, you can
locate the original text and verify the signature.
The problem with that option is that it allows a spammer to tack their
content on to the end of an existing mail, and with HTML mail they can
even then hide the whole of the original content. But if you can use the
'number of lines' option and advertise that you'll never send HTML mail,
it could be workable. I think there'll be too much resistance to a
scheme which can't work reliably for HTML mail though -- we're going to
have to accept that we can't come up with something which survives
resending.
So we're back to the first of the two options above -- checking only for
a signature from the 'most recent sender', not necessarily from the
address in the From: header. In the example I used of Tom sending mail
to the list, I can't know for sure that it did actually come from Tom,
but I _can_ know that it really did come from the list (if the list does
DK/IIM).
The problem with 'most recent sender' is that it may be _either_ of the
Sender: or Resent-From: headers. You can't easily tell which was more
recent. Personally, I think we should use the MAIL FROM address for this
purpose, not any of the RFC2822 identities -- it's entirely unambiguous,
and it's the correct 'layer'. After all, we're trying to authenticate a
single transit through the RFC2821 mail system, not trying to
authenticate a given RFC2822 mail object throughout its lifetime and
through multiple transitions.
The argument against using the RFC2821 reverse-path is mostly that it's
not reliably visible to the user. But that's a fairly spurious argument,
for two reasons. Partly because the RFC2822 identities aren't reliably
visible either -- how many MUAs reliably actually show Resent- headers,
Sender: headers, etc.? Outlook doesn't even display the address in the
From: header; it displays the pretty-name instead.
But the main reason I think the visibility argument is bogus is because,
as I said, by the time the mail has made it to the user it's too _late_.
A truly useful scheme is one which can catch the spam/forgeries and
reject them before they get to the user. The user can already tell spam
from non-spam in the majority of cases once you've actually put it in
front of them and wasted their time with it.
So while DK and IIM have their merits and I'm very interested in
implementing them to see how it goes, I think a scheme based on
authenticating the address in the RFC2821 reverse-path could be much
better. A crypto-based scheme like DK or IIM could use the reverse-path,
but none actually do.
The other thing you can do is actually encode the reverse-path itself,
rather than just including a DK-like signature which can authenticate
your use of the reverse-path in question.
That's what I do. Instead of including a header with a signature which
shows that my use of 'dwmw2@???' in the reverse-path is
authentic, I encode that signature into the reverse-path itself. I never
send MAIL FROM:<dwmw2@???>; instead it's all from
automatically generated addresses including a timestamp and a crypto
hash -- it's very much like SRS. You can see my implementation at
http://david.woodhou.se/eximconf/include/routers-ses
The immediate benefit of this is that I can reject all bounces directed
at dwmw2@??? -- they're _all_ bounces to mail I didn't
actually send. This in turn means that anyone doing SMTP sender
verification callouts will be rejecting faked MAIL
FROM:<dwmw2@???> too. They don't have to know about my scheme
and implement it themselves; they only need to be doing callouts.
That's basically the core of the idea which is being called BATV. SES
takes the same thing a little further.
Although the reverse-paths are time-limited there's a small chance that
one could be harvested and abused by spammers for a few days. So SES
allows you do include a message-digest in the reverse-path itself too,
and an SES-aware recipient can check that to prevent the replay attack.
Also, SES panders to those who are rabidly in opposition to sender
verification callouts, by offering lightweight validation options. There
can be a UDP service, and one based in DNS which is supposed to be
compatible with SPF and the 'exists:' mechanism.
SES seems to offer a lot of promise, and it gives an instant benefit to
the deploying sender even without any recipients playing alone. The
validation mechanism could be a useful alternative to SMTP callbacks
even for a sending domain which _isn't_ signing its reverse-paths, or a
receiving domain which isn't checking SES message-digests. There are a
few minor niggles -- some configurations of ezmlm, for example, restrict
posting to the list by the reverse-path, and that's a PITA if your
reverse-path is different every time. But on the whole it works well
enough for me that it's reduced my motivation to actually implement
anything more.
DK and IIM if done _sanely_ so that they'll not reject genuine mail are
also interesting, but for that they need to either standardise on the
'most recent RFC2822 sender' address, or allow the use of the RFC2821
reverse-path for the signature, rather than pretending that their
signatures can reliably survive mailing lists in reality.
--
dwmw2
