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

In <[email protected]> Keith Moore <[email protected]> writes:

>> The IETF, in the form of the IESG, has made it clear that they do not
>> want SPF going through a working group.  That is part of why MARID was
>> shut down.  They are pushing through both this SPF I-D, and the
>> Microsoft Sender-ID I-Ds, apparently without even an IETF last call.
>
> just as Informational or Experimental.  they can't standardize them
> without a Last Call.  even so a Last Call would still be advisable.

I agree that a last call would be be advisable.  I'll take your word on
information and/or experimental RFCs not needing them.  My reading of
RFC2026 section 6.1.2 seems to imply that both standard track (section
4.1) and non-standard track (section 4.2) I-Ds are handled the same
way.   But then, I'm not an RFC/IETF guru.


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

> -  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.  This looks pretty much
like a tautology to me.


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


-wayne