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

[Ken Hornstein]

>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