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

>> all of the authentication schemes I've seen suffer from one or both of
>> these problems:
>>
>> -  trying to do more than is reasonable for that particular approach
>
> This seems to be a pretty subjective criteria.  I suspect that  
> reasonable people can disagree on what might be considered 
> "reasonable" for a particular approach.

yes, there will be some disagreement, but the opinions will often 
cluster in one general area, and you can get rough consensus on them.  
this does require engineering judgment.  it's not as if, for instance, 
there are objective criteria for how many DNS lookups are too many to 
use to validate an email address, but you'll get general agreement 
among most knowledgeable folks that there's a limit to how many lookups 
is reasonable, and those opinions will cluster around some compromise 
number.

>> -  trying to retroactively change how the mail protocol is used, or to
>> restrict future use of the mail protocol such that valid use cases
>> will no longer work
>
> 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.

it's tempting to respond that all of these authentication schemes are 
therefore "broken".  but that's so simple a statement that it's likely 
to be taken the wrong way.

part of the problem is that none of the existing fields in either SMTP 
or [2]822 are intended to hold an authenticated ID of the originator, 
with the possible exception of Sender, even that one isn't well defined 
enough (or consistently implemented enough) to use.  and for every one 
of those fields there are numerous valid use cases for that field not 
being an authenticated ID for the originator, even though you might 
want to authenticate the message.  we simply don't have a field for 
that purpose defined at present.  various authentication schemes try to 
work around that by constraining or overloading existing fields.  the 
goal in doing so is to ease deployment, but what it actually does is 
limit the scheme's applicability.

there are also subtle but important differences between authenticating 
the return-path value as the originator and assuring an MTA or 
recipient that the originator had permission to use that return-path 
value.  we don't want to do the former, we do want to do the latter.

similarly there are subtle but important differences between 
authenticating the From address as the originator of a message and 
assuring a recipient that the originator was acting on behalf of the 
address(es) named in the From field. we need to support both.

it's also important that the architecture _not_ constrain originators 
to send their mail via a particular submission service.  it's okay if 
this is one way that mail can get authenticated, not okay if this is 
the only way that mail can get authenticated.

it's essential to get these details right.

>> what we really need is a framework that allows multiple schemes to
>> coexist and work constructively together.  but that can't happen as
>> long as the schemes try to change the mail protocol in incompatible
>> ways.
>
> Many of the email authentication schemes that I know of can co-exist
> and even work very well together.  I'm not sure that this is the
> appropriate forum to discuss which ones can and can't, and why.

I think that with slight modifications most of the schemes that have 
been proposed can co-exist and work well together, and that the schemes 
together will be much more useful than any of the schemes alone.

And if this isn't the appropriate forum to discuss the individual 
schemes, it probably is the appropriate forum to discuss a framework 
that would let the schemes coexist with each other and with Internet 
mail as it's actually used.

Keith