<<< Date Index >>>     <<< Thread Index >>>

Re: RFC 2047 encoder botched?



Hi,

* Thomas Roessler [07-06-08 12:38:27 +0200] wrote:

A little bit of poking at the relevant code suggests that
write_one_header in sendlib.c doesn't treat cases correctly in which
an encoded word gets too long.  From staring at the code, I don't
see where that bug is.

I debugged your sample mail a little bit and the problem seems to be this: the subject gets passed properly encoded and wrapped already. Mutt eats the first line just fine. However, when it sees '\n' it breaks out and modifies the working indexes and eventually does never see the '=?' in the first line being part of the encoded word.

I _think_ problematic is this:

   col < wraplen || in_encoded_word

Mutt is supposed to continue on line 2 since it's actually within an encoded word (but it doesn't know since it never saw '=?'). So the first part evaluates to false since the word is "too long" and in_encoded_word errorneously is 0.

I think it's a simple off-by-one bug somewhere because mutt sees the '?' of line two, but not the '=' before it...

A dirty fix was to change 'break' in that function to 'continue', but now the subject header for your example gets quite long (2 lines compared to 3)... but I don't know if that's what header wrapping was all about.

  bye, Rocco
--
:wq!