In <0619b0ece984ef7b6a4d683fc74ac482(_at_)cs(_dot_)utk(_dot_)edu> Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> 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