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

[David Levine]

> >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?

I am :-)  My concern isn't just the display name.  It's the
entire address (name-addr from the BNF).  It's a security
concern:  could replacement of any characters change the
name-addr to another that is valid, but different than
intended?

Right now, as we have seen, the answer is yes for nmh (where
"replacement" is truncation).  In general, I don't think the
question is easy to answer.  What if an attacker, or
mistake, moves the divider between the display name and
angle address?  And it's even more complicated because an
"address" can be an nmh alias.

Using '?' as the replacement character is especially
problematic because it's used as all or part of the
delimiters in RFC 2047 encodings.  It seems to me that an
attacker could then do just about anything to an address,
such as encoding something that turns into a ',' so the
first part of the display name becomes a standalone address
or alias.  (2047 specifically mentions encoding a "phrase",
which is what a display name is.)

This just isn't a hole that we should retain.  Punt to user
on input error, that's the only safe action here.

David