Hello Richard,
in the encoding I propose in draft-moccia-dkim2-deployment-profile, each
envelope recipient is carried in its own header, with the address as the
final tag:
DKIM2-Sig-rt: i=1; v=1; [email protected]
Everything after addr= is the address, to the end of the header field.
There is no following tag to separate it from, so an internal "=" - or a
comma or any other character a valid RFC5321 address may contain - is
simply part of the value. The parser reads the structural tags, reaches
addr=, and takes the remainder of the line. No character needs hiding,
because none of them can be mistaken for a separator: there is no
separator after the address to protect.
This is the same reason addresses already travel unencoded in From, To
and Return-Path today. An address in a header field does not break the
header field.
So the point stands: the quoting question is resolved within a tag-value
encoding and where the current spec does use base64 on rt=, that too is
independent of JSON. It is not an argument for a structured format.
Regards,
Vittorio
Il 2026-09-06 16:34 Richard Clayton ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
The complex characters in an RFC5321 Forward-path are handled the same
way regardless of what surrounds them. The current spec handles them
with base64: rt= is a tag-value field (rt=base64string *(","
base64string), Section 8.6) whose values are base64-encoded precisely
because the Forward-path "can include characters which would confuse
naive parsers." That is a tag-value field solving the quoting problem
without any JSON.
There is a second way to avoid the problem entirely: carry one address
per header, so no value ever contains more than a single address and
there is no internal separator to protect. No encoding is needed
because
there is nothing to disambiguate.
that is incorrect
The issue is not that an email address can contain a comma (which of
course would not occur if we did not have more than one address)
an email address can also contain a = character ... and that means that
a naive parser which believes that (<char>)<char><equals><string> is a
valid tag is going to make a mess of it
viz: there is more than one character to hide away from the naive
Note also that recipes can be contain a very wide range of characters
when entire header fields are being replaced.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
