On 12/3/20 8:21 AM, Todd Herr wrote: > On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins <[email protected] > <mailto:[email protected]>> wrote: > > > >> On 3 Dec 2020, at 06:03, Jim Fenton <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 2 Dec 2020, at 1:47, Laura Atkins wrote: >> >>> p=quarantine is quite useful, particularly for those folks who are >>> trying to get to a p=reject state. >>> >>> In practice, senders who publish p=none don’t find all of the indirect >>> mail flows as some mailing lists do nothing to transform the 5322.from >>> address for a p=none policy. Senders have found that when they switch from >>> p=none to p=quarantine pct=0 they regularly find mail that was not failing >>> for a p=none. >> >> I’m really confused by this. It sounds like the 5322.from address >> rewriting is creating additional errors that didn’t exist beforehand, and >> that’s the opposite of the intended purpose. Isn’t the purpose of rewriting >> the 5322.from address to change the domain to that of the mediator, which >> should redirect reporting to the mediator rather than the original sender? > > What I am trying to say is that as I understand it from the folks who > professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of > the deployment process. There are DMARC failures that go undetected in a > p=none situation but that is detected in a p=quarantine pct=0 situation. My > understanding was this was related to indirect flows through mailing lists > and how mailing lists are handling the header transformation but it’s > possible I got that piece incorrect. > > > Time was (and may still be) that there was a very specific type of mailing > list for which p=quarantine, pct=0 was required to get accurate DMARC > reporting, and that was for mail that transited Google groups. There've been > a couple of public discussions of the topic over on mailop, including a > thread from April 2018 with the subject of "DMARC p=quarantine pct=0".
p=quarantine pct=0 is a very useful strategy 1) It allowed us to find the mailing lists that don't munge from the From header - which would subsequently be problematic once we moved to pct=100 2) It allowed us to segregate the user complaints. With a large change initiative you need to reduce the number of uncontrolled variables at any one time. If we went straight to pct=100 then there would be a mix of people complaining about from munging mixed in with complaints about delivery. Confusion would ensue and the entire premise of DMARC would have been called into question. By using an incremental process it's easier to deflect people complaining about the Stage 1 problems after moving to Stage 2. 3) It allowed us to discover email receivers who ignore pct. It was annoying, but also a convenient gift in disguise, since it allowed us to innocently blame the receiver when non-compliant senders objected to the necessary DMARC adaptations. Jesse _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
