I disagree with the idea of making p= optional. My perception is that DMARC has been advertised to the ecosystem as a way for domain/brand owners to request specific treatment for mail that claims to be sent on behalf of a domain but that fails authentication checks. It's couched as a request for treatment because we already see frequent cases where the request is not honored, for example where a p=reject policy receives a disposition of quarantine; I've always believed this sort of thing to be due to the mailbox providers not exactly trusting the domain owners to fully understand the ramifications of their policy statement, and rather than do what's asked, the receiver takes the safer route to avoid the chance of a massive rejection of a legitimate mailing that had broken authentication for whatever reason.
Making p= an optional tag, even with the default of p=none, I believe would further erode receiver confidence in DMARC policy statements, simply because publishing a record with no p= tag provides no evidence that the domain owner has given any thought whatsoever to their policy statement. On Thu, May 21, 2020 at 5:12 PM Scott Kitterman <skl...@kitterman.com> wrote: > Agreed. I don't think this is controversial. > > Also, I don't see a problem with making the p= tag optional (with an > inferred > value of None if not present). This is consistent with an existing SHOULD > in > RFC 7489 and appears to be broadly supported in existing implementations. > > I'd propose we close this ticket with the following resolution: > > The requirement that the v=DMARC1 tag be first will be retained. > > The requirement that the p= tag be second and the requirement that the p= > tag > is mandatory will be dropped. If the p= tag is not present, the implied > policy value is None. > > Scott K > > On Thursday, May 21, 2020 4:54:55 PM EDT Tim Wicinski wrote: > > (With no hats) > > > > I agree with John the v=DMARC1; is magic and MUST be first. Everything > > else can show up wherever. > > > > tim > > > > On Fri, May 15, 2020 at 9:09 PM John Levine <jo...@taugh.com> wrote: > > > In article <CAL0qLwa-iuyB_iNQU+g6e3NH1+q0W413RaCZcHp== > > > s9cqa7...@mail.gmail.com>, > > > > > > Murray S. Kucherawy <superu...@gmail.com> wrote: > > > >It's been a while since the original discussion, but I can't remember > why > > > >the requirement is there in the first place. The only benefit I can > > > >think > > > >of is that having "v=" first lets you decide very quickly if you care > to > > > >continue, but the savings is really pretty small. > > > > > > The v=DMARC1; is a magic number that tells you whether it's worth > decoding > > > the > > > rest of the record. People put a lot of junk at tops of their zones, > some > > > of which is in k=v format and I would prefer not to try to decode > records > > > full > > > of junk to see of a v= tag is in there somewhere. > > > > > > Other than that I agree there is no reason to specify the order of > > > tags. > > > > > > -- > > > Regards, > > > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for > > > Dummies", > > > Please consider the environment before reading this e-mail. > https://jl.ly > > > > > > _______________________________________________ > > > 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 > -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
