Re: [dmarc-ietf] Definition of "value" in RFC8601

[John Levine <[e-mail]>]

In article <[e-mail]> you write:
>-=-=-=-=-=-
>
>Hmm, we didn't include this in RFC 8616 either, I could imagine that it
>should be punycoded also, though it really depends on whether in 6532 or
>5322.

This is another mistake in the ABNF in 8601.  The point of 6532 is
that with the exception of Message-IDs, any header fields that used to
be limited to ASCII can now contain UTF-8 printable characters.

If you're putting an A-R header on an EAI message, it has to allow 
UTF-8 since lots of the fields in an A-R header can contain mailboxes
and other UTF-8 strings. 

I realize that the authserv-id is usually a domain name, in which case
it would be reasonable to represent it as A-labels, but it doesn't
have to be.

The only, and I mean ONLY, strings that are "punycoded" are the
characters in IDN labels that follow xn--.  To pick a common point of
confusion, you absolutely cannot "punycode" a mailbox name.

R's,
John


>On Sat, Mar 28, 2020 at 3:39 AM Damian Lukowski <[e-mail]> wrote:
>
>> Hello,
>>
>> RFC8601 section 2.2 defines
>>
>> > authserv-id = value
>> >             ; see below for a description of this element
>> > [...]
>> > The "value" is as defined in Section 5.1 of [MIME], with
>> > "quoted-string" updated as specified in [RFC6532].
>> [MIME] (RFC2045) section 5.1
>>
>> > value := token / quoted-string
>> > token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>> >             or tspecials>
>>
>> The token is not said to be updated by [RFC6532] as is quoted-string, so
>> by my interpretation non-ASCII cannot be used without quotes.
>>
>> If so, then current implementations of OpenDKIM and OpenDMARC are wrong
>> or imcomplete, as they do not check for Non-ASCII AuthservID and produce
>> headers like
>>
>> > Authentication-Results: öde; dkim=none; dkim-atps=neutral
>> Is my understanding correct?