attachment count issue with multipart messages

[Will Fiveash]

I've received a message from an iPhone that has a MIME structure as
follows:

1 <no description> [multipa/alternativ, 7bit, 48K]
2 ├─><no description> [text/plain, 7bit, 0.1K]
3 └─><no description> [multipa/related, 7bit, 47K]
4 ├─><no description> [text/html, 7bit, 0.5K]
5 └─>Photo [image/jpeg, base64, 46K]

While I have an index_format setup to display the # of attachements
mutt is showing 0. In .muttrc I have:

set index_format="%4C %Z %{%m/%d/%y} %-15.15F %?M?(#%03M)?([%X]%4c) %s"

attachments +A */.*
attachments +A image/jpeg
attachments +A application/octet-stream
attachments -A text/x-vcard
attachments -A application/pgp.*
attachments -A application/(x-)?pkcs7-.*
attachments -A message/external-body
attachments +I application/octet-stream
attachments +I application/pdf
attachments +I image/.*
attachments -I message/external-body

I'm expecting that the Photo (image/jpeg) attachment would cause mutt to
display at least 1 for the attachment count in the Index view. Does my
.muttrc config need to be modified and if so, how?

[Michelle Konzack]

Hello Will Fiveash,

Post by Will Fiveash
I've received a message from an iPhone that has a MIME structure as
1 <no description> [multipa/alternativ, 7bit, 48K]
2 ├─><no description> [text/plain, 7bit, 0.1K]
3 └─><no description> [multipa/related, 7bit, 47K]
4 ├─><no description> [text/html, 7bit, 0.5K]
5 └─>Photo [image/jpeg, base64, 46K]

Sometime back I had to write a script which send such messages and I had
to figured out that it must be:

1 <no description> [multipa/related, 7bit, 47K]
2 ├─><no description> [multipa/alternativ, 7bit, 48K]
3 ├ ├─><no description> [text/plain, 7bit, 0.1K]
4 ├ └─><no description> [text/html, 7bit, 0.5K]
5 └─>Photo [image/jpeg, base64, 46K]

So, the iPhone app is wrong

Post by Will Fiveash
I'm expecting that the Photo (image/jpeg) attachment would cause mutt to
display at least 1 for the attachment count in the Index view. Does my
.muttrc config need to be modified and if so, how?

The Photo is NO ATTACHMENT but a part of the multipa/related stuff.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux

***@tdnet France EURL ***@tdnet UG (limited liability)
Owner Michelle Konzack Owner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France 77694 Kehl/Germany
Tel: [phone] mobil Tel: [phone] mobil
Tel: [phone] fix

<http://www.itsystems.tamay-dogan.net/> <http://www.flexray4linux.org/>
<http://www.debian.tamay-dogan.net/> <http://www.can4linux.org/>

Jabber ***@jabber.ccc.de
ICQ #328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/

[David Champion]

Post by Will Fiveash
I've received a message from an iPhone that has a MIME structure as
1 <no description> [multipa/alternativ, 7bit, 48K]

Mutt's attachment counter does not recurse through multipart/alternative
MIME parts. See parse.c:1556. I checked the latest version of this
patch that I made before it was mainlined 5 years ago. While several
things were simplified to get that patch upstream, it has the same logic
for multipart/alternative. I'm afraid I don't remember for sure why I
made this choice, but it's probably because there's no objective basis
for deciding which alternative in a multipart/alternative should be
analyzed. Counting attachments among all available alternatives is
almost certainly not what a user wants.

In principle the attachment counter could follow display rules and
choose the "preferred" alternative based upon alternative_order,
etc. This crosses an imaginary boundary between describing the
absolute structure of the message and making subjective decisions
about interpretation, but there's nothing logically incorrect about
it. However there could be unwated computational expense in that
approach. In 2005 at least there was pretty serious concern about the
computational cost of counting attachments at all, so in order to get
the code upsteam I took all possible steps to minimize that.

Post by Will Fiveash
2 ??????><no description> [text/plain, 7bit, 0.1K]
3 ??????><no description> [multipa/related, 7bit, 47K]
4 ??????><no description> [text/html, 7bit, 0.5K]
5 ??????>Photo [image/jpeg, base64, 46K]

Note that when iPhone sends a multipart/related message with text and
image parts -- when it sends just the mp/related subtree of the message
you have -- mutt does notice and count the jpeg. (I tested this by
sending email from the SMS/MMS app on an iPhone.) So it's certain that
your problem is caused by having a mp/alternative that envelops the
mp/related.


Michelle Konzack wrote that iPhone's appraoch is wrong. I guess it's
somewhat a matter of interpretation: is the text message a textual
representation of an HTML message that includes one JPEG, or does the
JPEG accompany a message which can be represented as HTML or as text?
It probably depends on how you see the relationship between the image
and the message. FWIW I tend to agree with Michelle but I can see where
iPhone developers might think otherwise.

Even so though, your problem is a mutt limitation and not inherent
to the MIME structure, which is completely legitimate even if it is
conceptually flawed.

[Michelle Konzack]

Hello David Champion,

Post by David Champion
Michelle Konzack wrote that iPhone's appraoch is wrong. I guess it's
somewhat a matter of interpretation: is the text message a textual
representation of an HTML message that includes one JPEG, or does the
JPEG accompany a message which can be represented as HTML or as text?
It probably depends on how you see the relationship between the image
and the message. FWIW I tend to agree with Michelle but I can see where
iPhone developers might think otherwise.

I think it depends, because if the iPhone define the JPEG a CID:... Link
which is a part of the multipart/related stuff, then it is right because
appropriated Windows Mail clients show the image in the HTML part and it
is not considered as Attachment.

You can find infos in the M$ Knowledge Database to this stuff.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux

***@tdnet France EURL ***@tdnet UG (limited liability)
Owner Michelle Konzack Owner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France 77694 Kehl/Germany
Tel: [phone] mobil Tel: [phone] mobil
Tel: [phone] fix

<http://www.itsystems.tamay-dogan.net/> <http://www.flexray4linux.org/>
<http://www.debian.tamay-dogan.net/> <http://www.can4linux.org/>

Jabber ***@jabber.ccc.de
ICQ #328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/

[Will Fiveash]

Post by David Champion

Post by Will Fiveash
I've received a message from an iPhone that has a MIME structure as
1 <no description> [multipa/alternativ, 7bit, 48K]

Mutt's attachment counter does not recurse through multipart/alternative
MIME parts. See parse.c:1556. I checked the latest version of this
patch that I made before it was mainlined 5 years ago. While several
things were simplified to get that patch upstream, it has the same logic
for multipart/alternative. I'm afraid I don't remember for sure why I
made this choice, but it's probably because there's no objective basis
for deciding which alternative in a multipart/alternative should be
analyzed. Counting attachments among all available alternatives is
almost certainly not what a user wants.
In principle the attachment counter could follow display rules and
choose the "preferred" alternative based upon alternative_order,
etc. This crosses an imaginary boundary between describing the
absolute structure of the message and making subjective decisions
about interpretation, but there's nothing logically incorrect about
it. However there could be unwated computational expense in that
approach. In 2005 at least there was pretty serious concern about the
computational cost of counting attachments at all, so in order to get
the code upsteam I took all possible steps to minimize that.

Perhaps there could be a mutt MIME parsing recursion level option that
could be set to restrict the levels of multipart attachments that are
parsed if this is an issue for people? Of course I have no experience
as to whether allowing recursive parsing is too much of a performance
hit to be usable but in my case it may not be too bad since I'm reading
mail from mbox files that are updated via fetchmail(from IMAP
server)->procmail->mbox files.