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
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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, (continued)
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Keith Moore
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt,
Keith Moore <=
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Keith Moore
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Keith Moore
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Keith Moore
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Tony Finch
- Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt, Charles Lindsey
|
|
|