"Breaking long-standing practice" is not the fault of the domain owner policy, it is the fault of DMARC being oversold and the DMARC result being applied by the evaluator in a way that undermines the interest of his own recipients.
Consider the possible causes of DMARC FAIL: Failures that can be prevented by the domain owner: 1) DNS error: omission or typographical error which causes FAIL or PERMERROR on both methods 2) Domain controlled server error: Failure to apply a DKIM signature, if the message is forwarded by the initial recipient 3) Service provider server error: failure to apply a DKIM signature, when Mail From uses the services domain Failures which the domain owner cannot prevent: 4) Message which is forwarded with changes, causing loss of both SPF alignment and DKIM verification 5) Message which originates on behalf of a domain member, outside of domain control, producing an acceptable impersonation 6) Malicious and therefore unwanted impersonations "p=reject" can only assert that the first three failure modes have been prevented, although experience shows that evaluators cannot always believe that assumption. Our document should be clear that p=reject or p=quarantine should not be used until all messages are believed to have a valid DKIM signature, because any message may be forwarded. However, the domain owner has no reliable way of knowing whether conditions 4-5 will ever apply, and applicability will be different for different recipients. Therefore, the burden falls on the recipient's evaluator to determine whether "p=reject" is caused by condition 6 or by one of the other conditions. Telling domain owners not to use p=reject is not the solution; the real solution is for evaluators to act wisely, and to review other available evidence carefully. Our document can provide guidance on wise use, starting with a discussion of possible failure modes. Doug On Wed, Aug 10, 2022 at 9:03 AM Barry Leiba <barryle...@computer.org> wrote: > > This list saves From: in X-Original-From:. It'd cost nothing to switch > to > > Author: instead. The arc list, however, saves it by appending to > Reply-To:. > > The point is to agree on a field name. Author: seems the most promising > one. > > > > Now, everybody complains about how From: munging ruined their habits. > Yet, the > > minimal effort required to restore it is deemed out of the question. It > sound > > like a tantrum, an excuse to hold that DMARC ruined the MHS and MUST NOT > be used. > > Yeh, I have to take serious issue with this: > It's not a "tantrum" to say that it's not reasonable to require all > mailing list software and every mailing list in the world to change > what's worked for decades in order to work around a problem caused by > use of a new standard in a way that new standard wasn't designed to be > used. > > I want to see the Proposed Standard version of DMARC to make it > abundantly and normatively clear what the intent of p=reject is and > when it should and should not be used (whether that be at a SHOULD NOT > or MUST NOT level is something we need to decide). It's not a > tantrum; it's how we write standards: we avoid having them break > long-established use whenever we can. > > Barry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
