It looks like it's enough to have SPACE somewhere in X-Face header after 80. character, Pan does a word-wrap and sees only the first line as a header.
check also this group:
yu.test
and look at the messages by 'Ivan Rajkovic' from 01. Jan 07.
Pan shows only one of them corectly, sylpheed-claws 3 out of 4.

(In reply to comment #1)
> It looks like it's enough to have SPACE somewhere in X-Face header after 80.
> character, Pan does a word-wrap and sees only the first line as a header.
> check also this group:
> yu.test
> and look at the messages by 'Ivan Rajkovic' from ***01. Jan 07.***
> Pan shows only one of them corectly, sylpheed-claws 3 out of 4.
> 

that was 06. Jan, not 01. Jan

I'm wondering if this is a GMime bug, of it it's even a bug at all.
Pan's getting this header from g_mime_message_get_header (msg, "X-Face");
and I'm cc'ing fejj to this to defer to his encyclopediac knowledge of
header ettiquite

it might be. quick search through claws-mail source showed me that they are not using GMime but procheader.h (their own header file) to read message headers.

Created attachment 81037 [details]
sample posting that displays the behavior

fejj: could you weigh in on this?  Boiled down, the question is this:
is the X-Face: header in Comment #5's attachment standards compliant,
and should a call to g_mime_message_get_header() return it as an
unbroken string with no spaces?

fejj: ping

Sorry, someone just poked me on this... my fejj@novell.com address didn't work back when this got Cc'd to me because I had been laid-off by Novell (the good news os I just recently got hired by Miguel to hack on MonoDevelop, so yay!)

Anyways...

looking at the sample text message, a block of headers ends at \n\n... so it would appear that that message's X-Face header is improperly folded.

If I remove the blank lines, GMime is able to parse it properly:

"4JwcMHVV7.+Q"O&7#~e!/D3&-We*\6>YCmt~!;eHB\Qc$GGC}v}V[BFN]+pX;wqky_vXgj Ag!*"Am:~ffPJV&#cV*0"NeN9I]gaK$eDg`>`!5Ep&J_:/#KPnG3g.u|DV]i7P@l#46^UkNF\#"N%Q s9VP9Clc>qmNO$c(.^"2~nkJ.0LC+F{"sZI@+Ut

(that's going to line-wrap, but basically GMime returns the unfolded header string w/ 3 encoded chunks separated by a single space - as it should)

I don't think there is a way to unfold a header like that and not get the lwsp char used to "indent" the subsequent lines... but I'd have to reread that part of the spec to be sure.

e.g., I *think* that given the following folded ehader string:

"X-Face: lalala\n lalala"

the unfolded header would have to be:

"X-Face: lalala lalala"


Again, I'd have to double-check though... it would probably be specified in rfc822 (rfc2822 should also be checked in the case they might be more clear on this issue)

oh yea, the other good news is I saved a lot on my car insurance!

I just read through the appropriate sections on Long Header Fields in both rfc822 and rfc2822 and I was correct about the unfolding process not removing the LWSP after the CRLF.

Anyways... if Pan's X-Face decoder needs the value to be devoid of LWSP, that should be a simple enough procedure to hack up a fix for inside Pan itself (e.g. you could either strip LWSP after getting the value from the constructed GMimeMessage object or you could be a cheeky bastard and hook up the header regex callback in the GMimeParser and with a little casting action, do it there).

This seems to be working now in svn revision 224.  Ivan's test case in comment 1 works right.

Pan now strips out extra trailing linefeeds when fetching headers
from the nntp server.

*** Bug 427489 has been marked as a duplicate of this bug. ***

I've just tried it, and it works great.
Thanks a lot.