Kevin J. McCarthy writes:
* First, my understanding is the rfc653x series is not incompatible with
IDNA2008. The introduction to rfc6530 mentions rfc5890 for domain
encoding, and in fact rfc6531 section 3.2 even says
It MAY transmit the domain parts of mailbox names within SMTP
commands or the message header as A-labels or U-labels [RFC5890].
(A-labels being Punycode encoded UTF-8)
So it says. 6531 tries to ban nothing that's permitted by 5321 and/or 5322.
But there are gotchas, because compatibility demands more than just a lack
of bans, it demands homogenous extensions.
You could sum EAI up as "allow UTF-8 everywhere, without banning anything
that was permitted before".
5321 allows you to send xn--, so 6531 does too. But 6531 does not go so far
as to require the final delivery agent treat u-labels and a-labels
identically. Similarly, 6855 doesn't require the IMAP server (or client) to
treat u- and a-labels as equal during e.g. FETCH ENVELOPE processing.
Instead, 6531/2/3 and 6854/5 require all the things that are necessary to
make fully UTF-8-encoded messages work homogenously. Using UTF-8 for
everyhing except the domain and a-labels for the domains remains permitted
when older RFCs permit that.
BTW, what 5890 says and what the mutt option enables is a bit different. If
you enable "idna" mutt encodes both localparts and domains. You cannot keep
that code and also comply with the EAI RFCs.
* Like in the IMAP patch, the mutt_idna*() routines are performing
Charset to UTF8 conversion (on the domain part). It seems like we
would want to create new routines that perform the Charset conversion
on both parts (and IDNA on the domain part if enabled), and switch
everyone to call those new routines instead.
I haven't had a chance yet to look through when/where these conversion
are called in the code. It's easy to detect when the domain has been
IDNA encoded, but when we start to perform charset conversion on the
mailbox part, we may need to record some kind of state. I'll look
into that more when I have some time.
I didn't look at charsets, I think. I looked at that in the nineties, these
days I feel that unicode has won and that that's a good thing, so I don't
want to spend actual working time on charset encodings. There are more
useful things I can write.
* I noticed rfc6531 mentioned the server also should announce/support
8BITMIME. Do we need to check for that capability too before we
the enable SMTPUTF8 mode, or it is sufficient to only look for the
SMTPUTF8 capability string?
Matter of opinion. Mine is that SMTPUTF8 is enough. Mutt doesn't carry out
a server compliance test, it just sends mail, so it should check the
extension it wants to use. Checking other extensions that are/may be
implicitly used is a digression.
* What should we do if we have a UTF8 mailbox, but the server doesn't
support SMTPUTF8? The patch looks like it will try to use the email
address anyway. Perhaps that will just abort with an error message,
and that's all we should do, but that doesn't seem great.
I don't understand the question.
But I can perhaps comment. You may have seen my EAI test messages. The
most-used SMTP and IMAP servers often handle those exactly as a 6531 and
6855 say to, even though they haven't been extended. (6530 and 6855 was
written with that in mind.) Because of that compatibility, just using the
address makes a lot of sense in many contexts, even if the server doesn't
declare support. Perhaps also in the one you're thinking of.
Arnt
