Hi Arnt, Thanks for the reply. This email is really helpful!
On Fri, Sep 04, 2015 at 10:44:50AM +0100, Arnt Gulbrandsen wrote: > 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. Okay, this is clearer. So although we "may" use a-labels for the domain part, we "should" use u-labels to ensure things are smooth. The difficulty (as you mentioned in another email) is that we don't know what the server supports until we actually try to send. Right now, IDNA is a compile-time option for mutt, and if it's compiled in, we always use it. The problem is the same mutt binary may be used with multiple SMTP servers: many people (including myself) have multiple profiles, and one server may require IDNA while the other supports UTF-8 domains. Since we'll be in a transition period for a while, I'm wondering if we should *also* add a configuration option $use_idna (only available when mutt is compiled with IDNA, of course). We'd default it to "yes" for now, but in the future could flip the default to "no" and eventually remove it if/when we remove IDNA from mutt. This would allow people who are sure their SMTP server supports 653x to toggle it off (in a hook or however). Of course, those people are also free to compile mutt with no idna support too, if they are compiling their own binary. > 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. I'm looking at the mutt_addrlist_to_idna() function in mutt_idna.c, and it appears to split up the mailbox/local part from the domain and only call mutt_local_to_idna() on the domain part. Have you observed this in practice, or is there another part of the code doing this that you've seen? (Even though I'm a developer, there are unfortunately still large parts of the code I'm unfamiliar with...) > 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. Fair enough. But before I commit it, I want to take the time to add the conversions, since mutt has these settings and tries to support it elsewhere. It will take me some time (my post-release todo list has gotten a little full), but I'll make it a goal to get this in before the next release. > >* 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. Okay. Sounds reasonable. > >* 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. This answers my question. When sending the email in smtp.c, I noticed the patch only checked for UTF-8 characters in each address if the server supported SMTPUTF8. So if the server didn't support SMTPUTF8 we could end up sending UTF-8 email addresses to it. The RFC said not to do that, but if it "just works" in many cases then it's worth it to at least try. The SMTP server can always return an error code if it didn't like it, right? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt
signature.asc
Description: PGP signature
