spf-discuss
[Top] [All Lists]

Re: Request for Input on the meaning of "pass".

2005-06-03 04:28:00
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark wrote:
Julian Mehnle wrote:
But that's not what a domain owner would have to do. Instead, he would
assert: "I, the domain owner, trust AOL not to allow anyone to use my
domain for whose actions I will not accept responsibility with regard
to my domain's reputation",

But here you shift the original SPF "pass" semantics of "I allow AOL to
use my domain" to "I trust AOL not to allow anyone (else) to use my
domain". Do you not see the great difference?

Yes, of course I do see the difference.  I just do not see what the 
practical usefulness of claiming the former but not the latter is.

Yes, theoretically, it keeps the domain owner from having to accept 
responsibility... no, let's instead say: bear reputation for messages that 
used his domain but that he did not send (the cross-user AKA cross-domain 
forgery case).  But in practice, this is not meaningful, because a domain 
owner can always claim: "But AOL's MTA just allowed some other AOL user to 
use my domain for his abuse, so don't hold my domain responsible, ok?"

On the other hand, claiming the _latter_ means that the use of a domain in 
MAIL FROM _can_ be considered authentic after an SPF "Pass".

Also, Wayne and others already sort of admitted that many receivers will 
assume the domain owner to be responsible _anyway_, even if the spec just 
says "... can now proceed with confidence in the legitimate use of the 
identity, oh, and please do not construe this as willingness of the 
identity owner to accept unjustified bounces (in the cross-user forgery 
case), or to generally bear any reputation for the messages sent."

So why do we not go the rest of the way and admit that "Pass" must mean 
that the domain owner trusts the MTA not to allow forgeries or accepts 
responsibility (bears reputation, accepts unjustified bounces) for the 
"unauthentic" cases otherwise?

The former just makes AOL authorized to inject mail with the given
identity. The latter goes far further, and makes the rather bold claim
that AOL has added to its SMTP infrastructure to prevent the misuse of
your domain by any of its other clients

Not exactly, it doesn't mean the MTA has to be secure.  It means that
_if_ the MTA is not secure, the domain owner will not say "It's not my 
fault! Don't blame me or my domain."

What I am saying is that, unless we want to overload "Pass" with the
meaning of "Neutral" (and then consequently get rid of "Neutral"),
there is no meaningful difference between...
| The owner of domain X authorizes IP address Y to use the domain X.
....and...
| The owner of domain X declares that every use of domain X
| by IP address Y shall be considered authentic.

I fail to see how 'neutral' plays into this;

"Neutral" means "I cannot or do not want to assert whether the IP address 
is authorized or not".  Since _I_ think that the two statements quoted 
above are practically equivalent, it seems to _me_ that some want to make 
the case described by "Neutral" into a case described by "Pass".

'neutral' claims neither of the two.

(Of course it doesn't.)

Besides, to me, there is really a world of difference between the two
statements already -- of which I support the first.

It has been explained to me by you and others that the difference was 
that... (see above):

...theoretically, the former statement keeps the domain owner from having 
to bear reputation for messages that used his domain but that he did not 
send (the cross-user AKA cross-domain forgery case).

But in _practice_, this is not meaningful, because then the domain owner 
can always claim: "But AOL's MTA just allowed some other AOL user to use 
my domain for his abuse, so don't hold my domain responsible, ok?"

And of course receivers will not accept this excuse and will hold the 
domain responsible anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCoD7AwL7PKlBZWjsRAvWzAJ0fY/1fMe/I3SihOpjXPGSzk3BESwCfd2Et
RSsbaY4Fw3Zblp34Mdms1Ys=
=3ydD
-----END PGP SIGNATURE-----