Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07

[John Levine <[e-mail]>]

It appears that Damian Lukowski  <[e-mail]> said:
> From the perspective of a decision problem, there are no unknown DMARC tags. If there are syntax errors, then the whole thing is 
>not a DMARC record, in particular it does not consist of valid tag-value pairs and invalid tag-value pairs. The record
>
>> v=DMARC1; rua=mailto:[e-mail]; garbage=101; more-garbage
>
>should not yield DMARC reports at all, as there is no DMARC record.

The spec could be worded better, but you are clearly mistaken.
Anything that starts with "v=DMARC1;" is a DMARC record.

>In my opinion, the spec should either stick to the grammar, or explicitly and unambiguously define the parsing procedure.
>
>[1] "A DMARC policy record MUST comply with the formal specification found in Section 5.4"

Selective quoting is not helpful.  What it actually says is:

  A DMARC policy record MUST comply with the formal specification
  found in Section 5.4 in that the "v" tag MUST be present and MUST
  appear first. Unknown tags MUST be ignored. Syntax errors in the
  remainder of the record SHOULD be discarded in favor of default values
  (if any) or ignored outright.

As I said before, I think we should fix the spec to agree with the
practice. The ones I've seen accept an arbitrary list of tag=value
pairs, ignore any trailing garbage, and do not care about tag order
other than that v=DMARC1 has to be first.

I definitely would not say that clients have to ignore records wth
syntax errors, since implmentations will ignore that and do what they
do how.

Re Ale's question about a the tag registry. I'd make it FCFS rather
than Specification Required since there is no risk of running out of
tag names. I'd rather know about all the tags people use, even poorly
specified ones, so we can avoid name collisions.

R's,
John