Re: Curiose encoding...
On 09Jun2006 15:36, thomas roessler <roessler@xxxxxxxxxxxxxxxxxx> wrote:
| On 2006-06-09 13:25:56 +0000, Rocco Rutte wrote:
| > I agree that mutt must not send out something like this.
| > However, mutt already has quite a number of features to be
| > more robust against standard-violating input like
| > RfC2047-encoded parameters. And if it's not too expensive, I
| > vote for catching such errors.
|
| Every RFC 2047 encoded word is an RFC 822 token.
|
| "=?asdf.hjlk?asdf?=" is, in fact, three RFC 822 tokens:
| "=?asdf", ".", "hjkl?asdf?="
|
| There is no encoded word there. Sorry.
Ah, now here is an actual reason why making mutt cope with this stuff may be
difficult. This is good, because I don't think anyone was disputing the
brokenness of the header.
How about, as an interim measure, a FAQ entry showing a procmail rule
for catching these few special malformednesses and rewriting them?
It reduces the impetus to accomodate this in mutt itself, if its parser
really does tokenise this stuff to make the malformed header hard to
recognise as a special case.
An alternative approach, given the token issue, might be to have the
tokeniser pick up the special evilness as a single token and rewrite the
token as a correct token, in-stream.
Cheers,
--
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
An unbreakable toy is useful for breaking other toys. - Van Roy