Re: multipart/alternative question
-----BEGIN PGP SIGNED MESSAGE-----
- -----BEGIN PGP SIGNED MESSAGE-----
On Thursday, July 16 at 10:49 AM, quoth David Champion:
> 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.
Well, it's not an issue of "which alternative I want to look at",
because even if the attachment counter obeyed my alternative_order
rules, I prefer to look at the text alternative.
> 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.
I think we can do better than that, by looking to the MIME RFC for
> 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.
I agree, to a point. The MIME RFC (1521) describes the
multipart/alternative type with a recognition that the alternatives
are not *equivalent*. To wit:
As with multipart/mixed, the order of body parts is significant.
In this case, the alternatives appear in an order of increasing
faithfulness to the original content. In general, the best choice
is the LAST part of a type supported by the recipient system's
By that logic, Apple is not even required to provide an especially
faithful representation of the email in the first alternative, as long
as it has a very faithful representation in the last alternative.
Often we think that the difference is primarily formatting, but the
RFC doesn't say that.
Thus, for attachment counting purposes, we can reasonably decide to
ALWAYS count *only* the attachments within the last alternative in a
multipart/alternative MIME section. That's the one that should best
reflect the "original" content, and thus that's the one that best
reflects the intention of the user. It's technically possible to have
attachments in other parts of the multipart/alternative, but by
definition they are supposed to be somewhat less-faithful
representations of the sender's original content, and so I don't think
they should count toward the grand attachment total. But any
attachments in that last alternative *SHOULD* count.
If you want to add a config option to allow it to count ALL
alternatives, that's fine by me, but I think counting only the last
alternative is perfectly reasonable and compliant.
The thing I like about this idea is that if someone sends a
multipart/alternative that has the attachment in an earlier component
but not a later component, we can point to the RFC and say "you're
doing it wrong; the LAST component is the one that's supposed to have
all the fancy stuff." (I.e. the choice to count only the last
alternative is a defensible one.)
> 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.
I think it all depends on what you mean by "intent". Another way of
looking at it is that Apple sent me her original content, formatted
exactly the way she wanted, and additionally sent me a text-like
representation of what she sent, just in case I can't render HTML.
> 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
Granted, mutt will only *display* the attachment inline if you view
the message as text/html, but whether it's displayed or not should
have nothing to do with whether it counts as an attachment. I think t
should counts as an attachment if a) I consider inlined PDFs to be
attachments and b) it is in the last component of the
> The best combination of efficiency and accuracy for this message
> would have been:
> |-> 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)
Yeah, but... that's so ugly and inefficient, I don't blame Apple for
sending a smaller, simpler message (that complies with the letter and
original spirit of the RFC).
By the way... would mutt's attachment counting view that as three
attachments or only one? (Yes, I know multipart/alternatives are
ignored, but let's say the structure was flattened a bit.) In other
words, does mutt's attachment counting understand references?
- - --
Eskimo: If I did not know about God and sin, would I go to hell?
Priest: No, not if you did not know.
Eskimo: Then why did you tell me?
-- Annie Dillard
- -----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
-----END PGP SIGNATURE-----