attachments not shown

Discussion:

Yubin Ruan

2018-02-02 02:45:33 UTC

Hi,

I got three attachments in a mail, as shown in the attachment view:

[multipart/alternative, 7bit, 97K]
[text/plain, quoted, utf-8, 9.2K]
[text/html, quoted, utf-8, 87K]

After using the editor to view the whole email, it seems to me that the
[multipart/alternative] part is an alias for both the [text/plain] and
[text/html] part, because from what I have seen, there is no actual content in
the [multipart/alternative] part. Instead there are just some pointers:

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3237106_526482122.1517522433475"
To: =?UTF-8?B?6Ziu57695b2s?= <***@gmail.com>
Date: Thu, 1 Feb 2018 22:00:33 +0000 (UTC)
X-LinkedIn-Class: CED
X-LinkedIn-Template: email_feed_ecosystem_digest_01
X-LinkedIn-fbl: m2-aszwv6yn2cyx11t27w2a5c2iw6ykfaqm3z4r4y5utivh7zm3r8pfdnpmndytd6fy0d1g032mbv6i8vhn8tppibujje9ixay0t8s8xc
X-LinkedIn-Id: 6mvow3-jd475j9d-y4
List-Unsubscribe: <https://www.linkedin.com/e/v2?e=6mvow3-jd475j9d-y4&t=lun&midToken=AQFSR-6AohV2qQ&ek=email_feed_ecosystem_digest_01&li=55&m=unsub&ts=unsub&loid=AQGfHwfVJDz4lAAAAWFTYrQP3DmU3nR4Vc7hiisLwhhS62wLY-Uz96VXZKmDjXHXWjHB9ul6Sf7-NkW9WoU8nPw4_e-Dt8De4ThCER44&eid=6mvow3-jd475j9d-y4>
Feedback-ID: email_feed_ecosystem_digest_01:linkedin
Require-Recipient-Valid-Since: ***@gmail.com; Sat, 14 Feb 2015 07:45:15 +0000

the [text/plain] part looks like:

------=_Part_3237106_526482122.1517522433475
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-ID: text-body

LinkedIn Highlights

Should I tell coworkers my salary?

264 people are talking about this

https://www.linkedin.com/comm/search/results/content/?keywords=3DShould+I+t=
ell+coworkers+my+salary%3F&origin=3DFED_EMAIL&anchorTopic=3D506458&midToken=
=3DAQFSR-6AohV2qQ&trk=3Deml-email_feed_ecosystem_digest_01-hero-1-null&trkE=
mail=3Deml-email_feed_ecosystem_digest_01-hero-1-null-null-6mvow3%7Ejd475j9=
d%7Ey4-null-neptune%2Fsearch%2Eresults%2Econtent&lipi=3Durn%3Ali%3Apage%3Ae=
mail_email_feed_ecosystem_digest_01%3BrxyHuw3NTWi4n8fHNW81ig%3D%3D

=20

...more content here...

and the [text/html]:

------=_Part_3237106_526482122.1517522433475
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-ID: html-body

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.=
w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns=3D"http://www.w3=
.org/1999/xhtml" lang=3D"en" xml:lang=3D"en"> <head> <meta http-equiv=3D"Co=
ntent-Type" content=3D"text/html;charset=3Dutf-8"> <meta name=3D"HandheldFr=
iendly" content=3D"true"> <meta name=3D"viewport" content=3D"width=3Ddevice=
-width; initial-scale=3D0.666667; maximum-scale=3D0.666667; user-scalable=

...more content here...

the problem is, even though there are three attachments, only one is shown. I
already have a

auto_view text/html

set in my .muttrc, yet the [text/html] is not shown (I can view the
[text/html] attachment in the attachment view, though ). AFAIK, mutt will try
to display all attachments automatically as long as it can be autoviewed. Is
there any configuration options I miss here?

--
Yubin

Cameron Simpson

2018-02-02 03:30:16 UTC

Permalink

Post by Yubin Ruan
Hi,
[multipart/alternative, 7bit, 97K]
[text/plain, quoted, utf-8, 9.2K]
[text/html, quoted, utf-8, 87K]

That's really 2 attachments. The text/plain and text/html parts are _enclosed
by the multipart/alternative part, which exists to offer two or more choices
which are meant to be equivalent.

Post by Yubin Ruan
After using the editor to view the whole email, it seems to me that the
[multipart/alternative] part is an alias for both the [text/plain] and
[text/html] part, because from what I have seen, there is no actual content in
the [multipart/alternative] part.

Yes, it is just an enclosure. In fact it is likely that the message itself is
the multipart/alternative part, containing a text/plain and a text/html within
it. But you can nest multipart sections if you need to.

[...]

Post by Yubin Ruan
the problem is, even though there are three attachments, only one is shown. I
already have a
auto_view text/html
set in my .muttrc, yet the [text/html] is not shown (I can view the
[text/html] attachment in the attachment view, though ). AFAIK, mutt will try
to display all attachments automatically as long as it can be autoviewed. Is
there any configuration options I miss here?

Ah, no.

What you've got looks like this, structurally:

multipart/alternative
text/plain
some plain text ...
text/htmnl
some HTML text ...

The main text/ area is the "message" part. When mutt displays a message from a
multipart/alternative section it chooses _one_ of the alternatives offers, and
transcribes that to a plain text appearance using the rules from your mailcap
settings (which may just be the system defaults).

A message with "attachments" comes with the type "multipart/mixed", indicating
that it contains a mixture of parts, almost always a "message" part with the
text and other parts being the zttachments, such as zip files. A mail message
with attachments usually looks like this, structurally:

multipart/mixed
multipart/alternative
text/plain
some plain text ...
text/htmnl
some HTML text ...
image/jpeg
a JPEG image, suitably encoded
application/pdf
a PDF file

and so forth.

So what you have is a plain text message with no "attachments". The mutt
"attachement" menu shows you all the parts, but more conventional mail readers
withn't present the text area as an "attachment".

Regarding your beleif that you're getting the text/plain presented, this may
well be so. Your setting:

auto_view text/html

is documented here:

http://www.mutt.org/doc/manual/#auto-view

It says that you know how to present text/html as plain text for viewing in the
"pager" mutt view. It will look up a mailcap entry for "text/plain" which has
the "copiousoutput" option. If you or your system doesn't have such an entry
the "auto_view" setting is probably ignored. So mutt may be choosing the
text/plain alternative because of this.

There is a system mailcap file and you can also have a personal $HOME/.mailcap
file. Mine has this:

text/html; exec 2>&1 && env DISPLAY= unhtml %s; copiousoutput

and "unhtml" is a script of mine which currently calls "lynx -stdin -dump", and
used to run "w3m -dump -T text/html". So you could use:

text/html; w3m -dump -T text/html; copiousoutput

to tell mutt how to present HTML as plain text.

Mutt needs such things because the pager presents plain text.

Cheers,
Cameron Simpson <***@cskk.id.au> (formerly ***@zip.com.au)

Yubin Ruan

2018-02-02 03:42:47 UTC

Permalink

Post by Cameron Simpson

Post by Yubin Ruan
Hi,
[multipart/alternative, 7bit, 97K]
[text/plain, quoted, utf-8, 9.2K]
[text/html, quoted, utf-8, 87K]

That's really 2 attachments. The text/plain and text/html parts are
_enclosed by the multipart/alternative part, which exists to offer two or
more choices which are meant to be equivalent.

Yes, it is just an enclosure. In fact it is likely that the message itself
is the multipart/alternative part, containing a text/plain and a text/html
within it. But you can nest multipart sections if you need to.
[...]

Ah, no.
multipart/alternative
text/plain
some plain text ...
text/htmnl
some HTML text ...
The main text/ area is the "message" part. When mutt displays a message from
a multipart/alternative section it chooses _one_ of the alternatives offers,
and transcribes that to a plain text appearance using the rules from your
mailcap settings (which may just be the system defaults).
A message with "attachments" comes with the type "multipart/mixed",
indicating that it contains a mixture of parts, almost always a "message"
part with the text and other parts being the zttachments, such as zip files.
multipart/mixed
multipart/alternative
text/plain
some plain text ...
text/htmnl
some HTML text ...
image/jpeg
a JPEG image, suitably encoded
application/pdf
a PDF file
and so forth.
So what you have is a plain text message with no "attachments". The mutt
"attachement" menu shows you all the parts, but more conventional mail
readers withn't present the text area as an "attachment".
Regarding your beleif that you're getting the text/plain presented, this may
auto_view text/html
http://www.mutt.org/doc/manual/#auto-view
It says that you know how to present text/html as plain text for viewing in
the "pager" mutt view. It will look up a mailcap entry for "text/plain"
which has the "copiousoutput" option. If you or your system doesn't have
such an entry the "auto_view" setting is probably ignored. So mutt may be
choosing the text/plain alternative because of this.
There is a system mailcap file and you can also have a personal
text/html; exec 2>&1 && env DISPLAY= unhtml %s; copiousoutput
and "unhtml" is a script of mine which currently calls "lynx -stdin -dump",
text/html; w3m -dump -T text/html; copiousoutput
to tell mutt how to present HTML as plain text.
Mutt needs such things because the pager presents plain text.

Thanks for your explanation about [multipart/alternative] and
[multipart/mixed]. I check several mails and they all seems to work in the way
you described.

--
Yubin

Cameron Simpson

2018-02-02 07:10:50 UTC

Permalink

Also, you can configure the order mutt displays them in, for example, I
alternative_order text/calendar text/plain text/enriched text/html test/*
Sometimes it does screw me up if the text/plain and text/html parts of a
multipart/mixed messages aren't actually equivalent as they're supposed
to, and I end up missing part of an email because Mutt doesn't show it
to me based on my configured order.

Yeah. Fortunately such things are still few enough to track. I've got this in
my muttrc:

message-hook '%f htmlers | ~f @no-***@cc.yahoo-inc.com | ~f @outlook.com | ~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order text/html text/plain'

So that mutt picks the HTML first for people in the "htmlers" group and an
assortment of other known broken senders. My default is tex/plain first.

Cheers,
Cameron Simpson <***@cskk.id.au> (formerly ***@zip.com.au)