Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement

[Todd Herr <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> wrote:
> > > In article <CAL0qLwa-iuyB_iNQU+g6e3NH1+q0W413RaCZcHp==
> > > [e-mail]>,
> > >
> > > Murray S. Kucherawy  <[e-mail]> 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, [e-mail], Primary Perpetrator of "The Internet for
> > > Dummies",
> > > Please consider the environment before reading this e-mail.
> https://jl.ly
> > >
> > > _______________________________________________
> > > dmarc mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dmarc
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*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.