Initial thoughts.

[Brian Candler]

On Tue, Feb 24, 2004 at 02:31:00PM +0000, David Woodhouse wrote:
> > - a mail from "b.candler at pobox.com", sent via myisp.net, could be signed via
> > myisp.net saying "this mail came through me, but I cannot vouch for the
> > sender; the real sender could be be anyone at isp.net"
> 
> I don't see what this achieves. If the host in question is clueful, its
> Received: headers are already enough, surely?

In theory yes.

I categorise this discussion under the heading "what do people think they
will gain from SPF?". If we understand what people think they will gain from
SPF, we can perhaps offer them a better solution.

The main reason for SPF I've seen on the list is: "I don't want my domain to
be abused". I translate this as: "I don't want my domain to appear in the
Return-Path: header or Received: headers in spam." They see SPF as a way to
stop their domain name being used in MAIL FROM and HELO respectively. Why do
they want this? Presumably because they receive misdirected complaints based
on their domain appearing in those places.

But: these are *obvious* forgeries. Anyone who knew what they were talking
about would look at Received: headers only, and only the parts which can be
trusted (i.e. ignoring HELO names provided by remote hosts).

So the only benefit which SPF gives is to give better quality information in
these headers, so you don't have to sort the wheat from the chaff manually.

IF that's what they want, THEN structuring and/or crypto-signing that
information is a better solution than attempting to validate MAIL FROM and
HELO names based on the IP address of the person connecting to you, a la
SPF.

> > Hmm. Let me put it another way. Suppose in our smarthost MTA we see a mail
> > which says
> >    From: president at whitehouse.gov
> > 
> > but whitehouse.gov has not published any key information, so we know the
> > recipient won't be able to verify it one way or the other.
> > 
> > I think it would be better for us to sign it saying "This mail probably came
> > from *@myisp.net", than not sign it at all. The receiver then has something
> > to verify (using the myisp.net key in the DNS) and show to the end-user.
> 
> But it means nothing. It's like signing a memo you found on your desk
> without reading it, just to say "I saw this and it really did exist".

Well, at least you said "this memo has been on my desk". Someone *could*
attach some importance to that fact, depending on whose desk it is, and how
hard it is to get something onto it.

Let's face it, if you are just checking the RHS of a domain (like SPF or the
system we're discussing, without SMTP AUTH), you are saying no more than
this:
1. this mail has been through myisp.net's mailserver
2. its RHS domain happens to be one of the domains which myisp.net handles

A large ISP can easily have 10,000 domains handled for its customers. In
that case, "this mail has been through myisp.net's mailserver" is actually
the main piece of information.

I had another thought. Given the information "this mail has been through
myisp.net's mailserver", a hybrid SPF-like system might become feasible,
because you've eliminated the forwarding problem.

i.e. (1) outgoing mail is signed "I've been through myisp.net"
     (2) domain foo.com declares in SPF "mail can originate from myisp.net"
         (rather than "mail can originate from IP addresses X,Y,Z")

Doesn't really gain you much, except that the outgoing mail relay needs no
intelligence (it doesn't need a database of which domains to sign). That
information goes back into the DNS. It does hand some control back to the
domain owner though; if I own a domain, and decide I am going to send mail
via isp1.net at work and isp2.net at home, I can declare in the DNS that
fact.

As for the problem of mails being modified and resent: the alternative
solution is to make the signatures time-expire, like SRS, and check them at
receipt time only. Much less strong because they could be captured and
re-used for a short period of course, but at least not subject to the SPF
forwarding problem. But then, SRS and callbacks achieve the same without any
public key infrastructure at all.

Regards,

Brian.