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