Initial thoughts.

[Brian Candler]

> 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.

The problem that SPF tries to solve is actually smaller than that: it only
verifies the envelope-sender, i.e. the return address for bounces. By the
time the message is displayed to the user, this information has either been
lost, or has been put in a Return-Path: header which only experts would know
how to view and interpret. The MUA displays the From: header, and SPF makes
no attempt to validate this.

I believe there are two reasons why people want to validate the
envelope-sender:

(1) To prevent bounces being sent to forged addresses, otherwise known as
"joe jobs" (that is, if a spammer puts my address as the envelope sender on
a spam, and it bounces, then I get the bounce).
This is a worthy aim, but
- SPF won't help until the whole Internet adopts SPF (if ever)
- SPF won't help with spam sent directly to an end-user with a null
  envelope sender
- There are simpler and better solutions anyway

(2) To identify spam. This is IMO a pointless exercise, since all it will do
is change the spammers' behaviour so that their mails are SPF-compliant (and
note that it's still easy to forge mails under SPF using any domain which
your ISP's IP addresses permit)

> A practicable solution will work end-to-end, without the need for
> participation by conservative and uninterested third parties.

Well, I still think the first thing which needs to be done is to agree on
the problem, before we look at the solution. I put some thoughts up here:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200402/0603.html

Personally, I exclude "verifying the envelope sender on deliverable mails"
from the problem set; if the message is deliverable, then by definition we
don't use the envelope sender anyway, because there's no bounce to be sent.
But I do include forged headers (at least the From: header) as a worthwhile
aim.

> 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?

3. How is this done in a way which is at least partly useful in the interim
period, with unmodified MUAs?

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

Indeed, although in many cases only the headers are munged.

I did wonder whether it was worthwhile adding a sort of cryptographic
"postmark", like a signed version of the Received: header. This could make
declarations such as:
- this mail was handled by the mail relay at foo.com
- this mail was received from IP address x.x.x.x
- this mail was sent by user X who authenticated using SMTP AUTH

Having this information in a proper structured format (unlike the ad-hoc
format of Received: headers), *and* signed for non-repudiation, would lead
to faster tools for reporting of spam and hence for dynamic black-lists.

Unfortunately, anyone who picks up one of these messages with signed
postmarks can then modify it and re-send it, unless the signature covers the
entire message. And thus we are back to the problem that the whole message
needs to be signed.

If we are building an infrastructure which converts plain mails into fully
OpenGPG or S/MIME signed mails: that is cool, in some ways. But the
automatic verification then has to be tied into whatever their existing key
infrastructure is, which is generally not suitable for our needs - we want
something DNS-based.

And if an end-user has signed a message using their own private key, we must
be able to add our own ISP-generated signature as well as it passes through
our mailserver.

(Actually, this is not really a "signature", it's more a "certificate". I,
ISP.COM, do humbly declare that this E-mail was sent by X at Y.COM.)

This kind of turns the normal usage of public-key on its head: normally, the
end-user would sign the mail with their own key, and then the ISP would
certify their *key* to say it belongs to the person with E-mail address
X at Y.COM. Instead, we're saying that the ISP should certify each *message* to
say that it came from X at Y.COM. This has the big plus, from our point of
view, that the end-user does not need to have their own key or sign the
message at all.

Then you have to consider how an end-point will verify the signatures. If
it's an MTA, then it can make a lookup in the DNS in real-time. However if
it's an off-line MUA, which has downloaded the mail using POP3 say, then
either it must trust the final MTA to stamp the message somehow, or it must
be able to verify the signatures off-line (which means a chain of trust up
to some root certificates)

> 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?

- extra Received: headers are added (as required by RFC2821)
- other extra headers may be added (Sender:, X-wotsit:)
- some evil systems rewrite From: (From: foo at mail.mydomain.com to
  From: foo.bar at mydomain.com; typically only at the sending end though)
- often footers are added (adverts, company signature, pointless virus
  sweeper signatures)

Those are the major things. Given that a small but non-zero set of people
use GPG successfully, including sending to mailing lists, I think in
principle it's possible to sign the whole message.

Whether people will accept the extra signature noise, or the concept of
mails being signed by third-parties in transit, is another matter...

Cheers,

Brian.