Initial thoughts.

[David Woodhouse]

The problem that SPF tries to solve is a real one -- _anyone_ can send
mail claiming to be from, for example, dwmw2 at infradead.org, and there's
currently no way of doing anything more than verifying that this is at
least a real address.

It's not the _only_ problem, but it's an interesting one.

The real problem with SPF is that placing restrictions on the IP
addresses from which mail for a given domain may originate is
fundamentally incompatible with the way SMTP actually works and has done
for decades. 

SRS attempts to fix this, but has its own problems, and even so could
only _actually_ fix the problem with SPF if it were to be implemented
_everywhere_.

Basically, the SPF+SRS 'solution' is no more realistic than any of the
myriad other schemes which have cropped up over the years which required
a fundamental departure from the status quo; a complete obsolescence of
SMTP as-is. It's just slightly more cunningly disguised as a practicable
plan than some of the others.

The problem which it addresses, however, remains as I said an
interesting one.

A practicable solution will work end-to-end, without the need for
participation by conservative and uninterested third parties. I think
that has to be considered a fundamental requirement, along with
backward-compatibility with the status quo. It'll let those who _want_
to participate advertise information to each other and verify each
others mail, but won't break if third parties don't play. And hopefully
it'll eventually gain critical mass so that we can stop talking to those
who _don't_ do it.

One possibile solution which looks like it could answer the same problem
is some form of cryptographic verification of the sender. By signing the
outgoing mail with a private key, the public complement of which is
available in the DNS, we can just as easily verify that it really come
from the address it _claims_ to come from.

GPG signing is an obvious first stab at a solution. One might easily
declare to the world at large, if there were a standardised way in which
to declare it, that "All mail from dwmw2 at infradead.org will be
GPG-signed. If you receive a mail claiming to be from that address which
is _not_ GPG-signed, reject it".

GPG serves to illustrate the point, but isn't great when you look at the
details. The plain-text signing method introduces cumbersome noise, and
the MIME method, well, requires MIME -- which is considered by many to
be cumbersome noise. :)

Ideally we'd be able to introduce a signing scheme where we put a hash
into the headers, cryptographically verifying some part of the mail
headers and contents. The questions are as follows:

	1. What part of the mail and its contents need verification?
	2. How shall it be done?

The problem we have is that forwarding MTAs may perform arbitrary
mutilation of our mail, disrupting our signature.

We don't have to worry _too_ much about mailing lists -- although they
often munge headers and add bits to the mail, they _also_ change the
reverse-path, so our original signature becomes irrelevant anyway. But
we do need to be concerned about virus checking crapware which adds its
own little adverts, and perhaps also MTAs which do address rewriting.

Actually I'm not entirely sure either of those _are_ good examples. If
we're doing the crypto-signing in the MTA, that can quite happily happen
_after_ the virus-crapware does its thing, or the address rewriting.
These things happen on _outgoing_ mail, and it's the responsibility of
the sender to ensure that the mail leaves their servers with correct
signatures, if they choose to publish their pubkeys for the purpose of
verification.

It's late -- I must be missing something here. What are the _valid_
instances of mails getting rewritten in transit, by intermediate
forwarding hosts between those which are doing the signing and those
border MX hosts on the reception side which are _verifying_ the
signatures?

--- 

Also interesting to note is that there's another really simple solution
to the original problem of faked senders. That is if we accept, as is
going to _have_ to be the case if we're honest with ourselves, that
_any_ scheme is only going to work between participating senders and
receivers. We just implement some form of SRS on our own outgoing mail,
then perform sender verification callouts on received mail. If someone
attempts to send mail claiming to be from dwmw2 at infradead.org, my server
will refuse the sender verification callout with empty reverse-path,
because nobody _ever_ sends mail from that address. We only send mail
from SRS0+XXX+YY+infradead.org+dwmw2 at infradead.org; addresses which are
extremely hard to fake.

-- 
dwmw2