Re: [Nmh-workers] Weird behavior with non-ascii code in headers

[Ken Hornstein]

>Do we do any character replacement now, other than the
>insertion of quotes around the display name that you mention
>below?  If not, character substitution could introduce bad
>behavior that we don't have now.

Actually ... yes!  If you use %(decode), we totally replace those
characters and perform character set conversion.  We don't yet do that
in the default component files when doing a reply, but it was actually
my plan to make that happen for 1.6 (that requires some other stuff,
like mhbuild doing RFC 2047 encoding).  Also ... if we cannot transform
the characters to the local character set when doing character set
conversion, the offending characters get replaced ... with a '?'.

Really, think of this as finally grappling with some more I18N issues
that have been long-pending.  We don't globally do character set
conversion, but we're going to have to ... and we have to handle the
case where characters in one character set aren't valid in another.

>> which is invalid because the . without quotes is invalid, we silently add
>> quotes and fix it up.
>
>It's obvious what needs to be done in that case to go from
>an invalid address to a valid one.  And the delivery address
>isn't being modified, just the display name.

Right, and that would be the same for Valdis's case as well.  Like I
said, if the concern is about mangling addresses it would be easy
(and proper, assuming we don't have widespread adoption of SMTPUTF8)
to add checking and rejection of addresses with 8-bit characters in
them.  But I'm not even sure that is necessary right now; I'm not yet
convinced 8-bit characters in an email address would make it all of the
way through the system.

--Ken