>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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
