Turn off writing exact-addresses that require 2047-encoding.

The full strdup'ed copy of the address can't be properly encoded
without significant rework to parse, encode, and reassemble.
(Additionally, IDNA is not being performed on the domain written in
the exact-address string.)

As an example, consider the current exact address behavior, given the
three addresses:
  "ascii name" (comment) <addr@example.com>
  The ènd (comment) <addr2@example.com>
  "The ènd" (comment) <addr3@example.com>

Before this commit, when sending Mutt would generate:
  "ascii name" (comment) <addr@example.com>
  The =?iso-8859-1?B?6G5kIChjb21tZW50KSA8YWRkcjJAZXhhbXBsZS5jb20+?=
  =?iso-8859-1?B?IlRoZSDobmQiIChjb21tZW50KSA8YWRkcjNAZXhhbXBsZS5jb20+?=

The second address 2047 encodes everything starting with ènd,
including the comment and address.  The third address is completely
encoded.

A "quick workaround" I proposed to the list was turning off
encode_specials.  This results in:
  "ascii name" (comment) <addr@example.com>
  The =?iso-8859-1?B?6G5k?= (comment) <addr2@example.com>
  "The =?iso-8859-1?Q?=E8nd=22?= (comment) <addr3@example.com>

That solves the second case, but in the third case 2047-encodes
ènd" - including the trailing double quote.

With this patch, we turn off writing the exact address if encoding is
needed, generating:
  "ascii name" (comment) <addr@example.com>
  The =?iso-8859-1?B?6G5k?= <addr2@example.com>
  The =?iso-8859-1?B?6G5k?= <addr3@example.com>

This reverts to Mutt-generated normalized form in the last two
addresses, which require encoding.  For the first case it preserves
the address as "typed" by the user.

0 files changed, 0 insertions, 0 deletions