Re: multipart/alternative question
* 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. dgc@xxxxxxxxxxxx NSIT University of Chicago