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

[Douglas Foster <[e-mail]>]

The chairs can introduce another topic whenever they want.   This does not
seem like a pre-requisite to any of the other pending topics.

My interest is interoperability:    We want recipient requirements and
sender compliance measures to align.

RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM
together.  An argument can be made that this is not necessary:   SPF
MAILFROM shows that the server is authorized to send messages for the
specific domain in the MAILFROM, while SPF HELO says only that the server
is authorized to send message for the server domain and an unknowable set
of other domains.  Therefore a PASS from SPF MAILFROM should make SPF HELO
unnecessary and redundant.    Does either the DMARC document or the SPF
document say this anywhere?

RFC 7208 can be misunderstood to suggest that SPF MAILFROM and SPF HELO are
equivalent and interchangeable, which they are not, for the reason just
mentioned.   Shouldn't we also make this clear?

Senders are motivated to ensure that their mail is delivered, which makes
them interested in all of the factors which can maximize delivery and
minimize rejection.    SPF HELO might be one of those reasons.   Do we
mention this as an additional measure that senders might want to consider,
or do we keep silent?

Todd's assertion is that SPF HELO will cause an excessive number of false
positives.   I share Todd's expectation that this will be true, but I have
no data on that point yet.  I am just beginning to collect that data,
because it seems like an interesting question.

A second assumption is that no significant recipients are evaluating SPF
MAILFROM and SPF HELO together in a way that would be of interest to
senders. This may also be true, but I don't think this is something that
can be tested.

A third assumption is that the current behavior related to SPF HELO will
continue indefinitely.

To maximize interoperability:
- Recipients can be encouraged to ignore SPF HELO as unnecessary and the
likely source of false positives.
- Senders can be encouraged to ensure SPF HELO compliance to prevent false
positives.

That interoperability outcome seems worth some comment in our final
document, since it created the confusion that led to ticket #1.

The original question and these comments are exclusively about the SPF side
of the DMARC evaluation, which presumes that the DKIM signature is missing
or invalid.   I was neither proposing a new block algorithm nor proposing a
new allow algorithm.  But I do think that we need to anticipate how people
are likely to use our documents, with the goal of minimizing incompatible
interpretations.   Ale's question demonstrates that such interpretation
problems are possible, even on a small and well-informed sample set.

DF

DF

On Mon, Feb 8, 2021 at 9:50 AM Todd Herr <todd.herr=
[e-mail]> wrote:

> 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.
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>