-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Mark
Sent: Thursday, June 02, 2005 1:21 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Request for Input on the meaning of "pass".
There is an issue regarding "pass" that we, the SPF Council, would like to
have your opinion on.
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.
In a nutshell, we would like to solicit your position on whether SPF can
be said to 'authenticate' the identity on "pass", or wether the connecting
client can only be considered 'authorized' to use the identity. Where
"authentic", in this context, means: "not forged".
Roughly, there are two main positions:
1): If the cross-user forgery thing is the only issue that keeps us from
asserting authenticity, we should instead find a way to make it clear to
publishers that they must assume responsibility if they authorize an MTA.
Therefore, the following wording remains applicable:
"can now proceed with confidence in the identity".
2): Even if a publisher chooses to authorize an MTA patched to prevent
cross-user forgery, then, without adding to the spec, there is still no
way for a receiver to know this; so that "pass" can really only mean:
"can now proceed with confidence in the legitimate use of the
identity".
In the same vein, we would also like to know whether the domain owners
among you assumed that receivers would take SPF-verified identites as
'authentic' (position 1) or just as 'authorized' (position 2) when they
published their policies.
We feel the issue is important; especially so if reputation-checks are to
become a more pronounced part of SPF.
What "pass" really means/implies touches upon the very core of SPF.
Therefore, instead of ruling on it immediately, we decided to bounce the
issue back to the spf-discuss forum, along with the cordial request for
you to speak out on the matter at your earliest convenience. Preferably
before Monday.
The matter was discussed by the SPF Council itself; and you can review the
log of the last Council meeting at:
http://www.schlitt.net/spf/spf-council/2005/06/02_irc_log.html
Thank you for your cooperation.
- Mark
First I would like to comment that I think that the discussion at
yesterday's council meeting reflected exactly the issue that I wanted
discussed.
In my opinion, all of the SPF specs have been somewhat hesitant about this
issue all along, so it's no surprise that people have a divergent view.
My view is close to #1. I think that the
http://spf.pobox.com/spf-draft-200406.txt definition probably had it best
when it said:
Pass (+): the message meets the publishing domain's definition of
legitimacy. MTAs proceed to apply local policy and MAY accept or
reject the message accordingly.
With a forward reference to the new paragraph on cross MTA user forgery and
the changes to Neutral that were, I believe, decided yesterday, I think
that's sufficient. Let the domain define what it's definition of legitimacy
is. People have a different level of concern about cross MTA user forgery.
Whatever we pick, we just need to be clear about what people should pick and
not leave glaring holes in between Neutral and Pass.
I do think that the spirit of what SPF has been after has been clear since
the SoftPass/HardPass debate I sparked last year. I just think the spec
needs to clear.
Scott Kitterman