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

[Ken Hornstein]

>There's a difference between "having a hard time" and
>"knowing that it cannot possibly happen".  You may be right,
>but I'd like to see a stronger statement.  If there's some
>doubt, then I don't think it's worth the risk.  This
>shouldn't occur often, and I don't see any problem with
>letting the user deal with it.

Well, I was trying to be charitable ... but let me say something stronger.
I do not see any way this attack could possibly succeed.

>An "attack" doesn't have to be malicious, it can be
>user/programmer/whoever error.

I guess in my mind an attack is something that is deliberate and malicious,
but that's just semantics.  Moving on ...

>My concern is that something like boss=?utf8?Q?=2cX=excluded,
>where X is a invalid UTF byte, will get converted to
>boss=?utf8?Q?=2c?=excluded, which is a legal encoding of
>boss,excluded.  If you can guarantee that kind of thing won't
>ever happen in an nmh draft, great.

I guess I don't really see why someone would do:

From: boss=?utf8?Q?=2cX=excluded

When they could do:

From: boss=?utf8?Q?=2c?=excluded

Or even:

From: boss, excluded

But if you're concerned about what I have to call a non-problem, there's
an easy solution.  Simply don't do %(decode) on address headers in the
replcomps (we don't do this now).  That ensures that there's not a problem.

--Ken