Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Todd Herr <[e-mail]>]

On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
[e-mail]> wrote:

> "We have a lot of other topics" is the wrong reason to call for
> consensus.   The important question is "Ale, have we addressed your
> concerns?"
>
> I agree with many that for DMARC, our primary interest is whether SPF
> validation of MAILFROM produces a PASS.
>

That's only partially correct. For DMARC, the SPF validation of MAILFROM
must produce a PASS and the identifier must align with the RFC5322.From
header domain. Absent both the PASS verdict and the alignment, the
<policy_evaluated> section of the aggregate report will show "fail" for
SPF, even if the <results> bit of the <auth_results> section shows "pass"
in the <spf> sub-section.


> However, I also see that a cautious recipient may choose to also require
> SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
> on these multiple criteria increases the confidence in the PASS result, but
> also increases the likelihood of ambiguous results and false rejects.
> Therefore:
>  - Recipients need to be cautious about enforcing rules so strictly that
> sender configuration errors produce unwanted disposition decisions.
>  - Senders need to be careful to ensure that they configure their policy
> to produce both SPF MAILFROM = PASS and SPF HELO=PASS.
>

The likelihood of a HELO identifier both passing an SPF check and aligning
with the RFC5322.From identifier is, I would venture, so small as to be
immeasurable for shared services such as ESPs, mailing list servers, and
the like. Perhaps they could eventually be convinced of a need to publish
SPF records, but that wouldn't do much of anything to change the
<policy_evaluated> results for DMARC. Getting an SPF pass verdict alone for
these identifiers isn't enough to alter the DMARC validation results; the
identifiers must align, too. From a practical standpoint, I don't believe
SPF MAILFROM=pass/SPF EHLO=fail would be useful information to mailbox
providers for the significant volume of mail routing to their customers
from shared services; I get quite a lot of such mail to my Gmail mailbox
each day, wanted mail that is correctly routed to my Inbox.

Beyond all that, though, SPF can fail for both the MAILFROM and the EHLO
identifier on any given message, but if the message is DKIM signed in a way
that aligns with the RFC5322.From domain and the DKIM validation check
passes, then the message will correctly be described as having gotten a
DMARC pass verdict. We've spent quite a lot of time on this list discussing
authentication checks that can, by themselves, result in a DMARC pass
verdict, but that cannot, by themselves, result in a DMARC fail verdict. A
message has to fail SPF validation/alignment checks and DKIM
validation/alignment checks in order to fail DMARC. I am not suggesting
that the DMARC spec be updated to require that both SPF and DKIM both pass
and align in order for DMARC to pass, because while I believe it to be best
practice for senders to align both SPF and DKIM identifiers, I believe it
would cause too much breakage in existing running code and sender
configurations to be worth it to mandate such things.


> Altogether, I think some wordsmithing is needed to communicate those
> points.   I do not have such wording at this moment, but will begin
> thinking about what I would propose.   Perhaps those who are anxious to
> move on will be able to produce text sooner.
>
> I have also raised a concern about the inadequacy of reporting these
> results, since "Recevied-SPF: pass" is currently a compliant header.   We
> can defer this issue to a later ticket, but we need to be thinking about
> the problem.   If this requires no change, I would like some discussion of
> why that might be the case.
>
>
>
What the message recipient does with all this authentication information is
left as a local policy decision, a decision that is likely to be made using
more data points than just the SPF, DKIM, and DMARC validation verdicts.
The DMARC spec does not mandate that a message passing DMARC checks be
accepted, nor does it mandate that a message failing DMARC checks be
rejected, even in the relevant policy published by the domain owner is
"p=reject", and I am absolutely not suggesting that the DMARC spec be
written in such a way as to mandate such behaviors. In my opinion, the text
that should appear in the DMARC spec to sum up these points is "A DMARC
pass verdict means only that the message can be reliably associated by the
recipient with the identity on which the DMARC validation check was
performed, and a DMARC fail verdict means that it cannot be so associated."

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*p:* 703.220.4153

`

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.