* On 16 Jul 2009, Tim Gray wrote: > > > > I 1 <no description> [multipa/alterna, 7bit, 653K] > > I 2 |-><no description> [text/plain, utf-8, 2.0K] > > I 3 `-><no description> [multipa/mixed, 7bit, 651K] > > I 4 |-><no description> [text/html, quoted, windows-1252, 3.0K] > > I 5 |->Typeface Ideas.pdf [applica/pdf ...] > > I 6 `-><no description> [text/html, 7bit, us-ascii, 0.2K] > > This is exactly what I'm dealing with. Though sometimes it's not > multipart/mixed but multipart/relative. Regardless, I was not able > to set up attachment detection properly to pick up the > application/pdf.
It's actually not possible in this case. Message and multipart are the two major MIME categories which are containers. All other types are atomic, but these two always exist to contain other components (which may themselves be atomic or containers). The attachment-counting algorithm has a flag that decides whether to traverse (recurse) the container types while looking for attachments that qualify by your "attachments" rules. Multipart/alternative containers are specifically excluded from ever being traversed. Why? Because mutt at this stage has no way of knowing which alternative in a multipart/alternative you want looked at. It either needs to count all attachments within the multipart/alternative, which is most assuredly exactly the thing you least want, or it needs to guess which alternative represents the view that you want counted. So it ignores multipart/alternatives. However, I think that when mailers are behaving well, that's a fine decision. How often should an attachment that you're truly interested in actually be part of the multipart/alternative enclosure? I would argue that Apple's arrangement here, while valid MIME, is not a faithful representation of what the sender intended to send. She has a letter with an inlined PDF in the middle of it. If Apple Mail is honoring her intent, the children of the mp/alternative part should be two multipart/mixed parts, each containing two text parts with a PDF sandwiched in the middle. It eats space (unless you cite content by reference, as with cid: naming), but what Apple Mail has done excludes the PDF content from visibility in the text/plain view. So does that exist as an "attachment" or not? It depends on whether you're reading text or HTML. The best combination of efficiency and accuracy for this message would have been: multipart/mixed |-> multipart/alternative | |-> multipart/mixed | | |-> text/plain | | |-> application/pdf (reference, no content) | | `-> text/plain | `-> multipart/mixed | |-> text/html | |-> application/pdf (reference, no content) | `-> text/html `-> application/pdf (referent) ... but mutt doesn't support cid: references, so this wouldn't help us. :/ If you have ideas for how mutt could deal with this conundrum in a way that's compliant, consistent, and user-centered, I'm interested to hear. I'm not sure whether I'll have time to update the code, but it would be good to get the ideas onto the table. -- -D. d...@uchicago.edu NSIT University of Chicago