>>> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character,
>>> it's invalid under 5321 and valid under 6531.
>> I thought we established that as soon as the authserv-id has non-ASCII
>> UTF-8 characters, the mail is automatically - by definition - a 6531 mail:
> Sorry if it seemed like I said that. It's either a potentially valid
> EAI message or a definitely invalid ASCII message. If your system
> doesn't handle EAI mail, it's invalid.
Let's say the system is capable of handling EAI mail. RC6531 sec 3.6:
> An SMTPUTF8-aware SMTP client or server
> that requires accurate knowledge of whether a message is
> internationalized needs to parse all message header fields ...
If I understand the section and your new authserv-id definition
correctly, an EAI capable system can process plain-ASCII messages, such
that with then definition of
> authserv-id = sub-domain *("." sub-domain)
> ; Where sub-domain is imported from 5321 for ASCII mail
> ; and 6531 for EAI mail.
, sub-domain comes from RFC5321.
If that is so, then this looks to me like a dependency cycle.
To decide for an authserv-id whether to pull sub-domain from 5321 or
6531, one needs to know if the message is internationalized. But to
obtain that information, one must have parsed all message header fields,
per 6531 sec 3.6, including A-R, that is still waiting to be parsed.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
