In article <caba8r6ttpateyprsgbwkafzvz4u8v8sn1vptpmlqcia2_+5...@mail.gmail.com> 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 <[email protected]> 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? _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
