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

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

When the header stream is recreated, three other issues occur:

1) If there is a 77 octets long line in the header like this one:

Content-Type: multipart/alternative;
        boundary="=_5cdba748639ad75b27918027=c3c12a77-1fb5-5217-9e5c-e9e8badcad91_="

and this header is reformated, there is RFC 2231 applied (parameter value continuation) as:

Content-Type: multipart/alternative;
        boundary*0="=_5cdba748639ad75b27918027=c3c12a77-1fb5-5217-9e5c-e9e8badcad9";
        boundary*1="1_="

which is completely unusable on Microsoft mail readers (Outlook, Outlook Express, Windows Mail, Live Mail...) because they don't implement RFC 2231 and such mails aren't identified as a multipart (they are shown as a plaintext mail).

Moreover this header splitting isn't needed in such case, because RFC 2822 says the line SHOULD NOT (not MUST NOT) be longer than 78 (not 76) octets. As a workaround I'm using #define GMIME_FOLD_LEN 78 instead of 76.

2) If From/To/Bcc... (write_addrspec()) headers look like:

From: "John Doe M.D." <jdoe@example.com>

all is fine and such header is reformated exactly the same, but

From: =?us-ascii?Q?John_Doe_M.D.?= <jdoe@example.com>

isn't interpreted as "John Doe M.D." (probably another issue) but as is (because of the banned period special character inside non-ASCII escape sequence), in older versions the email part was completely cut off, but true problem occurs when you use non-ASCII encoded characters:

From: =?iso-8859-2?Q?Vlastimil_Janou=B9ek_-_Claro_s.r.o.?= <jdoe@example.com>

is reformated as

From: =?us-ascii?q?==3Fiso-8859-2=3FQ=3FVlastimil=5FJanou=B9ek=5F-=5FC?=
        =?us-ascii?q?laro=5Fs=2Er=2Eo=2E=3F=?= <jdoe@example.com>

(note there is the first = character unascaped, which might point to another issue).

I know, there is a period what isn't an atom character, so decode_word() can't recognize as a =?...?= token, but you might try to say it to Microsoft, which generates such headers, not only period, but also @;:\ special chars aren't escaped (the backslash is doubled).

But, you know, RFC 8288 says the period appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be   interpreted properly.

3) When the existing headers are modified, digital signature check will fail. For example, if there is DKIM header like this:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=default;t=1389608114; bh=C6AYijNsfEWdvsEduoYHBxWKkb32qLrYFGcruVMx5D8=;h=Subject:To:Message-ID:From:Reply-to:Date:MIME-Version:Content-Type;b=tw8/zf4zStQNejPh67IWDSJ7P+oUDFMuC9z6xXxOCUCSEDle0ZHWO3YcgafCNGuQHVWjiefOkoDlrpYkxtqlGK4OAnEGiakX4+ZH1RH1lk4fO7ynsrW7U5u5s3S1HYew9nFet8JQZGMbhj9AkGoLT/09woQ7pEBfV2mCwFEN7D4=

and any of the headers Subject/To/From/Reply-To/Content-Type (they all I saw altered) is changed (e.g. g_mime_utils_unquote_string()), the hash will also change.

I tested all above things on 2.6.20 version (the "older versions" means 2.5.1). I'm using GMime indirectly via DBMail IMAP/LMTP services.

I've bumped the GMIME_FOLD_LEN to 78 in git master (although no idea when I'll do another release because I no longer have a working Linux machine and my VirtualBox VM won't boot).

I just took a look at the code and this will require API breakage to fix :-\

My recommendation to work around this (I presume you are adding a header?) is to write the new header to disk followed by writing the message.

It doesn't matter if the new header you added is at the top or bottom, so should be a workable solution for now.

Eventually I'd like to modify the API to work a bit more like MimeKit (which I specifically designed to work around this problem).

Thank you for reply. As you wrote, I made such bugfix for DBMail (http://dbmail.org/mantis/view.php?id=1051, I'm not a developer of DBMail, it's only my suggestion), the Return-Path header I'm adding (prepending) in my LMTP server patch to the string (message memory buffer) before g_mime_parser_new_with_stream() or something is called.

So, because my server doesn't alter headers now, a part of issues is solved for me. But solution for From: =?charset?q?chars_with_._inside?= I'm still looking. No simple solution I found. Yes, I can put a little module fixing malformed header (by replacing of banned characters by their valid form like =2E for ".") ahead of the LMTP server, but this fix modifies the header which could be digitally signed. I would like GMime could interpret such headers well. I think MS Outlook is still very popular mail reader.

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

I've decided to get rid of the header stream cache altogether and instead cache the raw value for each header on an individual basis.

I've almost got a patch ready to be committed for this that I wrote last night, but it breaks API/ABI so it'll have to be a "3.0" release (or 2.8 or w/e I end up calling it).

Since this will break API/ABI, I'll probably try to squeeze in some more API/ABI changes that I've been meaning to do for a while now.

Committed to git master.