On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely <[email protected]> wrote:
> 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:
> >
> > “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.”
>
>
> I like better the current wording.
>
>
> > 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.
>
>
> 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
> --
>
> 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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
