[Top] [All Lists]

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

2005-03-03 20:38:43

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

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.


<Prev in Thread] Current Thread [Next in Thread>