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

"Mark" asked on behalf of the Council:


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


I _still_ feel that both the logic and the vocabulary of Neutral (2.5.2) and 
Pass (2.5.3)  are wrong, and I refuse to chose between the two options you 
offer.
In my view:

    A Neutral is the sender saying:  "I do send mail from this IP, but there 
may also be mail coming
    from this IP which I did not send".

     A 'Pass' is the sender saying: " I send mail from this address, and I have 
confidence that
     everything that comes from this address and claims to be from me is, 
indeed, from me."
The _only_ difference between these two policy statements is the sender's 
declaration with the 'Pass' that he trusts the MTA using the IP not to permit 
forgeries. With 'Neutral' he declares that forgeries are possible.
The wording of the draft, and of the alternative you offer, is crazy and 
confusing.
Look again at the wording of Neutral in the draft:
   The sender doesn't " know whether the IP address is authorized or not. "

The problem with the wording / logic is that it is not the IP which is 
authorised, it is the sending of any particular message by that IP which may or 
may not be authorised.
In _both_ Neutral and Pass the IP is authorised to send - all of the time. It's 
just that in Neutral it may _also_ do un-authorised things _as well_.
The proposed change you ask us to vote on is trying to use the words 
'authorised' and 'authentic' to distinguish these two cases. You end up abusing 
the normal use of the word 'authentic', getting into deep water by implying 
something about the authenticity of the message itself, and still not 
communicating the true distinction between the policies.
My proposed wording is the following:
-----------------------------------------------------------

2.5.2 Neutral

The domain owner has stated that the IP is authorised to send mail on behalf of 
the domain, but the IP may also send mail claiming to be from the domain which 
was not authorised by that domain. It is therefore not possible to use this test 
to draw a conclusion about any specific message. A "Neutral" result MUST  be 
treated exactly like the "None" result; the distinction exists only for 
informational purposes.
2.5.3 Pass

A "Pass" result means that the domain owner asserts that they have confidence 
that all mail sent from this IP and claiming to be from the domain was, indeed, 
authorised by the domain.  Further policy checks, such as reputation, or black 
and/or white listing, can now proceed with confidence that the use of the 
identity was authorised in every case..
------------------------------------------------------------------

Actually, I also disagree with the phrase: 'the distinction exists only for 
informational purposes' in the Neutral result.
The Neutral policy is a necessary construct when used in association with e.g. 
"-all". It narrows down the possible source of forgeries from the entire 
Internet (which is the situation with "None") to just the identified MTA.  This 
distinction is surely far more than 'Informational', and Neutral is _essential_ 
in constructs such as this.  Just delete the clause after the semicolon if you 
agree with me.
------------------------------------------------------------------

To finish - a note about the great 'cross-user-forgery' issue.

Some people seem to be suggesting that the 'Pass' definition in the spec. should 
in some way warn the recipient about this possibility, or that the result of 
'Pass' cannot be trusted without some independent means of knowing if 
cross-customer forgery is actually being prevented by that MTA.
Come on guys! Stick to the architecture and _believe_.!

This is the _Sender's_ policy. It is the _sender_ declaring his belief about 
what comes out from the MTA which he has chosen and authorised.
Iff  (if and only if) the sender trusts the MTA to be preventing cross-customer 
forgery will the policy be Pass. That's what Pass is saying: "I trust this MTA 
not to permit forgeries."
If the sender does not know whether or not the MTA which is acting on his behalf 
will prevent forgeries, he can only publish Neutral. That's what Neutral means: 
"I do send from here, but I don't trust it not to permit forgery as well."
That's the senders belief, that's the sender's policy.  End of story.

Putting into the spec, as some have suggested in the last few hours, that 
recipients might nevertheless like to downgrade a Pass to a Neutral just in case 
the sender has got it wrong is crazy. If the sender gets it wrong it's his 
problem.
What I would recommend is a very strong caution in the spec, or perhaps in a 
BCP, making sure that senders do ensure that they have fully understood and 
evaluated the cross-customer forgery potential before deciding to use Pass, but 
once they have done that - that's it! Trust them.
If we find that senders can't build up enough trust in their MTAs to be able to 
use Pass with confidence, then we may need some more protocol+technology to 
solve the problem. In fact, during the MARID process, I did propose a scheme to 
address almost the same problem. But don't water down this spec. to cope with 
the uncertainty.
Hope I have not strayed too far off the topic.

Chris Haynes