[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: Sun, 30 Jun 2013 20:44:02 -0400

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


reply via email to

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