Re: [gmime-devel] Help appreciated adding attachments to outgoing mails

[Jeffrey Stedfast <fejj gnome org>]

Hi Steve,

On 8/11/2013 9:31 AM, Steve Kemp wrote:
>    Thanks for the detailed response, Jeffrey.  I don't know how
>   you find the time!

I've home sick with nothing to do ;-)

>    I used your framework, with only minor changes for the C++ vector
>   type and things look mostly perfect [0]
>
>    The only omission is that there is no explicit MIME-type for the
>   main part of the message.  I thought I could add these two lines:
>
>      GMimeContentType *new_type;
>      new_type = g_mime_content_type_new_from_string ("text/plain; charset=UTF-8");
>      g_mime_object_set_content_type ((GMimeObject *) message, new_type);
>      g_mime_message_set_mime_part (message,(GMimeObject*) multipart);

It probably sounds a little weird at first, but the way GMime does 
things, the headers on the GMimeMessage don't include the Content-* 
headers, those are instead placed on the MIME part.

For example, the GMimeMultipart is what contains the Content-Type: 
multipart/mixed; ... header.

If you want to change the Content-Type of the original text in the 
simple message, what you'll want to do is set it on the GMimeMessage's 
top-level MIME part:

    GMimeContentType *new_type;
    GMimeObject *mime_part;

    mime_part = g_mime_message_get_mime_part (message);
    new_type = g_mime_content_type_new_from_string ("text/plain; charset=UTF-8");
    g_mime_object_set_content_type (mime_part, new_type);
    g_object_unref (new_type);


(of course, this assumes that you do this before replacing the top-level 
mime part with the multipart)

What you could probably do instead is simply set the charset parameter 
(because by default, simple rfc822 messages without a Content-Type 
header automatically get created with a text/plain GMimeContentType 
object, they just don't have a header to go along with it unless you 
change a property of that GMimeContentType).

    g_mime_object_set_content_type_parameter (mime_part, "charset", 
"UTF-8");

This will update the existing GMimeContentType object by adding the 
charset parameter which will cause the GMimeObject to re-serialize the 
Content-Type header, adding one if it doesn't already exist.

The reason that the GMimePart that is parsed from your simple message 
doesn't write out a Content-Type: text/plain header right now is that 
there wasn't one to begin with and GMime attempts to preserve that aspect.

You should note that it's not necessary for each part of a multipart to 
have a Content-Type header. I know that the following raw text looks 
wrong, but it's actually valid (and correct):

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-Qq0SE38PaOrGL/oBRst7"

--=-Qq0SE38PaOrGL/oBRst7

  This is text/plain

When a subpart of a multipart does not have a Content-Type header (or any headers), MIME parsers are supposed to 
interpret that as if the part had a "Content-Type: text/plain" header (except when the multipart is a 
multipart/digest, then the default Content-Type is supposed to be interpreted as message/rfc822).

Anyway, hope that helps!

Jeff