Re: [gmime-devel] Accessing attachments including inline-parts.

[Steve Kemp <steve steve org uk>]

On Sat May 24, 2014 at 20:38:18 -0400, Jeffrey Stedfast wrote:

> >   As inline-parts don't contain filenames this results in the
> >  inline-parts not being visible.
>
> Be careful with this approach because this general rule isn't
> necessarily true. 

  Point taken; I guess the current problem with inline parts
 is the first failure case I've seen, until now it always looked
 like it was working.

> > The best way to determine if a MIME part is meant
> to be treated as an attachment or not is to check that the
> Content-Disposition value matches "attachment" (instead of "inline")
> in a case-insensitive comparison.

  Right.

> Your iterator loop above will iterate over all attachment and inline
> parts. You can use the following logic to determine if a part is an
> attachment (if it's not an attachment, then it is an inline part):
>
> GMimeContentDisposition *disposition =
> g_mime_object_get_content_disposition (part);
>
> if (disposition != null && disposition->disposition != null &&
> !g_strcasecmp (disposition->disposition, "attachment")) {
>     // the part is an attachment
> } else {
>     // the part is an inline part
> }

  This doesn't quite seem to be working how I expect, because
 the body parts are missing.

  If you have the patience I wrote a simple test-program which
 I've been using on messages:

    https://raw.githubusercontent.com/skx/lumail/master/util/attachments.c

  It looks like something is screwy getting the content, and I'm
 still not seeing the full number of parts that Mutt displays
 on some messages.

  e.g:

shelob ~/git/lumail/util $ ./attachments cur/x.msg\:2\,S 

Handling input message: cur/x.msg:2,S
XX  Inline part.
XX  Inline part.
XX  Inline part.
XX  Inline part.
Parsing has completed
We received 4 attachment(s).
    NAME: un-named size: 16
    NAME: un-named size: 16
    NAME: un-named size: 16
    NAME: un-named size: 16


  vs.

  I     1 <no description>                                                                                    
   [multipa/mixed, 7bit, 7.2K]
  I     2 ├─><no description>                                                                              
[text/plain, quoted, utf-8, 0.1K]
  I     3 └─>Weitergeleitete Nachricht - Re: [lumail]                                                         
  [message/rfc822, 7bit, 6.8K]
  I     4   └─><no description>                                                                             
[multipa/alternativ, 7bit, 1.9K]
  I     5     ├─><no description>                                                                          
[text/plain, quoted, utf-8, 0.6K]
  I     6     └─><no description>                                                                           
[text/html, quoted, utf-8, 1.0K]
  I     7 This is a digitally signed message part                                                           
[applica/pgp-signat, 7bit, 0.2K]

  The count differs ("4 vs 7") and the sizes are bogus.

Steve
--