Julian Mehnle wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll give my opinion not as a council member, but as an individual.
Mark wrote:
In a nutshell, we would like to solicit your position on whether SPF can
be said to 'authenticate' the identity on "pass", or wether the
connecting client can only be considered 'authorized' to use the
identity. Where "authentic", in this context, means: "not forged".
Roughly, there are two main positions:
1): If the cross-user forgery thing is the only issue that keeps us from
asserting authenticity, we should instead find a way to make it clear to
publishers that they must assume responsibility if they authorize an
MTA. Therefore, the following wording remains applicable:
"can now proceed with confidence in the identity".
It may have become apparent that I subscribe to the idea that SPF "Pass"
should assert _authentic_ use of the identity, and that only identity
owners can (and must) define what constitutes a "forgery" of their
identity.
Therefore, where sufficient security against forgery (as defined by the
domain owner) is difficult to achieve (such as with shared MTAs that do
not protect against cross-user forgery[1] -- are there other cases?),
domain owners should choose either to accept responsibility for
illegitimate uses of the domain name, or not to authorize insecure MTAs.
I think it is reasonable to require domain owners to choose between these
two options. And if we do that, we can define "Pass" to assert
authenticity.
I agree with you, and I would love for that to be the way it is.
Unfortunately, most MTA's do not prevent cross customer forgery (CCF),
and therefore we need to put prevention of cross customer forgery into
the SPF spec as a MUST or forget that goal because its not obtained
explicitly and is too drastic to be assumable.
In the same vein, we would also like to know whether the domain owners
among you assumed that receivers would take SPF-verified identites as
'authentic' (position 1) or just as 'authorized' (position 2) when they
published their policies.
To be honest, I do not use shared MTAs, therefore it is easy for me to
accept responsibility for the use of my domain names.
Me also.
Also, I would like
for receivers to be able to treat "Pass"ed uses of my domain name as
authentic.
Me also.
But SPF is for everyone, not just those who are resource wealthy.
We feel the issue is important; especially so if reputation-checks are
to become a more pronounced part of SPF.
Accepting responsibility for the authorized use of a domain name means that
reputation can be applied. If we choose for "Pass" not to assert
authenticity, we cannot honestly suggest that people base reputation on
"Pass"ed domaines. I think that would be a great loss in the value of
SPF.
I agree with you. And cross customer forgery (CCF) should be prevented
even if SPF never becomes a standard (de facto or IETF). But that does
not mean that CCF prevention will ever be adopted, there is a lot of
work to be done to make that happen.
Terry
References:
1.
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02pre1.html#cross-user-forgery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCn0dqwL7PKlBZWjsRAt9eAJ9I0QiwByF2+wNkQKADaebNae/jlQCg12m7
JuuBv4XB0rfclGFb/yDGxiM=
=aB1x
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085