I don't think that's a good idea. Decoding and conversion should do
only what they're suppose to. If they can't, they shouldn't produce
something different. Esp. if the input is in error. They should
flag the error and give up.
Ok, fine ... but we're not talking about that, are we?
Valdis's original issue was in the display-name portion of the address.
I think this paragraph from that memo applies:
o Occurrences in unstructured text fields, comments, and phrases,
can be converted into encoded-words (see [MIME3] if a likely
character set can be determined. Alternatively, 8bit characters
can be removed or replaced with some other character.
In case this isn't clear, here's the relevant BNF from RFC 5322:
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
So substitution of a non-valid character in the display-name portion
of a name-addr is consistent with this guidance, since it's a phrase.
If your concern is that this will cause problems if the addr-spec contains
an 8-bit character, then I think putting code in the address parser that
will reject such addresses will alleviate this concern. Right? I haven't
yet seen that so I'm not sure how much of a concern that is, but I'm willing
to do that.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers