the problem is that the example you pasted isn't a valid encoded word (not allowed to have spaces)

there are a few possibilities for the correct encoding:

=?UTF-8?Q?Alles_Gute_w=C3=BCnsche_ich_dir!?=

(_'s get decoded into spaces)

Alles Gute =?UTF-8?Q?w=C3=BCnsche?= ich dir!


I'll leave it up to the current mail maintainers to decide if this should be closed or not.

fejj, in the past we have always closed bugs like this as NOTGNOME, because the sender of such emails should ask the application developers to fix the sending application

My humple opinion is, that evolution should be as liberal as possible in its receiving capabilities, but as strict as possible when sending stuff. Simple rule, but fits fairly well here.

Lars, if you show me the "no idea how malformed the string is i get, i know how to transform it to a perfect correct display" algorithm, we can implement it.

I would suggest to replace whitespaces with underscores when the complete string is encoded. Makes sense?

Lars: you can't just replace spaces with underscores in headers formed by other mail clients because then you'd break correctly-formed encoded headers.

Of course not. I would suggest to first detect, if the header is completely encoded. If it is, check weither there are whitespaces and replace them. The rest stays untouched.

That's the point... that is non-trivial

Glib's regex functions would be too slow?

doesn't the fact that it breaks currently already mean that the evolution app "knows" that it's malformed?

no

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

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

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

I ended up implementing support for this in GMime's header decoder and then copied that code into Camel back in 2007, so this is probably "FIXED".

Check out commit a6130f62dafab744c3be19e571a747c4fe815679