spf-discuss
[Top] [All Lists]

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

2005-06-03 03:18:36
On Fri, Jun 03, 2005 at 05:29:37AM +0200, Julian Mehnle wrote:

SPF authorizes IP addresses.  Of course this does not mean that
SPF authenticates IP addresses.  SPF is supposed to authenticate
_domains_.

That's where we disagree.  SPF _authorizes_ hosts to use domains.

I never said anything to the contrary.

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.

SPF is not: is this example.org
SPF is not: is this mail.example.com
SPF is:     is mail.example.com allowed to say ...

I never said anything to the contrary.

<quote>SPF is supposed to authenticate _domains_.</quote>

This matches either the first or the second from my list. In both
cases I say "SPF is not".

| 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.

(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.

Would you agree that the definition of "Pass" should talk about having to 
accept responsibility (in terms of reputation)?

yes.

Sorry, but you are just jumping to a conclusion without supporting
your claim.  And I just don't agree with the steps necessary to fill
the gap you jump over.

I think there is a misunderstanding:

What I meant by "apply reputation" was "create reputation by judging the 
abusiveness of a message".

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.

There is no need, at all, to know where the mail originates.

Are you sure?  Don't you think most domain owners would want receivers to 
be sure of the MAIL FROM's authenticity before creating bad reputation for 
the domain?

No. See above.

If you want to know, for 99.9998 percent sure, that it came from
example.org you will need authentication and thus you will need
something (much) stronger than SPF.

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.

With SPF, you create a chain of trust and the receiver can use
the amount of trust to say something about the domain name.
We're talking reputation here.

If shared-mta.foo.org does not prevent cross-customer forgery, and some 
other user at foo.org sent the message, did it still "come from 
example.org"?

You really didn't read that paragraph, did you?

If you want to know, for 99.9998 percent sure, that it came from
example.org you will need authentication and thus you will need
something (much) stronger than SPF.

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.

Does it matter if it was or was not example.org submitting that
message? No.  example.org trusts mail.example.com

Making it explicit, this trust means: "example.org trusts
mail.example.com not to allow cross-customer forgeries".  Which is the
same as asserting authenticity.

NO I DO NOT SAY THAT.  Don't put words in my mouth.

Of course you did not say that.  You did not say anything about what you 
mean by "trust", so I was forced to guess.  My apologies.  Thanks for 
explaining now what you mean by "trust".

I have given an example, twice, where I strongly disagree with you
about this cross-customer forgery statement you make.  Yet you still
use your opinion to say what my words mean eventhough it is clear that
this is not what I am saying.

I think it is time I'm going to end this discussion.
Alex