Subject: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 13 Oct 2020 12:06:32 +0100

Dear DMARC WG participants,

I would like your feedback on resolving the following ABNF issue:

In Section 6.4 "dmarc-record" is defined as:

     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

Note that dmarc-request is listed as optional field here.

In Section 6.3:

   p: Requested Mail Receiver policy (plain-text; REQUIRED for policy
      records).  Indicates the policy to be enacted by the Receiver at
      the request of the Domain Owner.  Policy applies to the domain
      queried and to subdomains, unless subdomain policy is explicitly
      described using the "sp" tag.  This tag is mandatory for policy
      records only, but not for third-party reporting records (see
      Section 7.1).

>From the above it is clear that dmarc-request is required in some cases and optional in others.

In Section 6.6.3:

 Item 6:

       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;

So, we should clarify under what conditions "dmarc-record" is optional.

I can see a couple of ways of resolving this (there might be other better ways):

1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 different uses and different optionality of "dmarc-record" for them.

2) Make this more explicit and define

     dmarc-record    = dmarc-policy-record / dmarc-reporting-record

where dmarc-policy-record would require "dmarc-record" and dmarc-reporting-record shows it as optional.

Opinions?

Best Regards,
Alexey, as a co-chair

P.S. If you can provide your feedback by October 27th (2 weeks), that would be much appreciated.

---

From: Hector Santos <[email-masked]>
Date: Tue, 13 Oct 2020 12:12:35 -0400

Hi Alexey,

Not direct to "slightly wrong" question but related to the ABNF 
nonetheless.  Maybe a need new Ticket?

We need  a consideration for extended tags in ABNF.  The 3.1.3 text 
supports extensions.

3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

Using Extended Tags is a reality and in practice for many years, 
"running code", i.e. ATPS (rfc6541), it is part of the Wildcat! 
Mail/DKIM package and rest assured more are coming.

How would extended tags be described be the ABNF?  It currently says:

Can we clarify or define "components" and state it may include 
extended tags such as adding to the ABNF

[dmarc-sep dmarc-extended-tag]

For an implementor note, a few days ago, I came across an GUI Zone 
Manager which had a specific form input for adding and editing DMARC 
TXT records. The form editor had DMARC documented fields with their 
options.  You had to go into GUI's raw edit mode option to add 
extended tags and this was supported.  Since the editor did not 
recognize the tag, it disabled the form Editor and only allowed the 
raw field editor.  Nice job.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

On 10/13/2020 7:06 AM, Alexey Melnikov wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Seth Blank <[email-masked]>
Date: Tue, 13 Oct 2020 11:36:47 -0700

> nonetheless.  Maybe a need new Ticket?

Yes, please create a new ticket.

> > 1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 different
> uses and different optionality of "dmarc-record" for them.
> >
> > where dmarc-policy-record would require "dmarc-record" and
> dmarc-reporting-record shows it as optional.
> >
> > Opinions?
> >
> > Best Regards,
> > Alexey, as a co-chair
> >

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Oct 2020 10:56:53 +0200

> Note that dmarc-request is listed as optional field here.

There was some discussion on this question in the framework of ticket #49, 
about May.

IMHO, it is better to let the policy be optional, thereby keeping a unique 
definition of dmarc-record.[*]

For one thing, an empty DMARC record, like those which confirm external 
destinations, provides for better caching than no DMARC record at all.  Of 
course, the existence of an empty DMARC record doesn't have to imply that DMARC 
is "implemented" at the site, that's a different question.

> From the above it is clear that dmarc-request is required in some cases and optional in others.

Unneeded complication.

Best
Ale
-- 

[*] alternative syntax proposed at:
https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8/