Arnt Gulbrandsen wrote:
> At any rate, I added RFC6531/6855 support to mutt. Please pull:
> 
> https://bitbucket.org/arnt/mutt/commits/a83a4387c35384eccd3a11d74b8db4ebbb185d30
> 
> Some earlier changesets need to be reverted. mutt_idna.c may have been a
> fine idea, but using idna in mail didn't get traction, and is incompatible
> with this. This patch is compatible with the latest experimental release of
> Postfix, and with what Google and Microsoft are testing.

Hi Arnt,

This second email is about the SMTP / email address part of the patch.
I don't have a revised patch for this yet, but wanted to list some
comments first.

* 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)

* 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 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?

* 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.

-- 
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

Attachment: signature.asc
Description: PGP signature

Reply via email to