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:
; 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
