-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
guidance.
> 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
local environment.
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
> HTML.
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
multipart/alternative.
> 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)
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?
~Kyle
- - --
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!
iQIcBAEBCAAGBQJKX23MAAoJECuveozR/AWeyZUQAKPYs9TtckaBSg8vOAvFBDhh
hZoJuj2ek8M/8Yul8NHz92+/VHOCZ+qJ15gGYughbiaDRvmo5roOehg3ocNLbqGE
ilKt4KdKnIKRB8O/MIZxjLDRmjaqd5nJA7a78zYLAJzU9g5vqgHFbgt0QmAzpqEb
O4CBL/7I6OsN3qBZOLUNgw2qmAJLYyRTrqLXD6RxW2XstXL2djsQLrey+mEYxg1f
RRUmuqFBJm++J7y3nkVli1icMiIr0/wbbq2e57pO04mXAzIBjS568P1nCDTPldyO
JSxg9ZUMVxC10vpnEdszlUWrHbgxXcr0D9eXBlPpjHGFG25FiOVHD+EnEjqbMfJH
J30apJQQ8baGRg0MtCEkByuTcBqlPKph6HILDcZW0VmQGpQLE9Re8sYWuKEDk4z/
x6kMu9eLGwlBvMlPjMQqPemMVXEzxMhRLsVYxnLFATclUnvLj9D+5q2YtI25SLPl
xYiprv4bOCmLem02ddxTYRXkqFCPTJccvt82nJ1Z1pGOFko/WBSm/vK6//p6kOCd
hsZ56ogvl6JL0RNMLP4RPxQ+ajxEzR/NELeuhPoT/vDcBoBKp3+04cIa9Pkq5kAM
pazmE0Zvtan9QfDuolI4MwMmj6yAhpxYAcZEHBjagYj8Z8P1/NAgAFNe5PRczssH
73TUf+sKMFwBp6u9k+wz
=TQWq
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKX23+AAoJECuveozR/AWefa0P/1kLqI8+5jY1MoV2QyruBTnO
XXM806pQj+7b2IB3sBawNCR+xKfJ0dKq1ENWTitCpAYm2Fx6tJ1R1UEuoWfT6nz3
okNPGUubAOy0ybn17NKJj+zudS90mxbsG3RlnAoJX7Tn/i6zUgDuu//9avOZQXtb
DshTKeIzqgII+i8GQoPLDlBMg8hVK/9RjjkpX6uEvTiIKfOLykenQxlglAFQ07/q
5AxPwuSlkgEDo7sp9OLPuC9qfL/XpwnMloriff6kpLy1W8zdCN1G5JOx9Qj29MZJ
dFx7leWRss0uAus6tGv0iCEU9qOUdwfsCO4HLD8pYYXhsEexktenGXQGqGflVkpv
xIJd8npc9ZQPhGMiYXY1Wql/+f6MjqNrnuRGwIDV3WYo+Mfp/QU6ISqONroOp2DO
VpuPtMJrKe4HV5GLHnyzudnRoWpOzuLzy1ekeabYlBCsCm741Kz9DR2l8ZtBjSLN
FifzBMVDOO+0CHk4xIPRHMx9Dxh4vK/qiprNWOtXrLuHqrYhaIlEA+QD17zd8ejH
sbSJynicqO+Jysd56t9Z2N8E4TbzWnYebHtmWSIUNdebK82o1LXCos4UK83jqBMe
6gLIzZLX8BMlUci4skMEICO+RTTyGpJTJ5Mptt6DfZv0EHSVw9EFd4RJEu2ETokx
WmkdTq/pFss6ICIErwqG
=E9ea
-----END PGP SIGNATURE-----
