Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

> On Fri March 4 2005 09:24, Keith Moore wrote:
> 
> > > Well, that was Wayne's comment.  From my perspective (as a mobile
> > > user (i.e. connecting via an unpredictable IP address) with need
> > > to use only a few domain names) I'd phrase the issue as "being
> > > able to use any IP address"; and that's where SPF utterly fails.
> > 
> > or to put it another way, SPF is not applicable to that case.
> 
> The problem is that if the ISP that handles my *incoming* mail
> decides to use SPF and list only their *outbound* MTA IP addresses,
> I am screwed.

For that matter, if your ISP that handles your incoming mail lists the
wrong MX records, you are also screwed.  You can think of it as a flaw
in SPF, but most of our protocols require correct configuration of DNS
to work properly in practice.

It's not immediately clear whether a domain holder has any right to
insist that mail traffic "from" that domain only originate via 
particular IP addresses - my guess is that if nothing else, it's error-
prone, as too many network admins will assume (without adequate
justification) that all mail "from" their domains is sourced via some
set of well-known IP addresses.

> > and a number of ISPs and networks are blocking 
> > outbound access to port 25, thus forcing their users to send
> > outgoing mail via their SMTP servers (they may permit use of another
> > network's submission server on port 587).
> 
> Yeah, that's the situation I have at the moment (local ISP blocks
> 25, my ISP doesn't use SSL (port 465) or run a submission server
> on port 587).  The local ISP isn't so fascist that they block
> 465 and 587, but I suppose some might do that also.

Especially given that RFC 2476 doesn't require authentication.

> > it doesn't do much to address the 
> > problem of an MTA or recipient that wants to avoid handling 
> > unauthorized mail.
> 
> In the context of mail, i.e. requiring no prior arrangement
> as noted in Dave Crocker's architecture draft, "unauthorized
> mail" makes little sense. 

I should clarify that by "unauthorized mail" I meant sending a message
using MAIL FROM:<address> and/or From:<address> without having the
authorization of the party associated with <address>.

> An SMTP receiver for some domain,
> say example.net, might avoid relaying by refusing to accept
> message DATA which is neither MAIL FROM its domain nor destined
> for an RCPT TO its domain (and it had better not be too picky
> about the MAIL FROM part, as legitimate users within the
> example.net domain might desire or need to specify a different
> mailbox for bounces).  As far as acceptance of messages for
> RCPT TO in example.net, nothing else is relevant: the return
> path (MAIL FROM) indicates where to send bounces, and plays
> no role in any sort of authentication, EHLO/HELO domain is
> often forced by client software to be the same as the return
> path domain, so is uninformative, and IP address is irrelevant.

There are a lot of stupid policies out there.  People are so desperate
to block SPAM that they block a lot of legitimate mail in the process.
Our job is to improve the reliability of mail - which includes both
telling people how to do a better job of blocking unauthorized mail
and telling people which countermeasures do more harm than good.

> > what might be useful is for an MSA to use SMTP AUTH to establish 
> > credentials of an originator, and then use that to add headers to a 
> > message authenticating that message as being from that originator.  
> > (though you need some way for the originator to defeat that in case
> > he wants to be anonymous)
> 
> Maybe. My ISP (when I can reach it) does that, and if you check
> past list messages (from more than a few days ago) you'll
> probably see (assuming that you get list messages in  undigested
> form) lines like:
> X-Info: This message was accepted for relay by
> 	smtp02.mrf.mail.rcn.net as the sender used SMTP authentication
> Whoopee -- anybody with a working printf can forge such a line,
> so that doesn't seem to do much.

Well, duh.  Obviously you need something stronger than a header field
which doesn't contain any way of verifying what message it was attached
to.  Take the input message, canonicalize it, hash that, sign the hash,
put the signature in the header field.  Not rocket science (though the
canonicalization step is a bit tricky to get right)

Keith