On Tue, Oct 13, 2020 at 9:12 AM Hector Santos <hsantos= [email protected]> wrote:
> Hi Alexey, > > Not direct to "slightly wrong" question but related to the ABNF > nonetheless. Maybe a need new Ticket? > Yes, please create a 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: > > ; components other than dmarc-version and > ; dmarc-request may appear in any order > > 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: > > 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. > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > -- > Hector Santos, > https://secure.santronics.com > https://twitter.com/hectorsantos > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
