Subject: [dmarc-ietf] 7.1 SPF -ALL

From: Douglas Foster <[email-masked]>
Date: Fri, 11 Feb 2022 02:57:17 -0500

This section implies that publishing SPF -ALL is a risky move, which is
made worse by DMARC.   SPF -ALL is a only risk when (a) the message is
forwarded without MAILFROM rewrite and (b) the evaluator does not implement
DMARC.

Rather than telling senders to weaken their SPF policies, we need to make
it clear to evaluators that they should implement DMARC correctly.  Proposed
language for the second paragraph:

“By design, DMARC allows a verified and aligned DKIM signature to override
an unfavorable SPF result, including FAIL.    However, the full message,
including the DATA section, must be accepted before DMARC participation can
be determined and DKIM signatures can be evaluated.   Consequently, DMARC
evaluators SHOULD NOT use SPF results to reject a message prior to receipt
of the entire DATA section.”

When this was previously proposed, it was noted that some DMARC evaluators
consider the combination of SPF FAIL with a policy containing only "-ALL"
to be a special case which justifies early reject.  I think it is obvious
that if an evaluator does not wish to allow a DKIM override for that
situation, then the SHOULD NOT can be ignored.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Feb 2022 13:19:24 +0100

On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote:
> This section implies that publishing SPF -ALL is a risky move, which is made 
> worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded 
> without MAILFROM rewrite and (b) the evaluator does not implement DMARC.

My reading of Section 7.1 differs.  I see no risks implied in its wording.

> Proposed language for the second paragraph:
> 

I like better the current wording.

> consider the combination of SPF FAIL with a policy containing only "-ALL" to be 
> a special case which justifies early reject.  I think it is obvious that if an 
> evaluator does not wish to allow a DKIM override for that situation, then the 
> SHOULD NOT can be ignored.

SPF clearly suggests that receivers apply whitelisting broadly.  In addition, 
publishers can explicitly include ?exists:%{ir}.list.dnswl.org or similar 
reference to public whitelists.  Whitelisted is neither pass nor fail.

Of course, messages rejected before any DMARC processing takes place will not 
contribute to feedback reports.  Operators just have to be aware of it.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Fri, 11 Feb 2022 08:03:07 -0500

On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely <[email-masked]> wrote:

> made
> I agree with Ale. Further, it is not as if we are considering this in a
vacuum. Since originally being made public, DMARC has been widely
implemented and it has not been identified that this (early reject on SPF
-all) has been a significant or even an insignificant problem based on data.

Michael Hammer

---

From: Benny Pedersen <[email-masked]>
Date: Fri, 11 Feb 2022 17:19:50 +0100

On 2022-02-11 08:57, Douglas Foster wrote:
> This section implies that publishing SPF -ALL is a risky move, which
> is made worse by DMARC.   SPF -ALL is a only risk when (a) the message
> is forwarded without MAILFROM rewrite and (b) the evaluator does not
> implement DMARC.

+1

> Rather than telling senders to weaken their SPF policies, we need to
> make it clear to evaluators that they should implement DMARC
> correctly.  Proposed language for the second paragraph:

why spf -all when there exists nullMX ?

---

From: "John Levine" <[email-masked]>
Date: 11 Feb 2022 11:25:38 -0500

>-all) has been a significant or even an insignificant problem based on data.

A bare -all is clearly a special case, the converse of null MX, that
means no mail at all. I agree the current wording is fine.

R's,
John

---

From: Benny Pedersen <[email-masked]>
Date: Fri, 11 Feb 2022 17:28:25 +0100

> means no mail at all. I agree the current wording is fine.

nullMX is supported from all mta, but spf is lotto

---

From: Douglas Foster <[email-masked]>
Date: Fri, 11 Feb 2022 13:32:22 -0500

I don't see that the current language is in any way limited to the soecial
case of only -ALL.  I read it as a general warning.

On Fri, Feb 11, 2022, 11:26 AM John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Douglas Foster <[email-masked]>
Date: Sat, 12 Feb 2022 06:39:01 -0500

If early reject is not a problem, then perhaps this paragraph is not needed
at all.  If it is present, it needs to communicate correctly to everyone,
including the new cybersecurity student.   I see nothing in the language
which limits the warning to this one special case.   I read it as a broad
statement that any policy containing "-all": is likely to produce unwanted
behavior by some evaluators.  That broad statement is wrong, and is
particularly misleading when applied to DMARC.

I don't think the special case of a policy containing only "-ALL" needs any
comment in our document.  I also don't think we can say very much about it
without creating a layer violation, since the special case is not part of
RFC 7208.

Doug