Occasionally I receive mails that include an incorrectly RFC2047 encoded Subject header like:

Subject: =?utf-8?B?TmV3IFRyYWRpdGlvbmFsIENhY2hlOiBNw7xobGdhc3NlbmjD?=
 =?utf-8?B?vHR0ZSAoR0NBMFhKUiksIDguODltaSBOVyAoMTQuM2ttIE5XKQ==?=

This is incorrect as by RFC2047 5.3:
  The 'encoded-text' in an 'encoded-word' must be self-contained;
  'encoded-text' MUST NOT be continued from one 'encoded-word' to
  another.

The decoding is:

Subject: New Traditional Cache: Mühlgassenh<1st byte of 2-byte character>
 <2nd byte of 2-byte character>tte (GCA0XJR), 8.89mi NW (14.3km NW)

Claws-mail displays these Header files in an unreadble way, as it suppresses display of some characters after the incorrect encoding.

Nonetheless, I do receive such emails and I cannot reasonably ask the sender to prepare RFC2047 compliant emails. I would prefer claws-mail to be as fault-tolerant as other mail readers, here.

I have spotted the cause for this behavior in src/common/unmime.c unmime_header() which is (RFC compliant!) parsing MIME encoded headers one encoding after the other. Changing the processing in a way to first collect and decode all subsequent encodings, before conv'ing them into the target character set, would make this behavior more fault-tolerant.

While preparing a patch proposal for this behavior I spotted some other potential flaws when unmime'ing header fields, e.g. in handling of RFC822 quoted-string, for which I'll need deeper analysis before elaborating further.

I'll prepare a patch proposal for src/common/unmime.c unmime_header() and attach it to this bug report, as soon as it seems to be ready for review.