Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly

[Alessandro Vesely <[e-mail]>]

On Mon 22/Apr/2013 20:20:44 +0200 Murray S. Kucherawy wrote:
> On Mon, Apr 22, 2013 at 1:33 AM, Alessandro Vesely <[e-mail]> wrote:
> 
>>>> SPF does not separate algorithm from policy in the same way
>>>> that DKIM is separated from ADSP.  How can DMARC specify an
>>>> interface to the SPF layer if SPF does not provide for one?
>>>
>>> RFC5451 is a perfectly good interface.  It works fine for
>>> OpenDMARC, for example.
>>
>> Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned
>> as "pass" result'.  It is not clear whether that refers to the
>> result of the check_host() function rather than, considering
>> Section 4.2 "Local Policy Enforcement", the combined result of
>> check_host() and local policy up to that point in the
>> processing.
> 
> That's a bit off topic here, I think.

Not if we just aim at establishing whether such /kind/ of statements
can be made in a well defined manner.

> However, I don't think you're comparing the same things.  The SPF result is
> the result of check_host().  What local policy choice is made might be
> based on that and it might not, but that doesn't change what check_host()
> returned.

Correct, it is possible to refer to the result of check_host() for a
given identity.  But none of RFC 5451, VBR and DMARC do so.  Why?  I
think it would result in a too lengthy wording.  Perhaps, the wording
of Section 2.4 can be improved?  Let me try:

OLD:
 A mail receiver can perform a set of SPF checks for each mail message
 it receives.  An SPF check tests the authorization of a client host
 to emit mail with a given identity.  Typically, such checks are done
 by a receiving MTA, but can be performed elsewhere in the mail
 processing chain so long as the required information is available and
 reliable.  At least the "MAIL FROM" identity MUST be checked, but it
 is RECOMMENDED that the "HELO" identity also be checked beforehand.

NEW:
 A mail receiver can perform two SPF checks for each mail message it
 receives.  Each SPF check tests the authorization of a client host
 for using either the "HELO" or the "MAIL FROM" identity.  The
 possible results of each check are given in Section 2.6.  The
 primary SPF result is the result of of the check associated with the
 "MAIL FROM" identity; this result MUST be obtained if possible.  The
 secondary SPF result is the result of the check associated with the
 "HELO" identity; it is RECOMMENDED that this result be obtained
 beforehand, and it MUST be obtained if it is not possible to get the
 primary.

_Note_ that I'm not proposing that change.  I'm asking if a change
like that would clear this issue.

>> As a further example, Section 7.3 of RFC 5518 is formally ambiguous
>> too, because SPF could produce a "pass" result by validating the
>> "HELO" identity, and then VBR would be checked against a possibly
>> spoofed <reverse-path>.
> 
> RFC5451 includes a mechanism for the consumer to know which mode of
> SPF was used.  Why does VBR itself have to care?

VBR does not refer to RFC 5451.  It just says:

   When SPF is the validation mechanism, VBR's md= MUST be the same
   value as the domain name in the <reverse-path> address that is the
   first parameter to the SMTP MAIL command.

   A domain is valid for use with VBR only when the SPF process
   produces a "pass" result.

Admittedly, it takes a bit of malice to misunderstand that.  However,
someone blindly developing the specs could overlook it.