-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Taroli wrote:
Julian Mehnle wrote:
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.
But isn't an administrator, by virtue of including an MTA (by whichever
criteria they use) in their domain's SPF RR, explicitly taking an action
that communicates trust in that MTA?
Exactly, this is what authorizing MTAs in one's SPF record must mean. This
isn't reflected well in the current specification's definition of the
"Pass" result code[1]:
| 2.5.3. Pass
|
| A "Pass" result means that the client is authorized to inject mail
| with the given identity. Further policy checks, such as reputation,
| or black and/or white listing, can now proceed with confidence in the
| identity.
Therefore I think we should adopt Scott Kitterman's proposal:
| 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.
Wayne, what do you think?
References:
1.
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#anchor9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCj02fwL7PKlBZWjsRAv/1AKDvGyJ14VEdS5RU3Utsf3GEDxZ3KACg6Oby
5NCgn7CFNE3E7coiM8q7w+E=
=a62e
-----END PGP SIGNATURE-----