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

On Fri March 4 2005 00:19, Keith Moore wrote:
> >> Well, current SMTP specifications allow for anyone to use any domain
> >> in either the rfc2821 identities, or any place in rfc2822.  All
> >> authentication schemes intend to change that.
> >
> > AFAIK, none of SSL, TLS, or SMTP AUTH make any such change.
> 
> well, it depends on what you mean by "being able to use any domain"

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.
To be precise, I mean that when sending mail, I need to specify
a mailbox in the return path which uses my ISP's domain name
(because that (my mailbox) is where legitimate bounces should go)
and likewise in the From and/or Reply-To and/or Sender fields of
the message header -- regardless of my IP address, and regardless
of the ISP that I happen to be sending the message(s) via, if I
use an ISP's SMTP relay, and regardless of whether I choose to
use such a relay (e.g. to store a single copy of a message for
distribution to multiple recipients) or to directly connect to
the designated MX host(s) for the message recipient(s).
 
> for instance, SSL/TLS server certificates do not allow the server to 
> [convincingly] claim to be any domain it wants to be within the SSL/TLS 
> protocol.   they don't try to restrict the server's domain name 
> according to the IP address,

or the client's!

> and they don't inherently impose  
> constraints on what domains the protocols layered over SSL or TLS use.  

> in the case of email, it's generally not 
> reasonable for an SMTP client or server to expect the domains in EHLO, 
> HELO, MAIL, or RCPT to match those used at the SSL or TLS layer, 
> because third-party relaying is an extremely useful feature of the SMTP 
> architecture.

And SMTP AUTH provides for SMTP session authentication independent
of transport layer security, and without imposing unreasonable
restrictions on IP address or domain name.