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

From: Seth Blank <[email-masked]>
Date: Fri, 15 May 2020 11:26:30 -0700

https://trac.ietf.org/trac/dmarc/ticket/49

The penultimate paragraph of https://tools.ietf.org/html/rfc7489#section-6.3
 states:

the "v" and "p" tags MUST be present and MUST
   appear in that order.

While the v= tag pretty universally appears first, the p= tag does not in
many records, and no implementation appears to care.

The v= tag must appear first, or the policy discovery mechanism as defined
in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break.

But there doesn't appear to be any real reason to keep the normative
requirement that the p= tag MUST be second in the record after the v= tag,
nor does this requirement seem to have any impact on interoperability or
general record parsing in theory or in practice.

Should we remove this normative requirement?

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

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.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 May 2020 16:09:06 -0400

Section 6.6.3, step 6, sub-step 1 already says:

>        1.  if a "rua" tag is present and contains at least one
>            syntactically valid reporting URI, the Mail Receiver SHOULD
>            act as if a record containing a valid "v" tag and "p=none"
>            was retrieved, and continue processing;

I don't see a problem with changing the MUST for p= to SHOULD and adding a 
MUST p= or rua=.  That's consistent with what we already tell receivers they 
SHOULD do.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 May 2020 15:08:15 -0700

On Fri, May 15, 2020 at 11:27 AM Seth Blank <seth=
[email-masked]> wrote:

> The penultimate paragraph of
> https://tools.ietf.org/html/rfc7489#section-6.3 states:
>

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.

-MSK, devoid of hat

---

From: "John Levine" <[email-masked]>
Date: 16 May 2020 01:09:15 -0000

In article <CAL0qLwa-iuyB_iNQU+g6e3NH1+q0W413RaCZcHp==[email-masked]>,
>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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 16 May 2020 11:37:05 +0200

On Fri 15/May/2020 20:26:30 +0200 Seth Blank wrote:
> The penultimate paragraph
> of https://tools.ietf.org/html/rfc7489#section-6.3 states:
> 

Actually, the text says:

   A DMARC policy record MUST *comply with the formal specification* found
   in Section 6.4 in that the "v" and "p" tags MUST be present and MUST
   appear in that order.

I agree to relax that rule, but that entails changing the spec in Section 6.4.
 A possible way is be like so:

OLD
     dmarc-record    = dmarc-version dmarc-sep
                       [dmarc-request]
                       [dmarc-sep dmarc-srequest]
                       [dmarc-sep dmarc-auri]
                       [dmarc-sep dmarc-furi]
                       [dmarc-sep dmarc-adkim]
                       [dmarc-sep dmarc-aspf]
                       [dmarc-sep dmarc-ainterval]
                       [dmarc-sep dmarc-fo]
                       [dmarc-sep dmarc-rfmt]
                       [dmarc-sep dmarc-percent]
                       [dmarc-sep]
                       ; components other than dmarc-version and
                       ; dmarc-request may appear in any order

NEW
     dmarc-record    = dmarc-version *(dmarc-sep dmarc-tag)

     dmarc-tag       = dmarc-request /
                       dmarc-srequest /
                       dmarc-auri /
                       dmarc-furi /
                       dmarc-adkim /
                       dmarc-aspf /
                       dmarc-ainterval /
                       dmarc-fo /
                       dmarc-rfmt /
                       dmarc-percent
                       ; components other than dmarc-version may
                       ; appear in any order

The latter syntax allows repeating the same tag more than once.  Should we add
that in such cases it is undefined which value an implementation retains?

> While the v= tag pretty universally appears first, the p= tag does not in many
> records, and no implementation appears to care.
> 
> requirement that the p= tag MUST be second in the record after the v= tag, nor
> does this requirement seem to have any impact on interoperability or general
> record parsing in theory or in practice.
> 

Yes.

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 21 May 2020 16:54:55 -0400

(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 <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 21 May 2020 17:11:54 -0400

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

---

From: Todd Herr <[email-masked]>
Date: Thu, 21 May 2020 18:40:32 -0400

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 <[email-masked]>
wrote:

> > > The v=DMARC1; is a magic number that tells you whether it's worth
> decoding
> > > the
> > > of which is in k=v format and I would prefer not to try to decode
> records
> > > full

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:*

---

From: Steven M Jones <[email-masked]>
Date: Thu, 21 May 2020 15:50:01 -0700

> RFC 7489 and appears to be broadly supported in existing implementations.

Wow, did I miss/forget this proposal earlier in this thread? IMO this 
change should not be buried as a side-discussion, it should have it's 
own ticket (assuming it doesn't already) to raise visibility and record 
a proper discussion/decision.

--S.

---

From: "John R. Levine" <[email-masked]>
Date: 21 May 2020 18:50:37 -0400

> domain owner has given any thought whatsoever to their policy statement.

I don't see that making p= optional solves any problems, so I agree we 
should continue to require it.

"People who don't read the spec and publish garbage" is not a problem we 
solve by changing the spec.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 21 May 2020 23:17:24 +0000

>solve by changing the spec.

RFC 7489 already says if it's missing receivers SHOULD assume p=none, so I don't see the point in "requiring" something in a record when receivers are already supposed to deal with it being missing.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 May 2020 10:02:41 +0200

> is mandatory will be dropped.  If the p= tag is not present, the implied 

Please, let's not forget to update the grammar, e.g. as proposed in
https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8

Best
Ale
--