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.  That is a fundamental flaw in SPF; it not only
makes the mistake of trying to tie mailbox domains to IP addresses,
it ties *inbound* mailbox domains to *outbound* IP addresses (at
least with the usual MUAs that use that domain in EHLO/HELO).
 
> 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.
 
> 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.  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.

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

About the only workable authentication scenario that I can
imagine that is consistent with email architecture would
involve:
1. some sort of PKI
2. use of secure MIME (S/MIME or PGP/MIME)
At each hop, the DATA would be MIME wrapped and signed, then
that wrapped MIME body would have trace header fields prepended
and would be sent to the next hop.  The receiver would consult
the PKI to verify the previous hop, then unwrap the DATA and
repeat for the next hop (or return a failure response).

Or something like that.

The weak links are of course the PKI, and how the sender indicates
a key to the next hop.  The key could be passed in a new trace field,
or an extension to the Received field.  The PKI could be implemented
via DNS or a similar mechanism, or an established PKI could be used.
Of course, both senders and receivers would have to be modified to
use such a mechanism, it use would have to be negotiated via some
sort of ESMTP keyword and there would have to be broad agreement on
PKI.  Negotiation and fallback means that a sender would either
need to be able to sign and wrap messages on the fly, or pre-sign
and wrap and choose pre-signed or plain DATA depending on
negotiation.  The PKI would need to reasonably accessible to
individuals (so that their MUAs can be configured to sign and wrap
messages with a key associated with the sender).

The MIME wrapping would be so-called triple-wrapped MIME, and
I've some time ago expressed my doubts about significantly
deployed and functional implementations of that.

Obviously, such a mechanism isn't going to spring up and become
widely deployed overnight; it might simply be best to wait for a
next-generation mail system that can be designed with an
authentication mechanism up-front.