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 On Fri, Feb 11, 2022 at 8:03 AM Dotzero <[email protected]> wrote: > > > 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
