* On 10 Nov 2010, Will Fiveash wrote: > I've received a message from an iPhone that has a MIME structure as > follows: > > 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. > 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. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
