-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Authentication is the process of determining authenticity. Authenticity
means the genuine use of an identity (strictly: identifier).
Authorization is the declaration of legitimacy by some authority.
Authorization is strictly dependent on authentication, that is, without
authenticity, authorization is inapplicable.
(Now some may wonder how authorization, by that definition, can work on
seemingly unauthenticated identities such as IP addresses -- think of
hosts.{allow|deny}. In fact, IP addresses can be _implicitly_ authentic,
such as when taken from an established TCP connection, as in SMTP. But
IP addresses can very well be unauthentic, too -- think of UDP.)
See also the Wikipedia article on "Authentication"[1], which also explains
the relationship between authentication and authorization. It's really
not very complicated.
SPF, from a strictly technical standpoint, is a method for authorizing
(implicitly) authentic IP addresses to use a certain domain name as the
identity. This, in itself, is not equivalent to the authentication of a
domain. In order to gain real value from SPF with regard to reputation
systems, we need to somehow bridge the gap from the authorization of IP
addresses to the authentication of domain names.
The only practical and useful way to do this is to require the domain owner
to take responsibility for the cases where authorized IP addresses send
unauthentic (i.e. forged) mail, i.e. requiring them to declare full trust
in their outgoing MTAs.
Wayne Schlitt wrote:
* The term "authorize" is used throughout the document and appears
to generally mean both "authorize" and "authentic".
* Changing *just* the terminology in the "Pass" definition will
probably cause more confusion than it solves.
I agree, but I also think that getting the definitions of the meanings of
the individual result codes "right" is of utmost importance. In this
regard, I very much like Scott's wording:
| 2.5.3. Pass
|
| A "Pass" result means that the client is authorized to inject mail
| with the given identity. The domain used in the given identity
| accepts responsibility for messages from the client. Further
| identity base policy checks, such as reputation, or black and/or
| white listing, can now proceed with confidence in the identity.
To make things somewhat easier, in the -01pre7 draft, I have changed
the few places that use the term "authentic" to "authorize". These
references were almost always from recent changes.
That's ok for now, but I really think we should get all of the wording with
regard to "authentication" and "authorization" right in the final spec.
I'd even volunteer to create a patch if nobody else wants to do it.
References:
1. http://en.wikipedia.org/wiki/Authentication
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCjhbrwL7PKlBZWjsRAoRDAKCEV+HAXg2Ny5LIkfMcmDd4Tf5MMwCghm5R
ECl7FQ/nQHuBqE+mf3fkbCg=
=b+96
-----END PGP SIGNATURE-----