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

[Steve Kemp <steve steve org uk>]

On Sun Aug 11, 2013 at 11:16:53 -0400, Jeffrey Stedfast wrote:

> 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.

  OK.

> 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:
..

  Having tried that I suspect something is going wrong, as the 
 resulting message is clearly bogus:

--
Subject: testing 3
From: Steve Kemp <steve steve org uk>
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-6d8Cd3fBeYCB69lh/Amd"

--=-6d8Cd3fBeYCB69lh/Amd

ontent-Type: text/plain; charset=UTF-8
MIME-Versio
--=-6d8Cd3fBeYCB69lh/Amd
Content-Type: application/octet-stream; name=fstab
Content-Disposition: attachment; filename=fstab
Content-Transfer-Encoding: base64

IyAvZXRjL2ZzdGFiOiBzdGF0aWMgZmlsZSBzeXN0ZW0gaW5mb3JtYXRpb24uCiMKIyBVc2UgJ2Js
--

  Note the weird "ontent-Type" and the version not being quite right.

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

  Noted.

> 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");

  Thanks.  That seems to be causing me the same pain, but I'm not
 100% sure if the bug isn't mine.  It could be I'm doing something
 daft with the message that I've not yet spotted.

> 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.

  Sure thing, that makes sense.

  I guess I'm struggling here because I assumed that each message would
 have an explicit content-type:text/plain section with my "simple" message
 inside it.

  Because on the receiving side I'll only display such a thing.  (i.e.
 The receiving side will only display the first text/plain part.  I can
 see the messages I've generated but they show up as empty bodies with
 valid attachments.  Progress, but not quite right!)

> 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).

  That's interesting.  I guess I need to pay more attention.

  Thanks again :)

Steve
--