Re: [gmime-devel] unexpected rewrapping in long lines

[Jeffrey Stedfast <fejj gnome org>]

Hi Paul,

On 4/5/2013 9:16 AM, Paul J Stevens wrote:
> Jeff,
>
> Below was confirmed on gmime-2.4 and gmime-2.6
>
> When a message with a long utf7 encoded lines passes through gmime every
> works as expected, except when a header is added to the message along
> the line.
>
> Consider below message. The quotation style was used to preserve indenting.
>
> ----
> > From: test
> > To: test2
> > Subject: qqqq wwwwwww [eee 
> > 1234]=?UTF-8?Q?=20=D0=95=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC?=
> >
> > 123
> ----
>
> when it gets parsed as-is, everything is alright -
> g_mime_object_to_string returns the message exactly as fed in.
>
> However, when a header is added after parsing the message, the subject
> line in this case gets re-wrapped

When a header is added, GMime currently destroys the cached header 
stream because it doesn't have any logic to merge unmodified headers 
with added/modified headers.

It looks like the Subject header above is broken in that there is no 
white space separating the beginning of the encoded-word token from the 
preceding text.

>   in what appears to be an incorrect
> fashion. At least, thunderbird and other mail clients don't grok it any
> more.
>
> Say a header 'X-Test' is set on above message:
>
> g_mime_object_set_header(message->content, "X-Test", "testing");
> g_mime_stream_reset(message->stream);
> g_mime_object_write_to_stream(message->content, message->stream);
>
> Now if I do g_mime_object_get_headers on the message->content
> GMimeMessage object I get:
>
> ----
> > From: test
> > To: test2
> > Subject: qqqq wwwwwww [eee
> >   1234]=?UTF-8?Q?=20=D0=95=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0
> >         =BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0
> >         =BC=D0=BC=D0=BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0
> >         =BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=20=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0
> >         =BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC=D0=BC?=
> > X-Test: testing

Looking at the header_fold() logic in gmime-utils.c, it doesn't look 
like it has all of the same complex logic of handling malformed rfc2047 
encoded-word tokens that the tokenize_rfc2047_text() code has.

As a workaround, you could register your own subject writer function 
that does something like:

static ssize_t
write_subject (GMimeStream *stream, const char *name, const char *value)
{
    char *decoded, *encoded, *unfolded, *folded;
    ssize_t n;

    decoded = g_mime_utils_header_decode_text (value);
    encoded = g_mime_utils_header_encode_text (decoded);
    g_free (decoded);
    unfolded = g_strdup_printf ("%s: %s\n", name, encoded);
    g_free (encoded);
    folded = g_mime_utils_unstructured_header_fold (unfolded);
    g_free (unfolded);

    n = g_mime_stream_write_string (stream, folded);
    g_free (folded);

    return n;
}

If you could submit a bug report about this and a sample message (with a 
Subject like the one you pasted above), I'll try to look into fixing 
this properly when I get a chance - probably by fixing the header_fold() 
logic to use the tokenizer or something.

Or maybe I'll fix it by enabling this identical workaround if 
g_mime_init() was initialized with the ENABLE_RFC2047_WORKAROUNDS flag 
(do you use that flag?).

> ----
>
> and the top-level mime-part also gets encoded as:
>
> > D=0B
> Does this ring any bells for you?

Can't say that it does :-\

Jeff