Re: multipart/alternative question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thursday, July 16 at 08:18 PM, quoth lee:
>> The definition of "attachment" is not as clear as you would think.
>> For example, we tend to think of MIME components whose type is
>> text/* as not being "attachments", but sometimes they can be (e.g.
>> if I sent you a txt file).
>
> Yeah, but mutt already has a way of showing a list of attachments.
Those aren't attachments, they're MIME components. There's a
difference, at least in modern lingo. MIME components have *semantics*
that are important. For example, if someone sends me a message that is
a multipart/alternative container with both a text/plain component
(that simply says "Your reader cannot read HTML!") and a text/html
component, *very* few people would consider that message to have THREE
attachments, besides the fact that it has three MIME components.
> If you have used the mail client built into Mozilla, it would
> distinguish between forwarding messages inline vs. as attachment.
> And inline was actually inline, while attachment was attachment.
>
> So what's the difference between "inline" and "attachment"?
In the case of forwarding mail? The difference is usually between
"copy the text of the forwarded mail into the text of a new mail, and
maybe quote it or indicate that it came from another message somehow"
(that's "inline") and the alternative "preserve the original message
EXACTLY and encapsulate it within a separate MIME container appended
to the MIME structure of a new message" (that's "attachment"). Mutt
does similar things based on the $forward_mime setting.
Unfortunately, those terms mean different (albeit related) things in
the sense of MIME disposition. In MIME disposition terms, "inline"
means "display the contents of this MIME component when the reader
views the mail" and non-inline means "don't display the contents of
this MIME component when the reader views the mail".
>> Here's a wacky message structure my mom sent me (using Apple Mail):
>>
>> 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]
>>
>> I haven't set up attachment detection properly, so %X says this
>> message has 0 attachments.
>
> All the attachments of this message are designated inline. But you can
> even set
>
> attachments +A */.*
> attachments +I */.*
>
> and mutt doesn't count attachments that are inline.
Yes it does. But it doesn't recurse into some MIME containers (as
we've been discussing).
For example, I have a message with the following MIME structure:
I 1 <no description> [text/plain]
I 2 forwarded message [message/rfc822]
I 3 `-><no description> [text/plain]
With your two rules, mutt tells me that this message has ONE
attachment. They're ALL inline, so *something* got counted!
As I understand it (David would know for sure) the "main body" of the
message (MIME component #1) doesn't count toward the total. Also, mutt
doesn't look at the sub-components of MIME component #2 (why? I don't
know), so there is only one attachment: component #2 itself.
> (Imho, there's no such thing as an "inline attachment". Something is
> either attached or inline, and it cannot be both. Creating mails
> with inline attachments is silly.)
Then you're not understanding the idea.
It's all about *display*. Do you want the contents a given
"attachment" (or MIME component) to be *displayed* when the rest of
the message is displayed, or do you want it to be represented more
succinctly, merely letting the viewer know that it exists? The former
is an "inline" attachment, the latter is a non-inline attachment.
If you include a JPEG in an email, should that JPEG be displayed when
the user views the message, or should it just show up as an icon that
can be downloaded and saved to disk? If you want it to display when
the user opens the message, is that JPEG "attached" to the message?
(if it is not attached, how would you describe its relationship to the
message?) Should the user be able to save it separately from the rest
of the message? Should it be allowed to have a filename associated
with it?
The answers, according to the standard RFCs, is that yes, that JPEG is
"attached" to the message, yes it can have a filename, and yes the
user should be able to separate the picture from the rest of the
message. It is merely an "inline attachment".
~Kyle
- --
It is easier to be critical than to be correct.
-- Benjamin Disraeli
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKX+tbAAoJECuveozR/AWeG/kP/1qmGQ15hDy64hXZsPP7h3XL
bYVF0zhSCRNxSYluj0puDqLNEqyRTJR+UbmtFSNK5dHOKNwx0OknNrCly6vPPhsi
6/SEIInLp2hzNtOxTWgGtGFJre0RJdeQZm/suvXiq/xmLX2oplcWoF0yPDNmw5c3
e1A2Ye+/oK1R+0DmM+/8KaGVf0UXl9JSrxv5RZ8E004wtVFONX4r8cvuTVOSis9v
YwRV2Oh8hpgXxF8e2ZmOIN10lVoNS/My6CaBTmF16T/SjDxWI3gbYTCmv6E6zKFh
gjvf6eJEpNEoYCbJXeyr6Ng/tgNZgiFnsNWCu4fYoD6fQq0N4sKoU3zl2lGYsjF9
dOXt3YdAmKm3ApGJ79mrUUa1Qnr2bVUvGirrCQCCBbT5Wji35eVRDTNaNzFw65FS
2tfWwgGHaJs9ZyE/flZtOBaru/REOds4D8S9UiMEB15mZUKzXG9K8sVWtcHwbbv3
tl3qmemsrXZCsJuh//G1poYBi35840ZLpX4kseE07h0T8xe+SzzR5WsyA/XCd2fY
lwxJWZIEYrFlALpPm+cUg4huPNlaRl9RKBYFAzJw7HpWPtc4u58kE9ZNsV0UBJI0
raVKtWeRN7d++Q9Jmxxn5gc5j1P2EfvhPCfMmgFuIZYFJDWA2B2fK/OWmvRtCejH
K5YW/RxteJxbDUMp0k2+
=0aZp
-----END PGP SIGNATURE-----