What standard? If X-Faces were standard, it wouldn't start with X-.

What do you mean by this bug report anyways? Can you give us an example of what KMail generates and what it should generate? Can you point to the relevant spec?

OK, let me redefine the problem:
KMail uses quoted printable like the iso-thing in this section:
'UczgG:,VxBnpe!Z&V_g2,<?[WV?!r0s>}W\P%Cou5$w*6$lc4(kKQ5Z:<=?iso-8859-15?q?jrOdKqH=5E8=
I am not an expert in this, but I guess it is not necessary to use things like iso-foobar or utf-foobar in the X-Face header because the online generators neither do this. How should they know the character set of the user anyway?
The thing is that quoted printable may break the implementation of X-Faces in other clients like wanderlust (which I do not use, but one of my LUG does).
So if possible, remove those iso-things from the X-Face header, if not, it is wanderlust's problem.

Unfortunately I didn't find a spec, there is only code. 

If you think this issue is somehow irrelevant, close the report with something like WONTFIX or so.

Then it is a bit difficult to find out if KMail is right and the other ones are wrong unless there's a spec to conform to.

By the way, what you pasted is not valid RFC-2047-encoding. The =?...?= must be separated by spaces.

> By the way, what you pasted is not valid RFC-2047-encoding. The =?...?= must be separated by spaces. 

I pasted this from Mozilla source code view of mail, so what does your comment mean in words? Is Mozilla wrong, is KMail wrong?

spec or not spec, why use quoted printable when you don't need to?

It means that whatever you pasted is not a valid RFC 2047-encoded string. So, there are two possibilities: it was never intended to be one, or something mangled it. (KMail, the mail server, your email client, or you pasting here)

From what you pasted, it tried to encode just a "_", which is absurd since there are other underscores that are unquoted.

I had the exact same problem. The header looked like this:
X-Face: 8HSw7:+H-B,=?utf-8?q?Y=60m=5Ft6X=7C=247cV0o=5BWoy=7ECHR2=27Ey/BLWHaWPbQe=7Ee9sJ=3BU=5B?=
 =?utf-8?q?aRJdLOkXjL=3DlO=3D=0A=09S53EJKr7x-=25Bgx=2E=26?=<%x:|LG<\$)M06I}7.9]9{8n.m.qmWLYNj^,o_COfHuW{kfUu>
 =?utf-8?q?ViPV=0A=09e=5EYEccX=25-PGy/?=>';$}K~tvcM>j~ooA%9",z~d9d`s8T='XE_V+~q'
Just going to the preferences, inserting the correct header again and clicking OK fixed it for me (KMail 1.9.1 on KDE 3.5.0).
It now looks like this:
X-Face: 8HSw7:+H-B,Y`m_t6X|$7cV0o[Woy~CHR2'Ey/BLWHaWPbQe~e9sJ;U[aRJdLOkXjL=lO=
	S53EJKr7x-%Bgx.&<%x:|LG<\$)M06I}7.9]9{8n.m.qmWLYNj^,o_COfHuW{kfUu>ViPV
	e^YEccX%-PGy/>';$}K~tvcM>j~ooA%9",z~d9d`s8T='XE_V+~q'
I'll let you know if the old behaviour should return.


regards,
felix

OK, bugzilla obviously messes up the pasted lines. Here are both headers, in comparison: http://extern.tribut.de/bug-reports/kmail-xface.txt


felix

Yesterday, I noticed I was sending out the utf-8 crippled headers again. And I did not change the account configuration - so this is a bug and it's still present in KMail 1.9.1!

It seems to be a very weired problem. At least no client i've tested can display x-faces sent by KMail.

This is how it looks like actualy in KMail 1.9.1:
X-Face: &t~~bnQ.fgWh`/W|0D@%LRW$mP6&{WvB;@yXYNg*{\_HG)JM~OLd|/7G$J}C,O!)=?utf-8?q?J=7Ee*3o=0A=09A!=7D=3BD5lEf=23y1Zt/T7b-D=7D5zV=7BypJIf=23l?=
 =?utf-8?q?=5F=7CgODK=5B2f=3FxI18m-y=23?=@Epo-3UYY@
 =?utf-8?q?M/kmFsY=3D=607=0A=09id=7Em5RSa6Wij+yaH7=23ClX=7E=3DB!Jbz=3DN2=3D6?=
 =?utf-8?q?=3B=5Cux=24J?=)9UA!8g~32,?yR|&"DLLn*#:PC(WSJ(
 =?utf-8?q?=0A=09VS7=26Fim7?=

And this is how (the same) x-face string should look like (taken from KNode):
X-Face: &t~~bnQ.fgWh`/W|0D@%LRW$mP6&{WvB;@yXYNg*{\_HG)JM~OLd|/7G$J}C,O!)J~e*3oA!};D5lEf#y1Zt/T7b-D}5zV{ypJIf#l_|gODK[2f?xI18m-y#@Epo-3UYY@M/kmFsY=`7id~m5RSa6Wij+yaH7#ClX~=B!Jbz=N2=6;\ux$J)9UA!8g~32,?yR|&"DLLn*#:PC(WSJ(VS7&Fim7

KNode works perfectly. Maybe you wan't to take a look at the knode source?

Confirmed, see https://bugzilla.novell.com/show_bug.cgi?id=354693

I believe this bug occurs because KMail tries to fold (i.e., wrap) the X-Face header after column 77.  (Headers are allowed to span multiple lines if subsequent lines begin with whitespace.)  Every 77 characters in the header, then, KMail inserts a newline and a tab (0x0A 0x09).  Then the header is then RFC 2047-encoded, which converts the newline+tab (as well as some arbitrary number of characters before and after) to the sequence

=?charset?foo=0A=09bar?=

where "charset" is the composer's default charset.

This problem is pretty trivial to fix, using one of the following

1) The RFC 2047 encoding step should be done before, not after, the insertion of newline+tab characters.

2) The RFC 2047 encoding step should leave newline and tab characters as-is.

3) The RFC 2047 encoding step should be skipped altogether, since X-Face headers consist solely of printable ASCII characters.  (Just in case, the X-Face input form should reject any invalid characters from the input.)

4) Header folding for X-Face should be disabled altogether.  As far as I know, RFC 822 imposes no limit on the length of an individual e-mail header; header folding is done purely for cosmetic purposes.

Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.