Last Call Review of draft-ietf-lamps-rfc8398bis-03
review-ietf-lamps-rfc8398bis-03-artart-lc-levine-2024-01-30-00

This minor update is fine.

Unicode often provides vast numbers of ways to encode a string of text, and
some rules like NFC and NFD to try to choose preferred encodings. But RFC6531
allows most UTF-8 code points in a local part and says nothing about preferred
encodings. (I don't blame them, since anything they said would have been at
bast a guess, and there are way worse problems than NFC like you cannot fold
upper and lower case without knowing what language the string is in and
sometimes not even then.) Also, even though IDNA says U-labels and A-labels are
equivalent, a lot of mail software doesn't treat them that way so you often
have to alias the A- and U- versions of local domains in the mail system
configuration to deliver them to the same place.

This means that it is dismayingly easy to put an address in a SmtpUTF8Mailbox
which looks exactly like the address on the From: line but is different UTF-8.
I'm not sure there's anything you can do about that other than perhaps warn
people of the problems and encourage them to be sure the address they put in
the certificate is the same as the one in the mail system.