...... Original Message .......
On Wed, 18 May 2005 01:12:56 +0200 Julian Mehnle <bulk(_at_)mehnle(_dot_)net>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
If PASS means authorized, but not necessarily authentic, then I don't
think SPF mail from is a suitable basis for reputation.
If PASS means authorized and should be treated as if it's authentic,
then you can use if for reputation.
I think you're missing what authorization actually means.
"1.2.3.4 is authorized to use example.com as the HELO/MAIL FROM identity
when sending mail."
...means nothing other than...
"If 1.2.3.4 sends mail with example.com as the HELO/MAIL FROM identity,
you can hold the owner of example.com responsible."
I think that semantics aside, we agree.
This is exactly how PASS should be viewed. This is exactly why it is
imprudent to give a PASS to Mail From a shared MTA that doesn't prevent
cross-customer forgery.
There you have it. And what does "authentic" mean other than "I know who
takes responsibility for it"?
Besides, the concept of perfect authentication is entirely virtual because
my trusted systems can always be hacked or suffer some other bad fate that
kills their integrity. Does this mean I don't have to take responsibility
for what the compromised systems did? No, it doesn't, at least not as far
as spam is concerned. Reputation services won't care about me not being
personally responsible, they'll just blacklist my systems anyway. And it
really couldn't be any other way.
Yes. The concern I have is systems behaving as designed, but with a whole
in them. Although the scope is much narrower, the situation with shared
MTAs is akin to using an open relay in an SPF record. It's asking for
trouble.
I think that the current (and long standing) language of the various
specs can and has been interpreted both ways.
I agree, and I also agree that this should be changed. I'm just not sure
yet how.
Stuart D. Gathman wrote:
Scott Kitterman wrote:
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.
[...]
PASS is meaningless unless it is option b - so that is the only option
I can support. A NEUTRAL result already gives you the equivalent of
option a.
No, "Neutral" is _not_ some kind of "SoftPass". "Neutral" means "I won't
tell you whether I have authorized this system to use my identity when
sending mail". Yes, I know this sounds stupid, but that's what some
people want to be included in the specification, so there you are.
And, again, I don't think it makes much sense to distinguish between
"authorized" and "authentic" in practice. SPF policies are all about
taking responsibility for certain mail, and this is what actually counts.
Just a minor change from what I suggested as b above... How about this:
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail with
the given identity and that the message should be treated as authentic[pick
a different eord here if you want, just don't say authorized again.].
Further identity based policy checks, such as reputation, or black and/or
white listing, can now proceed with confidence in the identity.
I suggest ...should be treated as authentic because as you discussed above,
just because it ought to be authentic, doesn't mean it is.
Scott K