[Users] encoded addresses causing problems in reply

[Derek B. Noonburg]

On Thu, 8 Sep 2022 13:34:39 -0000
Paul <paul at claws-mail.org> wrote:

> patches welcome :)

I'm not quite there yet -- I'm trying to understand the code well
enough to put something together, and hoping that someone can give me a
little help.

First, to follow up on my own question:

> But why does $LANG affect the selection of base64 vs quoted-printable?

There's code in conv_encode_header_full (src/common/codeconv.c):

	if (MB_CUR_MAX > 1) {
		use_base64 = TRUE;
		mimesep_enc = "?B?";
	} else {
		use_base64 = FALSE;
		mimesep_enc = "?Q?";
	}

MB_CUR_MAX (defined in stdlib.h on my system) is the max character
length in the current locale -- which explains *how* $LANG affects it,
but not why.  I.e., why does this choice depend on the current locale,
rather than the output encoding?

Moving on to the real problem, I believe my original diagnosis is
correct.  If the email address is encoded in ISO-2022-JP, the
display-name part happens to contain a '>' character (or, more
accurately, a '>' byte as part of a multibyte character).  

I think the relevant sequence of function calls (when use_base64 is
false) is:

compose_quote_list_of_addresses
compose_convert_header
conv_encode_header_full
qp_q_encode

The qp_q_encode function escapes certain characters, in order to obey
the quoted printable rules.  But it doesn't know anything about which
characters are invalid in an email address header.

The conv_encode_header_full function has an addr_field argument, which
tells it to parse out parens and quotes.  But that's not really the
right place to handle this either -- that code is before the string is
converted to the final encoding (ISO-2022-JP in this case).

Maybe the simplest option would be to not allow quoted printable in
address fields?  Something like this:

if (MB_CUR_MAX > 1 || addr_field) {
	use_base64 = TRUE;
....

Though I'd still like to understand why the current locale is being
used here.

- Derek