Fwd: MIME, attachments, and few more things

On 7/31/07, Matt Ronge <mronge-ePFkAnfr6dRWk0Htik3J/[email protected]> wrote:
>
> On Jul 30, 2007, at 4:01 PM, DINH Viêt Hoà wrote:
>
> What are your thoughts on this Hoa?
>
> Sure, though, it would have to be renamed to
> mail_imap_uid_list_to_env_list() and
> mail_imap_flags_to_flags() (or
> given access through such functions).
> (scheduling it for work this week-end)
>
> Sounds great! I might try and play around with changing it too. I'd like to
> get more involved in libetpan and give a little bit back.

If you have a patch for this, I can integrate it. (patch have to be
provided as diff -u, diff -Naur to build a patch of a while tree)

> Another question, I noticed that in a number of places,
> mailmime_fields_new_encoding(MAILMIME_MECHANISM_8BIT); is
> used. Why is
>
> 8BIT always used? What if the client and server doesn't support 8BIT?
>
> Could you give a detailed description of the place where it is used
> ?
>
> I saw it in two places:
>
> mailmime_types_helper.c:1057
>
>
>
> struct mailmime * mailmime_multiple_new(const char * type)
> {
>   struct mailmime_fields * mime_fields;
>   struct mailmime_content * content;
>   struct mailmime * mp;
>
>   mime_fields =
> mailmime_fields_new_encoding(MAILMIME_MECHANISM_8BIT);
>   if (mime_fields == NULL)
>     goto err;
>
>
>   content =
> mailmime_content_new_with_str(type);
>   if (content == NULL)
>     goto free_fields;
>
>
>   mp = mailmime_new_empty(content, mime_fields);
>   if (mp == NULL)
>     goto free_content;
>
>
>   return mp;
>
>  free_content:
>   mailmime_content_free(content);
>  free_fields:
>
> mailmime_fields_free(mime_fields);
>  err:
>   return NULL;
> }
>
>
> I also saw it in some of the etpanX code,
> etpan-message-composer.c:254
>
> Code is similar to the above snippet. Is it ok to always use 8BIT like that?

<<
   As stated in the definition of the Content-Transfer-Encoding field
   [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
   permitted for entities of type "multipart".  The "multipart" boundary
   delimiters and header fields are always represented as 7bit US-ASCII
   in any case (though the header fields may encode non-US-ASCII header
   text as per RFC 2047) and data within the body parts can be encoded
   on a part-by-part basis, with Content-Transfer-Encoding fields for
   each appropriate body part.
>>

The thing is that for text part encoding, I also use UTF-8 encoding.
So that iso-8859-1 encoded text part keep they original form as much
as possible but I guess, this is no more up-to-date. I should encode
them in quoted-printable if there are some 8bit characters and set
7bit for multipart encoding.

> Finally, is there any code in etpanX or in libetpan that is used to
> determine what MIME type should be used for an attachment? IE: Like if
> the file is *.jpg then it will know to use image/JPEG.
>
> I have no code to do that.
> /etc/mailcap is something more or less standard to do describe how to
> choose a MIME type. Though, that's not used on Mac OS X.
> On Mac OS X, maybe the following file could help:
> /System/Library/Frameworks/Foundation.framework/Resources/types.plist
>
> I wonder why /etc/mailcap isn't used in Mac OS X?

Hmmm maybe /etc/mime.types is a better way to go.
I think that some implementation of how to read this file could be
found on the internet.
maybe apache implements this.

--
DINH Viêt Hoà

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/