On Tue, May 17, 2005 at 03:37:45PM -0400, Scott Kitterman wrote:
Here is the current definition:
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. Further policy checks, such as reputation,
or black and/or white listing, can now proceed with confidence in the
identity.
If I read the first sentence by itself, I think it means authorized, but not
necessarily authentic. Thus it would not be a suitable basis for reputation.
Agree, agree. Disagree.
The domain owner trusts the provider and so {c|sh}ould you. If the
domain is abused, more than once or twice, the domain owner is at
least as ignorant or as blackhat as the provider. In that case,
you don't care about the domain owner's policy as his reputation is
shattered. No authorization nor authentication will help, why would
you believe authentication if you don't trust him based on reputation?
By including the second sentence in the definition, I infer that PASS must
mean both authorized and authentic because that's necessary for reputation.
PASS means trust, see further below.
So, I think the paragraph as written is confusing. Now I don't know which is
the right answer. I think SPF has been back and forth about this over time.
I do think that we need to clear it up one way or another for the RFC. I
propose that the council pick one of two options (or some variation thereof):
a. 2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. Further determnination is required to
find out if the message is authentic before policy checks, such as
reputation, or black and/or white listing, can proceed.
b. 2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity and that the message may be treated as
authentic. Further policy checks, such as reputation, or black
and/or white listing, can now proceed with confidence in the
identity.
Option b comes close to MHO, except that I don't think "authentic" is
the right word to use.
If people want strong authentication, they should use strong
authentication. Authentication and trust are not the same.
Authentication leads to trust, not vice versa.
I think people are confusing authentication and trust, just
like they are confused between authorization and authentication.
I trust my provider and its customers not to forge my name. Should
a customer forge my name, I'm confident the matter will be resolved
and the customer will have to look for another provider. Should my
confidence be improper, I will have to look for another host to
authorize. Should I keep authorizing a host knowing it is being
abused (I am not talking hours or even days here...) I'm doing
something wrong and I should be hold responsible.
Nowhere in above paragraph I make a claim about authenticity of
a message, on the contrary. I do however express confidence in
my provider and am willing to put my reputation at stake.
I don't think there's much difference between "?ip4:..." and
"+ip4:...". In both cases either you do or you don't trust my
mail. Using "?ip4:..." might lead to a lower reputation, based
on the fact that I'd seem to willingly be using a host that has
a bad reputation; this may reflect on my reputation. However, if
no complaints are seen, my reputation will not be damaged but
there would also be no reason not to use "+ip4:...".
Alex