3

How do you handle mail attachments when checking mails in Mutt?

I have set up auto_view for HTML files :

bind  attach  <return>  view-mailcap
alternative_order text/plain text/enriched text/html text
unauto_view *
auto_view text/html

But if there are any images attached to the mail there is no way for me to know it, unless I go and check "view attachments".

Sometimes, the pager displays the following:

[-- Attachment #1: tutorial.pdf --]
[-- Type: application/pdf, Encoding: base64, Size: 320K --]
[-- application/pdf is unsupported (use 'v' to view this part) --]`

If [-- Attachment #1: x --] appeared every time it would be great, but it doesn't seem to work with inline pictures.

As a result, I have to remember to check it every time.

Is there a better way?

2

Mutt should show you attachments as long as they are part of a multipart/alternative MIME, no matter what the attachments are (it may say unsupported but the Attachment # line will be there). Yet, some email clients build the MIME as follows (notably Apple Mail and iPhone mail):

  I     1 <no description>             [multipa/alternativ, 7bit, 496K]
  I     2 ├─><no description>         [text/plain, quoted, utf-8, 3.5K]
  I     3 └─><no description>             [multipa/related, 7bit, 492K]
  I     4   ├─><no description>         [text/html, quoted, utf-8, 17K]
  I     5   └─>Screen Shot.png                [image/png, base64, 474K]

Mutt cannot deal with this image because the image is inside another multipart MIME, a MIME which is not meant to contain attachments. At least this is the scenario where my mutt does not display the attachments.

The reasoning behind it is that multipart/related is not meant to be used for attachments but display suggestions, according to the RFC

Reference:

  • If I add alternative_order multipart/related text/html text/plain to my config file, it displays the attachments from Mail.app but is it a bad idea ? – DaftWooly Aug 7 '16 at 14:26
  • 1
    @joyeuxlutin - Not really, it should be fine. There are people that have text/enriched as the first MIME in alternative_order and they survive. It is just something that you need to keep in mind, if an email displays as a CSS file when you open it (that's super rare) then you know that you need to hit v. – grochmal Aug 7 '16 at 14:43
  • 1
    Once upon a time you could display attachments with external applications based on the contents of mailcap. You could have multiple entries for the same MIME type, so that you could f.i. decode PDF files inline with pdftotext (and include the text in replies), and still view the file in acroread when going through the attachment menu. This worked fine for 15+ years. Then the current maintainers (I presume) decided they don't really understand what that part of the code was for, and removed that feature. Tough luck. – Satō Katsura Aug 7 '16 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.