[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] Weird behavior with non-ascii code in headers
Date: Thu, 27 Jun 2013 23:16:39 -0400

>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] /

   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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]