Re: [dmarc-ietf] [rfc-i] Question about changes introduced by erratum

[Damian Lukowski <[e-mail]>]

Hello DMARC working group,

I am going through the changes between RFC7601 and RFC8601 and try to
understand the implication of the change introduced by erratum 5435.
The new resinfo definition uses 1*propspec, that is, by my understanding
of [1] and [2], potentially multiple consecutive propspecs without
obvious delimiters. The beginning of a ptype and the end of a pvalue
have no mandatory CFWS, so from my understanding, a verifier could
construct a valid authres-header-field that is cumbersome to parse.

I will refer to the "ptype.property" part of a propspec as its "key".

The spf method defines smtp.helo and smtp.mailfrom. RFC8601, RFC7601 and
RFC7001 have only examples of the form smtp.mailfrom=domain-name.
However, RFC7208 shows a local-part@domain-name form in [3], so I must
assume a parser for an RFC8601 resinfo needs to recognize both forms. So
consider

> spf=pass smtp.mailfrom=x.y.zsmtp.helo=a.b

This is "clearly"
- smtp.mailfrom = x.y.z
- smtp.helo = a.b

It seems that a 10 character lookahead is sufficient, as long as we are
in the domain-name case. However, with

> spf=pass smtp.mailfrom=x.y.zsmtp.helo=[e-mail]

the previous "cut" between x.y.z and smtp.helo is no longer valid, as we
have a single smtp.mailfrom with

- "x.y.zsmtp.helo=a.b" as the local-part, and
- "c.de" as the domain-name.

I see some issues:

1. The lookahead for the "@" is unbounded.
2. RFC8601 does not (that I am aware of) prohibit duplicate keys among
multiple propspecs. They may be either completely redundant, i.e. "k1=v1
k1=v1 ..." or contradicting/overwriting each other, i.e. "k1=v1 k1=v2
...". Without a delimiter between the propspecs, it seems even
impossible to parse them unambiguously.
3. I believe that a parser for potentially non-separated propspecs would
be ugly.

Did I overlook or misunderstand something? Would you consider a parser
RFC8601 compliant if it was only able to parse the "benevolent" forms of
an authres header?

Regards
 Damian

[1] https://www.rfc-editor.org/rfc/rfc5234
[2] https://www.rfc-editor.org/rfc/rfc5234#section-3.1 [no "implicit
     specification of linear white space"]
[3] https://www.rfc-editor.org/rfc/rfc7208#section-9.2

> But in answer to your question: [e-mail], since RFC8601 is from the dmarc WG.

[...]

>> I have a question about a change in an RFC introduced by a specific
>> erratum (5435). Is this the right list to ask such question?