Created attachment 73153 [details] [review]
0.113 patch

This fixes the case for utf-7, but please test this patch out
on other charsets for me before the next release to catch any
regressions.

Now some UTF-8 headers aren't decoded properly. Example:

Newsgroups: pl.news.czytniki
Message-ID: <20060921132655.52b3dd00@athantor.ath.cx>

Looks like QP headers are affected, not just UTF-8, but other charsets as well. They are decoded, but in a wrong way.

Created attachment 73191 [details] [review]
0.113 patch

Same homework assignment as before. :)

Hasn't helped.

So you're saying the that the headers cited in comment #2
are still broken in the second patch?

That's right.

But they worked in 0.113?

The only difference between the headers downloaded & shown with 0.113,
and downloaded & shown with the patch, is that X-Face is broken in the
patch.  Is that what you're referring to, or is there another header
that I need to look at as well?

My mistake, X-Face isn't broken in the patch.

I'm sorry but I don't see what you're referring to.
Which header works in 0.113 but not with the patch?

I've found the problem. The headers get messed up when the group's default encoding isn't set to UTF-8.

I'm not sure what to do to make this work right all the time
in the xover headers.  At that point, we don't have the mime
headers to know that the headers are encoded as utf-7, and
utf-7 does pass through undecoded as valid utf-8.

Still, the patch _does_ fix the case of handling utf-7 in
the message body when the mime headers specify the encoding.

Marking this as fixed for the original bug.  I don't think
there's a good solution for the second part.

Oh, but that's not the end of it. I've found out that if the group's fallback charset is other than UTF-8, and you reply to a message posted in UTF-8, some characters get jumbled in the quote.

I'm confused.  Is the body jumbled in the body pane before you
press `followup'?  If it's jumbled in the body pane, then followup's
got nothing to do with it.  If it's clear, then you're reporting
a separate bug unrelated to the UTF-7 headers bug, right?

As for the original issue of how to handle at xover time
encodings that aren't utf-8 but are utf-8-clean, I'm open to suggestions.

It's clear before the followup, but the bug was introduced with the UTF-7 patch, which is why I put it here.

I can reproduce Artur's last problem in 0.113 (without any patches). Example:

Newsgroups: pl.news.czytniki
Message-ID: <45029d91$0$14268$c3e8da3@news.astraweb.com>

I've left the article's charset to the default UTF-8.

The article (which I'll add after this entry) has the following content-type header:

Content-Type: text/plain;
	charset="iso-8859-2"

The article starts as follows:

Po dodaniu serwera news.tpi.pl w momencie ściągania dostępnej listy grup na
serwerze wyrzuca błędy:
------------------------------------------------------------

Checking the raw message confirms the article's indeed in iso-8859-2. 
However, if I try to follow-up, I get:

> Po dodaniu serwera news.tpi.pl w momencie ¶ci±gania dostêpnej listy grup na
> serwerze wyrzuca b³êdy:
> ----------------------------------------------------------------------------
> -------------------

(I have no idea how bugzilla is going to display this. Let's hope for the best :-))

Created attachment 73393 [details]
article from the previous comment

I'm hijacking this bugreport now, but post-ui.cc just calls g_mime_message_get_body() to get the content.  I check that that function indeed returns the garbled message.

GMime source states the following about that function:

 * Note: This function is NOT guarenteed to always work as it
 * makes some assumptions that are not necessarily true. It is
 * recommended that you traverse the MIME structure yourself.

Yup, that seems sound advice. :)

I guess post-ui.cc should use the same mechanism already used by body-pane.cc.

I've promoted the bug described starting in comment #13 into
its own ticket (http://bugzilla.gnome.org/show_bug.cgi?id=357698)
and cc'ed you both.

Marking the original bug as fixed.