-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
Julian Mehnle wrote:
Alex van den Bogaerdt wrote:
You say auth_enticate_ I say auth_orize_.
You say _domains_ I say _hosts_.
Yes, that's no contradiction.
It isn't? If you think you can intermix host and domain, if you
think you can substitute authorization for authentication (and v.v.)
at will, then I seriously believe we have a much larger problem
here than I already think.
How is saying...
| The state issues passports to people.
| (The state authorizes people to pass borders.)
...and...
| Border authorities check people's passports.
| (Border authorities authenticate passports.)
...a contradiction?
| Is mail.example.com allowed to say [this message was sent by someone
| at example.org]?
...is equivalent to...
| Is the identity claim MAIL
FROM:<(_dot_)(_dot_)(_dot_)(_at_)example(_dot_)org> authentic?
...isn't it?
Yes, it isn't.
Authentication leads to authorization. Authorization does not
necessarily mean authentication.
So here we are again. I'll try a different order of wording this time:
Just because the concepts of authorization and authentication are not
identical and SPF includes the concept of authorization, that does not
mean that SPF cannot also include the concept of authentication.
SPF is supposed to authenticate _domains_, based on the authorization of IP
addresses.
I still don't get what the _practical_ difference between my two statements
quoted above ("| Is mail...", "| Is the identity...") is supposed to be.
Perhaps I'm just dumb.
(Now we're making progress.) This is exactly why we need to make it
clear to domain owners that they should only assert "Pass" if they are
reasonably sure that abuse that uses their domain can only come from
themselves. Otherwise, people will assert "Pass" and then wonder why
they end up on black-lists, even though the definition of "Pass" only
said "host is authorized" and not "domain will accept responsibility".
_reasonably_ sure, yes. That is based on trust, not on authentication.
Authentication is all about trust. Border authorities could not
authenticate passports if they didn't trust the passport issuer, or if the
passport issuer didn't trust the person to which he issued the passport.
Would you agree that the definition of "Pass" should talk about having
to accept responsibility (in terms of reputation)?
yes.
Great! So do I.
You certainly cannot _create_ reputation without being sure that the
identity at hand can be considered authentic.
Would you agree to that?
No. It doesn't matter who sent the spam. If you authorize a host to
speak on your behalf and if that hosts sends spam, it is going to reflect
on your reputation. It doesn't matter where this message originated.
You vouch for a host -> your reputation is influenced.
Ok, so we are in agreement that "Pass" means being willing to take on
responsibility, reputation-wise, for the use of the domain.
Now, what does "who sent the spam" mean? If the domain authorized the host
to speak on the domain's behalf, and the domain even has to take on
responsibility, then is it not appropriate to say that "the domain (as an
entity) sent the spam"?
What do you mean by "it came from example.org"? If the policy for
example.org is "v=spf1 +a:shared-mta.foo.org -all", and the message
came from shared-mta.foo.org, does this mean the message "came from
example.org"?
SPF does not verify the complete path. You can only be sure that
it was sent by shared-mta.foo.org. If you want to be sure that it
came from example.org, you need something stronger than SPF.
What, for instance, would that be? PGP?
If you want to know that it really came from example.org you will need
something else than SPF.
If you want to know if example.org trusts shared-mta.foo.org you
can use SPF.
If you (a border authority) want to know if the state (the issuer of
passports) trusts a certain person to pass borders, you can use (check)
that person's passport. Does that not constitute authentication?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCoFG7wL7PKlBZWjsRAnaOAJ4yIWJkTkEYYyeh25RB9HdozZvmegCg7Ywv
Z7PN6rxHn6LwrIgd/xey19A=
=1fh5
-----END PGP SIGNATURE-----