-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
SPF is about authorization. You are talking about authentication.
Authorization and authentication are two different things. Related:
yes, the same: no. Mix 'em up and you'll make it difficult to
understand.
True, they're two different things. The goal of authorization is to
prevent unwanted use of a service or resource. The goal of authentication
is certainty of identity, the subject being a person or a virtual entity
such as a DNS domain.
I think the RFC is pretty clear on what SPF is and does. [...]
You are right that the SPF spec talks of authorization only. Earlier
revisions separated the two concepts not so cleary. I supported the
clarification towards authorization purely for the sake of clarification.
However it cannot be denied that SPF is _not_ just about authorization,
but about authentication as well.
A significant portion, perhaps even a majority, of the SPF project
participants have had reputation systems based on SPF in mind since the
earliest stages of the project, and this implies authentication. Without
a doubt, many others have resisted the idea of SPF-based reputation and of
creating accountability through SPF, but for the most part this really
just hinged on the question of what "Pass" means and what levels of
assertion SPF would offer to policy publishers (hardpass vs softpass vs
neutral).
The introduction of accountability is inevitable in the long run, if not
for other reasons then simply because an increasing number of domain
owners _are_ willing to assert authenticity through an SPF-like system and
to accept accountability for the mail sent in their name, _provided_ that
this mail complies with the policies specified by them.
If you don't trust an ISP, publish `neutral'. But maybe you should
leave the ISP and find something you do trust.
Agreed absolutely.
Most people do trust their provider. That doesn't mean problems never
occur. But it does mean problems are expected to be solved, and will
occur less frequent than elsewhere on the net.
So perhaps indeed we need a "softpass". Others (like you) might say
instead that we need a "hardpass", because they consider today's "pass"
a "softpass". (And regardless whether a "softpass" or a "hardpass" was
added, it would have to be defined very thoroughly.)
If you want authentication, the minimum is some form of encryption,
like SES. Do not mistake SPF for something providing authentication.
This is a misconception. TCP provides authentic sender IP addresses
_without_ the need for encryption. What's "authentic" is a matter of
definition by a respected authority. If I say, "consider all mail with an
envelope sender of 'mehnle.net' to be authentic if it passes the sender
policy", then that's my choice and receivers will be happy to accept this
assertion.
PGP isn't any different in this regard, and it isn't fundamentally more
secure, either, because private keys can be stolen and crypto algorithms
can be broken, and *poof* suddenly all these fancy digital signatures mean
a shit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFEHJNwL7PKlBZWjsRAs6nAJ9QmgB7yLOo64043zBbICHDHLys5QCgt7YL
p44JxR8bMDV14Hm5MfzkBCY=
=jU2/
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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