Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Saturday, July 18 at 02:41 PM, quoth lee:
 Hmm, well, I guess I see your point, but not even mutt supports 
 batch-decoding like that. Do you perhaps have a perl script of some 
 kind that you use to bulk-decode like that?

 Unfortunately not; but I haven't needed one yet. Saving whole 
 containers is merely a possibility that comes to mind when considering 
 attachments as containers that contain something. That's something I 
 didn't do before. Once you do, it's evident that a MUA could have a 
 way to save a whole container like that.

 Perhaps we should make a feature request?

Well, I was thinking that it might be possible using tags and piping 
with a slick perl script, that you could glue together with a macro..

 Speaking of which, I sometimes wished that I could just attach a 
 whole folder instead of having to attach all the files separately.

You *can* do the tag-and-attach approach. Saves time over attaching 
each file independently.

 Since pictures can be large, the user should be able to specify a 
 size limit after attaching a folder (or large files) to a message, 
 and the MUA should automatically split the thing up as needed.

 These mime guys did only part of the job --- or maybe it's the MUA 
 developers.

It's the MUA developers. MIME supports a message/partial entity type 
(section 7.3.2 of RFC 1521), which allows a message (i.e. a MIME 
structure) to be split up across multiple emails. Outlook Express 
supports it, but it's the only MUA I know of that does. The origin of 
the idea was to avoid problems with slow unreliable modems that 
periodically disconnected, so that if you've only partially uploaded 
your giant email to someone, at least part of it will have been sent 
(and received)... it just can't be decoded  viewed until you've sent 
all the pieces of it. It could also be used to circumvent limits on 
single message sizes.

 So where's the full MUA support of the mime stuff?

Good question.

For what it's worth, another way to segment large files (or 
collections of files) is to use the shell utility `split` (and the 
recipient can use `cat` to put them all together again). Combine that 
with `tar`, and you can pretty efficiently chunk up large collections 
of files. Then, again using your shell (assuming all the segments are 
in a folder called segments), you can send those segments using 
mutt, like this:

 for F in segments/* ; do
 mutt -s segment $F -a $F -- recipi...@example.com
 done

Not exactly *convenient*, though... but unless your recipient is using 
Outlook Express, there's not much point in using a MIME trick that 
they can't take advantage of.

 The content doesn't matter. No message without headers, but headers 
 are content.

A fair point. Kind of like saying no file without an inode.

 So... it sounds like, because it's English, words got re-used and 
 redefined into confusion.

 Hm. I was about to say that it doesn't have to be that way, but, since 
 I'm German, I find that English, at least American English, is mott 
 very sloppy and indistinctive with things. There are distinctions I 
 naturally make in German that nobody makes in English. That means 
 they are not aware that there is the possibility of making a 
 distinction. English doesn't allow them to think of one, it sets 
 limits. I can't tell if that's really true because I might not feel 
 that way if English was my native language --- and it's impossible to 
 tell because if English was my native language, I wouldn't be aware of 
 the possibility (unless I learned another language, maybe).

English has its trade-offs, like most things. While it is a bit sloppy 
and leaves a lot up to interpretation, that leads to lots of fun 
double- or triple-entendres (which has benefits in the realms of 
poetry, humor, and other forms of literature), and lets us use nouns 
as verbs, among other things. By not requiring the speaker to make 
distinctions about everything, it leaves a lot more room for 
interpretation, which is both liberating and frustrating for the exact 
same reason.

~Kyle
- -- 
The fact that we live at the bottom of a deep gravity well, on the 
surface of a gas-covered planet going around a nuclear fireball 90 
million miles away, and think this to be normal, is obviously some 
indication of how skewed our perspective tends to be.
   -- Douglas Adams
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKY3nmAAoJECuveozR/AWekz8QAIlUPfrwS+cPRCRlBqNzb8F9
k0LYtU6JzkScYvQpdYZWKcHhoPKAPKrc/7TRneaMUBQVkqnlxuV02x3peaTRTY16
KKmXx+Oviw6/MRHBRQR+F9lqTqjEJEXf/GJDRXjfZb66ZhtwCPzu+d8DKAQ5jhE2
N6c8EpN9iscETgA4yRHs+f4MBuutKKbFy8hZ7+7hpI565Jb+YBRaQl0cJ+spJWVO
c+NG7ePQjsASX26USru34Sra0FeNzH5+VCWS9GoxBYKPdjJT53b4p4j4gukIDkgI
/IRuvmkZuAlOYlio1XN8+786iSz4We5E+HkMv57JaGKruxAEhoYjUSLMfjmPYlj7
72Mp0XwndhIbbjKrSdSWZcFp0Mk3+GER8mT9JCZh89R3WL8Eym2yYGWanKAv74Pv

Re: multipart/alternative question

[lee]

At Sun, 19 Jul 2009 04:50:05 +0100,
Noah Slater wrote:
 
 On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
  On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
   On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
 To the best of my knowledge, it isn't defined anywhere. But that 
 doesn't matter.
 The common understanding of an attachment is that it is a file, with 
 a filename,
 that has been sent as a separate item from the message.
   
Well, then most people have a wrong understanding.
  
   This is an absurdly prescriptivist statement.
 
  I'm not sure what prescriptivist means.
 
 In other words, if most people think attachment means X then, by
 definition, attachment means X - regardless of your personal preference for
 what it should mean. This is how language works.

Ah, I see what you mean. But aren't RFCs prescriptive by nature? And
if they are, it's silly to say that a statement resulting of an
interpretation of an RFC is absurdly prescriptive. --- The
interpretation can be wrong, but that's another question.

  A simple email message doesn't have any HTML components.
 
 That depends on what you mean by simple

sure does

  You probably wouldn't get any valid results from such a survey because
  the percentage of people who wouldn't know what you're talking about
  would be too high.
 
 I think that would probably support my thesis. Heh.

I don't see how invalid results could support a hypothesis based on
them.

If you ask 100 people the way to the museum while having a hypothesis
that you should go to the right and about 90 of them tell you that
they don't know what you're talking about, would you think that the
answer you got from those 90 people supports your hypothesis? Or would
you rather ignore their answers?

Re: multipart/alternative question

[lee]

At Sun, 19 Jul 2009 14:54:15 -0500,
Kyle Wheeler wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On Saturday, July 18 at 02:41 PM, quoth lee:
  Hmm, well, I guess I see your point, but not even mutt supports 
  batch-decoding like that. Do you perhaps have a perl script of some 
  kind that you use to bulk-decode like that?
 
  Perhaps we should make a feature request?
 
 Well, I was thinking that it might be possible using tags and piping 
 with a slick perl script, that you could glue together with a macro..

Yeah, IIRC, there are perl libraries to handle mime things. Or you
could always make some bash script that uses one of the softwares that
can handle mime, like metamail, to send a whole folder out as a
message. Another script could handle unpacking the message.

  Speaking of which, I sometimes wished that I could just attach a 
  whole folder instead of having to attach all the files separately.
 
 You *can* do the tag-and-attach approach. Saves time over attaching 
 each file independently.

I know, but I just happend to try to attach the whole folder
somethimes without thinking and then found that I can't ...

  So where's the full MUA support of the mime stuff?
 
 Good question.
 
 For what it's worth, another way to segment large files (or 
 collections of files) is to use the shell utility `split`
 
 Not exactly *convenient*, though... but unless your recipient is using 
 Outlook Express, there's not much point in using a MIME trick that 
 they can't take advantage of.

Hm. I wonder what mutt --- or wanderlust, which I'm trying out now ---
would do with messages containing parts of files. You might be able to
save something from each message but then be left with the problem of
having to figure out how to put the pieces together.

 English has its trade-offs, like most things. While it is a bit sloppy 
 and leaves a lot up to interpretation, that leads to lots of fun 
 double- or triple-entendres (which has benefits in the realms of 
 poetry, humor, and other forms of literature), and lets us use nouns 
 as verbs, among other things. By not requiring the speaker to make 
 distinctions about everything, it leaves a lot more room for 
 interpretation, which is both liberating and frustrating for the exact 
 same reason.

That's probably true for other languages as well, in one way or
another, to a greater or lesser extent. I wonder if there's a German
translation of that RFCs --- it's probably extremely difficult to
translate if the interpreter was to transcribe what it's supposed to
mean to the full extent ... I've always been reading things like that
in English, even when there was a translated version available. It's a
lot easier because the translations ignore that the original
originates from a totally different mindset, which makes them hard to
understand and sometimes even incomprehensible.

For example, there is no German word for segmentation fault. It is
not translatable not only because there isn't a word for it, there's
also no concept for it. Interpreters confronted with the problem of
translating it made something up, but it is nonsense. It's like trying
to explain to a blind person what colors look like.

When you watch German TV, you start asking yourself where you are
because like half the words are English. They do that to make what
they are saying to appear important, and the less they know what they
are trying to say, the more English words they (ab-)use. It's really
awful --- but nobody would ever say segmentation fault.

Re: multipart/alternative question

[Noah Slater]

On Fri, Jul 17, 2009 at 10:21:29AM -0600, lee wrote:
 On Fri, Jul 17, 2009 at 02:36:41PM +0100, Noah Slater wrote:
  I guess in some general sense you are correct, but within the
  context of a MUA, an attachment has a very specific and well defined
  meaning, that is much more narrow than this.

 Well, I'm not trying to mislead someone. Where is defined what an
 attachment is for the context of a MUA, and who made the definition?

To the best of my knowledge, it isn't defined anywhere. But that doesn't matter.
The common understanding of an attachment is that it is a file, with a filename,
that has been sent as a separate item from the message.

  An attachment is a message entity that a user is likely to add or
  save to and from the file system, as separate to the main message.

 In Kyles example, that would be saving the html attachment to view it
 in a web browser. The user might do that himself, the MUA might do it
 automatically. If you use a MUA that cannot display text/plain, you
 might save the text/plain to display it ...

This is NOT a typical use case.

 And who is to decide how likely a particular user is to save a
 particular attachment, for the purpose of the MUA counting the
 attachments?

The authors of the MUA.

 To me, it has clearly three attachments. It doesn't matter if a user
 is likely to save an attachment or not.

And you should be free to configure your MUA to display those as attachments,
but the way you think about message parts is uncommon, and would be confusing
for the average user.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 06:28:35PM -0500, Kyle Wheeler wrote:
 On Friday, July 17 at 03:58 PM, quoth lee:
  Hm, somehow I've never had that problem. When reading the message, I 
  find out if something is attached.
 
 You're lucky!

Yay! ;)

 But every now and then, I still manage to miss an attached file
 (either because I didn't look, or because it was surprisingly
 small).

That's because mutt doesn't count the attachments right and doesn't
make it very obvious that they are there. Not making it obvious has
advantages in that you don't need to worry about them when viewing a
message. But in your case, it's not so good because it leads you to
miss attachments ... If I got such mails, I might miss them as well.

  Well, you could have a message with a container. The container could 
  contain a number of files,
 
 Hmm, well, I guess I see your point, but not even mutt supports 
 batch-decoding like that. Do you perhaps have a perl script of some 
 kind that you use to bulk-decode like that?

Unfortunately not; but I haven't needed one yet. Saving whole
containers is merely a possibility that comes to mind when considering
attachments as containers that contain something. That's something I
didn't do before. Once you do, it's evident that a MUA could have a
way to save a whole container like that.

Perhaps we should make a feature request? I'm not sure how useful that
would be, but I can imagine that there are ways of explicitly using
it. In case you want to send someone several files, you (or the MUA)
could make a container to contain them. The recipient could save the
whole container instead of having to save all the files separately. If
you want to go a step further, you could invent a way of specifying
something that should be done after saving the files, similar to
Debian packages specifying what to do to configure the software that
is in the package ... Like someone could attach a folder with files in
it, the MUA would attach them as/in a container, and the sender would
specify that make should be run after saving the files and then
program that's compiled because he's sending you the new version of
the program. That's a dangerous feature, so the MUA would have to ask
to user before doing something ...

Speaking of which, I sometimes wished that I could just attach a whole
folder instead of having to attach all the files separately. Moott,
that was when I wanted to send several pictures to someone. I would
resize them and convert them to JPEG and collect them in a folder, and
when I had all the pictures gathered, I naturally wanted to tell
mutt to send the folder --- but that doesn't work. Since pictures can
be large, the user should be able to specify a size limit after
attaching a folder (or large files) to a message, and the MUA should
automatically split the thing up as needed.

These mime guys did only part of the job --- or maybe it's the MUA
developers. I used to split up files when the message size limit was
64k and had scripts for sending them and splitting them up
automatically. The limits aren't that tight anymore, but the files are
also larger. Try sending someone 5 or 10 TIFFs as they come out of
your camera --- you may find that you can't even send one because he's
got a mailbox limit of 5MB or a size limit of 20MB and one TIFF is
about 18MB ...

So where's the full MUA support of the mime stuff?

  At some time, all this mime crap (that's how I still think of it) 
  was invented.
 
 HEH - way to make me feel old.

Well, how should I feel? ;)

 The first MIME RFC was written in 1993, back when I was barely a
 teenager and was just about to discover the wonders of
 HyperCard. (My First Internet (tm) was AOL.)

You started early then. In 1993, only a few people had even heard
about internet --- it was something very expensive that only a few
institutions like universities could/would afford. At that time, I had
news and mail, but no internet ...

 But I see what you mean about your definition of an attachment... 
 though by that logic, a message is essentially defined by its 
 headers (From/To/Subject/etc.) rather than its content.

*The headers are content.* The headers are the substantial part of the
message.

What content the headers or other parts of a message have doesn't
define what a message is. The definition is formal and doesn't concern
the contents.

You can send something via SMTP that doesn't have headers and a body
because the MTA doesn't care about the content. That's why the SMTP
protocol knows such things as envelope sender and envelope
recipient. What you put into the headers as From: and To: can be
different from what's in the envelope. For example:


l...@cat:~/Mail$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 cat.rubenette.is-a-geek.com ESMTP Exim 4.69 Sat, 18 Jul 2009 12:37:07 -0600
helo cat.rubenette.is-a-geek.com
250 cat.rubenette.is-a-geek.com Hello localhost [127.0.0.1]
MAIL FROM: l...@yun.yagibdah.de
250 OK

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 09:20:49PM +0100, Noah Slater wrote:
 On Fri, Jul 17, 2009 at 10:21:29AM -0600, lee wrote:
  Well, I'm not trying to mislead someone. Where is defined what an
  attachment is for the context of a MUA, and who made the definition?
 
 To the best of my knowledge, it isn't defined anywhere. But that doesn't 
 matter.
 The common understanding of an attachment is that it is a file, with a 
 filename,
 that has been sent as a separate item from the message.

Well, then most people have a wrong understanding.

  In Kyles example, that would be saving the html attachment to view it
  in a web browser. The user might do that himself, the MUA might do it
  automatically. If you use a MUA that cannot display text/plain, you
  might save the text/plain to display it ...
 
 This is NOT a typical use case.

Why not? Mutt does it, sup does it. When I have a mail with an html
part and want to view that, I can press ENTER on it and mutt and sup
will start galeon (Yuck! I need to change that.) to display it. I
haven't verified, but I'm pretty sure that the MUA saves the html part
as a file so that a web browser can load the file to display it.

The MUAs probably do the same with other parts of a mail, unless they
can display the part themselves. Since they can display plain text,
they're not saving it, but if they couldn't display plain text,
wouldn't they handle it the same way they handle parts they can't
display themselves?

  And who is to decide how likely a particular user is to save a
  particular attachment, for the purpose of the MUA counting the
  attachments?
 
 The authors of the MUA.

The RFC leaves it up to the user how he wants to display a (part of a)
message. And since each user has preferences, it's not up to the
authors of the MUA to force the user to display a message in a
particular way or to decide what the user would consider as an
attachment.

  To me, it has clearly three attachments. It doesn't matter if a user
  is likely to save an attachment or not.
 
 And you should be free to configure your MUA to display those as attachments,
 but the way you think about message parts is uncommon, and would be confusing
 for the average user.

Yeah, I configured mutt to count all attachments, but mutt doesn't do
that. It doesn't go into some containers.

Don't get me wrong: Reasonable defaults are fine and should be there,
and since its up to each user, it doesn't matter what you or I or most
users consider as an attachment. As you say, each user should be free
to configure his MUA the way he wants.

Re: multipart/alternative question

[Noah Slater]

On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
  To the best of my knowledge, it isn't defined anywhere. But that doesn't 
  matter.
  The common understanding of an attachment is that it is a file, with a 
  filename,
  that has been sent as a separate item from the message.

 Well, then most people have a wrong understanding.

This is an absurdly prescriptivist statement.

   In Kyles example, that would be saving the html attachment to view it
   in a web browser. The user might do that himself, the MUA might do it
   automatically. If you use a MUA that cannot display text/plain, you
   might save the text/plain to display it ...
 
  This is NOT a typical use case.

 Why not? Mutt does it, sup does it.

Sure, many MUAs will let you do it, but it's not a typical use case.

As in, if you did a survey of all the people on the planet, and asked them if
they had ever saved the HTML component of a simple email message, I am willing
to bet the number would be under 1%.

  The authors of the MUA.

 The RFC leaves it up to the user how he wants to display a (part of a)
 message. And since each user has preferences, it's not up to the
 authors of the MUA to force the user to display a message in a
 particular way or to decide what the user would consider as an
 attachment.

I never said force. I'm only talking about sane defaults.

  And you should be free to configure your MUA to display those as 
  attachments,
  but the way you think about message parts is uncommon, and would be 
  confusing
  for the average user.

 Yeah, I configured mutt to count all attachments, but mutt doesn't do
 that. It doesn't go into some containers.

 Don't get me wrong: Reasonable defaults are fine and should be there,
 and since its up to each user, it doesn't matter what you or I or most
 users consider as an attachment. As you say, each user should be free
 to configure his MUA the way he wants.

Agreed.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
 On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
   To the best of my knowledge, it isn't defined anywhere. But that doesn't 
   matter.
   The common understanding of an attachment is that it is a file, with a 
   filename,
   that has been sent as a separate item from the message.
 
  Well, then most people have a wrong understanding.
 
 This is an absurdly prescriptivist statement.

I'm not sure what prescriptivist means. See Message-ID: 
20090718204148.ga8...@cat.rubenette.is-a-geek.com,
there's an explanation why I could maintain saying that.

 As in, if you did a survey of all the people on the planet, and
 asked them if they had ever saved the HTML component of a simple
 email message, I am willing to bet the number would be under 1%.

A simple email message doesn't have any HTML components.

You probably wouldn't get any valid results from such a survey because
the percentage of people who wouldn't know what you're talking about
would be too high.

Re: multipart/alternative question

[Noah Slater]

On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
 On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
  On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
To the best of my knowledge, it isn't defined anywhere. But that 
doesn't matter.
The common understanding of an attachment is that it is a file, with a 
filename,
that has been sent as a separate item from the message.
  
   Well, then most people have a wrong understanding.
 
  This is an absurdly prescriptivist statement.

 I'm not sure what prescriptivist means.

Compare the following topics:

  http://en.wikipedia.org/wiki/Descriptive_linguistics

  http://en.wikipedia.org/wiki/Linguistic_prescription

In other words, if most people think attachment means X then, by
definition, attachment means X - regardless of your personal preference for
what it should mean. This is how language works.

  As in, if you did a survey of all the people on the planet, and
  asked them if they had ever saved the HTML component of a simple
  email message, I am willing to bet the number would be under 1%.

 A simple email message doesn't have any HTML components.

That depends on what you mean by simple - and you have already demonstrated
that your definitions are unusual. That is not meant to be offensive, because I
can see where you're coming from. Nevertheless.

 You probably wouldn't get any valid results from such a survey because
 the percentage of people who wouldn't know what you're talking about
 would be too high.

I think that would probably support my thesis. Heh.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
 I'm not sure what prescriptivist means. See Message-ID: 
 20090718204148.ga8...@cat.rubenette.is-a-geek.com,
 there's an explanation why I could maintain saying that.

Sorry, you might have that. Here's the References: header
(which you probably have):

References: 20090716055919.ga6...@cat.rubenette.is-a-geek.com 
20090716141914.gc4...@atakapa.local
20090717021854.ga7...@cat.rubenette.is-a-geek.com 
20090717030916.gn4...@atakapa.local
20090717042711.gf7...@cat.rubenette.is-a-geek.com 
20090717053919.gp4...@atakapa.local
20090717173748.gd14...@cat.rubenette.is-a-geek.com 
20090717183804.gt4...@atakapa.local
20090717215821.gf1...@cat.rubenette.is-a-geek.com 
20090717232835.gw4...@atakapa.local

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 12:48:45AM -0500, Kyle Wheeler wrote:
 On Thursday, July 16 at 10:51 PM, quoth lee:
 On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:
 
  But anyway, I don't consider this message to have ANY attachments.
  The person didn't send me any extra files to look at. They sent me the
  same message twice, one with extra formatting and one without. I don't
  think most people would consider that to be a message with
  attachments, so I don't think mutt should say that there is an
  attachment.
 
 Well, I would consider such a message as attachment only: No message
 (i. e. no body), only three attachments.
 
 Logically, an attachment needs something to be attached TO.

Ok, maybe I should have that expressed less ambiguous. What you get is
a message (RFC822) that doesn't have a body (or has an empty body). To
this message, something is attached.

 The MIME equivalent of what I just described is this:
 
  I   1 no description  [multipart/mixed]
  I   2 |-no description   [text/plain]
  A   3 `-no description   [image/jpeg]
 
 Entity #3 is the attachment. It is attached to Entity #2. Entity #1 is 
 the staple: it exists only for the purpose of attaching #3 to #2.

Yeah, I see what you mean.

But you've skipped a step: the message. If you consider the
implementation, starting with RFC822 (and considering RFC821), you
have a message. The message doesn't have a body. Your entity #1 is
attached to the message.

That entities #2 and #3 are contained in entity #1 doesn't change the
fact that they are, though indirectly, attached to the message. That
entity #3 could be considered as attached to entity #2 doesn't change
the fact that they are (indirectly) attached to the message, either.

The fact that all entities are attached to the message makes all of
them attachments to the message, regardless of their purpose,
regardless of how they might be attached to each other and regardless
of how they are attached to the message.

Thus you cannot deny that you have a message (without a body and) with
three attachments. *You cannot send attachments without a message.*

 I understand, having read enough philosophy, that you can argue ad 
 infinitum about the truth that the letter is just as much the 
 attachment to the photograph as the photograph is an attachment to the 
 letter, but that's a really pointless argument.

ok :)

Then we don't need to argue whether a message is still a message or
not when it doesn't have a body. RFC822 gives us the basic definition
of what a message is. That still seems to be in use. Other RFCs define
attachments --- I'll admit that I didn't read those because I didn't
need to yet and because there are so many and because it's hard to
tell which ones are current and which ones are superseded by others
...

Re: multipart/alternative question

[Rejo Zenger]

++ 16/07/09 09:03 -0500 - Kyle Wheeler:
 Since mutt is set to prefer text/plain, all I see is the plain text 
 message, with no indication that there is an attachment (or even an 
 html part).

First, of course there's no obvious indication that there's an html 
part. Why should there be? Unless you press v to view the MIME 
hierarchy of the message, mutt doesn't tell you about alternative 
components to your email.
[...]

The same issue has been discussed before on this list: [1]. Kyle did a 
good job of explaining at [2].


[1] http://www.mail-archive.com/mutt-users@mutt.org/msg37364.html
[2] http://www.mail-archive.com/mutt-users@mutt.org/msg37430.html



-- 
Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl
GPG encrypted e-mail prefered. 


signature.asc
Description: Digital signature

Re: multipart/alternative question

[Noah Slater]

Hey,

On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:
  I   1 no description[multipart/alternative]
  I   2 |-no description [text/plain]
  I   3 `-no description [text/html]
[...]
 But anyway, I don't consider this message to have ANY attachments.

On Thu, Jul 16, 2009 at 10:51:44PM -0600, lee wrote:
 Well, I would consider such a message as attachment only: No message
 (i. e. no body), only three attachments.
[...]
 The fact that all entities are attached to the message makes all of
 them attachments to the message, regardless of their purpose,
 regardless of how they might be attached to each other and regardless
 of how they are attached to the message.

Lee, directly or indirectly, you're just playing language games.

You're using the word attach to misleadingly describe the process by which a
message has message entities added to it. While this is certainly a valid use of
the word attach, you're then extrapolating that all entities must therefor be
attachments. I guess in some general sense you are correct, but within the
context of a MUA, an attachment has a very specific and well defined meaning,
that is much more narrow than this.

An attachment is a message entity that a user is likely to add or save to and
from the file system, as separate to the main message. A good litmus test,
although by no means perfect, would be if the entity has an explicit file name.
In the example that Kyle gave, there are clearly no attachments, and I would not
want to use a MUA that listed any.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 02:36:41PM +0100, Noah Slater wrote:
 I guess in some general sense you are correct, but within the
 context of a MUA, an attachment has a very specific and well defined
 meaning, that is much more narrow than this.

Well, I'm not trying to mislead someone. Where is defined what an
attachment is for the context of a MUA, and who made the definition?

 An attachment is a message entity that a user is likely to add or
 save to and from the file system, as separate to the main message.

In Kyles example, that would be saving the html attachment to view it
in a web browser. The user might do that himself, the MUA might do it
automatically. If you use a MUA that cannot display text/plain, you
might save the text/plain to display it ...

And who is to decide how likely a particular user is to save a
particular attachment, for the purpose of the MUA counting the
attachments? The MUA would have a hard time to figure that out.

 A good litmus test, although by no means perfect, would be if the
 entity has an explicit file name.  In the example that Kyle gave,
 there are clearly no attachments, and I would not want to use a MUA
 that listed any.

To me, it has clearly three attachments. It doesn't matter if a user
is likely to save an attachment or not.

BTW, what's a message entity? Attachments are not message entities
if you look at RFC822.

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 12:39:19AM -0500, Kyle Wheeler wrote:

 No, I mean that MIME components (aka entities) have meanings that 
 affect the interpretation of other MIME entities.

ok

 I could appeal to something like Wikipedia (which says an email 
 attachment is a computer file which is sent along with an email 
 message), but I'm guessing you don't care much for so-called 
 official definitions.

It depends ... I distinguish between definitions and descriptions, and
since there are often many different descriptions of something
(calling themselves definitions), I don't care much for so-called
official definitions. Then look at different languages and the
descriptions of the same thing, and even if the description of
something may be very similar to one in another language, people who
have different native languages can (and usually will) have a
different understanding/perception/relationship/opinion of the same
thing. That is something very difficult to include into a description,
and it's usually not done.

As to RFCs, the ones I know are more definitions than descriptions,
and I consider RFCs as relevant. They are what is in use; implementing
something is either compliant with RFCs or may not work. Without RFCs,
one MTA couldn't understand another one, and one MUA couldn't display
messages created with another one.

  Mutt says that there are 0 attachments. I say there's at least 1.
 
 We clearly have different definitions of the term.

Yes --- but that's ok.

 I find my definition more useful, because then I can use it to tell
 me whether there's some component of the message that I can and will
 want to save to disk.

That's fine --- it is what is useful for you. You could rename what is
called attachment counter to file counter or something, or you
could say that you would like to have a counter telling you how many
attachments there are that you might want to save.

Mutt already supports this in that you can specify what things should
qualify as attachments and be counted. The problem is that the
counting doesn't work right.

 What's the utility of your definition?

You mean what the usefulness is of my considering everything that is
attached to a message as an attachment? It gives me an impression
about how messed up a message might be. If it's a message that might
be a SPAM mail, it will prevent me from opening it.

What is the usefulness of knowing if something is attached to a
message that you might want to save to a separate file? It's useful to
you, but not really useful to me.

 Why do *you* care how many containers are on the ship?

See above --- you care about what's in the containers, I care about
how many containers there are.

How do you want to unload, i. e. would you prefer to unload all the
bricks at once by unloading the container (save the whole container to
disk with everything in it), or would you rather open the container
and unload (save to disk) one brick (file) at a time?

  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.
 
  So you would say that all of them are attachments and therefore should 
  count as such, no matter how they are supposed to be displayed.
 
 Am I really that hard to understand, or are you just trying to get 
 under my skin?

Well, what were you saying?

 For the umpteenth time, no, not all MIME entities are attachments.

To me, they are.

  RFC822:
 
 RFC 2045:
 
  This set of documents, collectively called the Multipurpose
  Internet Mail Extensions, or MIME, redefines the format of
  messages to allow for
 
  (1) textual message bodies in character sets other than US-ASCII,
  (2) an extensible set of different formats for non-textual message
  bodies,
  (3) multi-part message bodies, and
  (4) textual header information in character sets other than
  US-ASCII.
 
 Thus, in the context of MIME, the RFC 822 definition of a message 
 format is no longer supreme. It has been, in the words of the MIME 
 RFC, redefined.

Ok, so which is the current RFC for this? 2045, or is there even
another one modifying or superseding 2045?

2045 says:



   The term message, when not further qualified, means either a
   (complete or top-level) RFC 822 message being transferred on a
   network, or a message encapsulated in a body of type message/rfc822
   or message/partial.



That's a rather unlucky definition because it uses the term it defines
in the definition. I don't understand what message means when they
say a message encapsulated in a body. Do they mean an RFC822
message? Do they mean body in the sense of RFC822?

  You shouldn't ask me that because if I wanted to send someone a 
  message and a JPEG, I would send a plain text 

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 11:37:50AM -0500, David Champion wrote:
 * On 17 Jul 2009, lee wrote: 
  
  Well, I'm not trying to mislead someone. Where is defined what an
  attachment is for the context of a MUA, and who made the definition?
 
 Content-Disposition's role is described in RFC 2183.  But attachment
 is a very ambiguous term.

They have a good way of putting it in RFC 2183:



   Two common ways of presenting multipart electronic messages are as a
   main document with a list of separate attachments, and as a single
   document with the various parts expanded (displayed) inline. The
   display of an attachment is generally construed to require positive
   action on the part of the recipient, while inline message components
   are displayed automatically when the message is viewed. A mechanism
   is needed to allow the sender to transmit this sort of presentational
   information to the recipient; the Content-Disposition header provides
   this mechanism, allowing each component of a message to be tagged
   with an indication of its desired presentation semantics.



There is a distinction between attachments and other message
components. You could say everything not designated to be displayed
automatically in line is considered as an attachment.

 It's less about what the user wants to do, and more about the
 component's relationship to the message that the sender composed.  But
 this is still rather subjective.

There could be a counter counting message components. The RFC 2183 is
supposed to define a means *for the sender* to specify how he wants
parts of the message to be displayed. How the recipient deals with the
message is up to him.

Is there an RFC that defines how a MUA is supposed to deal with such
multipart messages? RFC 2183 seems to (reasonably) say only a minimum
about what MUAs should do.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 11:37 AM, quoth lee:
 Mutt already supports this in that you can specify what things 
 should qualify as attachments and be counted. The problem is that 
 the counting doesn't work right.

Agreed!

 What's the utility of your definition?

 You mean what the usefulness is of my considering everything that is 
 attached to a message as an attachment? It gives me an impression 
 about how messed up a message might be. If it's a message that might 
 be a SPAM mail, it will prevent me from opening it.

Hm. See, I find that I really don't care how messed up a message 
might be. For example, I often get emails from corporate secretaries 
that use Outlook and some goofy HTML stationery (complete with 
background picture, goofy fonts, corporate logo, etc.). Knowing that 
it's a complex MIME structure isn't a useful piece of information to 
me.

But to each his own, I suppose.

 What is the usefulness of knowing if something is attached to a 
 message that you might want to save to a separate file? It's useful to 
 you, but not really useful to me.

Well, the usefulness to me is that occasionally I receive messages 
that don't make it clear that there IS an attachment in the text. For 
example, I'll get an email that reads Can you make sure that the 
schedules are right for next month?. It also has a copy of the 
schedules attached (probably that's messed up and isn't what had 
previously been established as the schedules), but that's an easy fact 
to miss in a text-based email reader (GUI email programs, and webmail, 
often make such things a bit more obvious).

 Why do *you* care how many containers are on the ship?

 See above --- you care about what's in the containers, I care about 
 how many containers there are.

 How do you want to unload, i. e. would you prefer to unload all the 
 bricks at once by unloading the container (save the whole container to 
 disk with everything in it), or would you rather open the container 
 and unload (save to disk) one brick (file) at a time?

See, here's where I think the metaphor becomes a bit strained. I don't 
know how what you're talking about maps back to email.

 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.

 So you would say that all of them are attachments and therefore should 
 count as such, no matter how they are supposed to be displayed.

 Am I really that hard to understand, or are you just trying to get 
 under my skin?

 Well, what were you saying?

According to the Content-Disposition RFC (2183), which is what defines 
the idea of an inline MIME entity versus an attached MIME entity, 
the difference is in presentation (aka display) to the recipient. 
Here's how they describe it:

 Two common ways of presenting multipart electronic messages are as
 a main document with a list of separate attachments, and as a
 single document with the various parts expanded (displayed)
 inline. The display of an attachment is generally construed to
 require positive action on the part of the recipient, while inline
 message components are displayed automatically when the message is
 viewed.

That, I think, pretty much restates what I was saying.

In particular, mutt observes and respects the two disposition types 
outlined in that RFC:

 2.1  The Inline Disposition Type

 A bodypart should be marked `inline' if it is intended to be
 displayed automatically upon display of the message.  Inline
 bodyparts should be presented in the order in which they
 occur, subject to the normal semantics of multipart messages.

 2.2  The Attachment Disposition Type

 Bodyparts can be designated `attachment' to indicate that they
 are separate from the main body of the mail message, and that
 their display should not be automatic, but contingent upon
 some further action of the user.  The MUA might instead
 present the user of a bitmap terminal with an iconic
 representation of the attachments, or, on character terminals,
 with a list of attachments from which the user could select
 for viewing or storage.

 For the umpteenth time, no, not all MIME entities are attachments.

 To me, they are.

Well, then I think it's safe to say that you have a rather unusual 
view of MIME entities that is not shared by (at least some of) the 
designers of the MIME standard.

 Ok, so which is the current RFC for this? 2045, or is there even 
 another one modifying or superseding 2045?

There isn't an RFC that obsoletes 2045. It is updated by 2184 (MIME 
Parameter values  character sets), 2231 (obsolets 2184), and 5335 

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 12:18 PM, quoth lee:
 Is there an RFC that defines how a MUA is supposed to deal with such 
 multipart messages? RFC 2183 seems to (reasonably) say only a 
 minimum about what MUAs should do.

Not that I know of... The closest I can find is RFC 1521, which says:

 It may be the case that some user agents, if they can recognize
 more than one of the formats, will prefer to offer the user the
 choice of which format to view. This makes sense, for example, if
 mail includes both a nicely-formatted image version and an
 easily-edited text version. What is most critical, however, is
 that the user not automatically be shown multiple versions of the
 same data. Either the user should be shown the last recognized
 version or should be given the choice.

Granted, this is talking about presentation of the CONTENTS of the 
multipart/alternative sub-entities, but I think it applies to 
summaries of that content as well (i.e. attachment counts). In other 
words, I think the suggestion here is to count attachments from only 
ONE of the alternatives, not from all of the alternatives, because to 
count attachments in ALL of the alternatives is equivalent to being 
show multiple versions of the same data.

Of course, this is complicated by the preceeding paragraph:

 In the case where one of the alternatives is itself of type
 multipart and contains unrecognized sub-parts, the user agent
 may choose either to show that alternative, an earlier
 alternative, or both.

It doesn't say what to do if multiple alternatives are of type 
multipart, and showing both seems to directly contradict what is 
most critical a mere few sentences later.

~Kyle
- -- 
Preach the Gospel at all times and when necessary use words.
   -- St. Francis of Assisi
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYMlsAAoJECuveozR/AWebUsP/1KhmB/AjnTqQSFJPF/th+Qf
X4+kbao9m2xMNSE2pcpT/3eZwyk886gCXsgWfxtA2I78/9In32UTeg2YkNROIAHX
BT26rSd3rZMqTAL/5yKyWs5jAcz4NlRES0nCd6UIpS5vk9lNqEFWjhMz/n58UsUo
xtiR7PjCEc5fVwTRH5ukN7GKoTdc5rzzmsn8wuehIdTPTbvJOA/9oWaGP8mhXpow
X0ak3i4JKBQEfpn1J6lJJFe0FE4Rguex60EdqinWWMqgRL4nmU/I4uNf+sd4KRQt
G+6z84bkm1EqQFms6+7DYuP9NTaYMQw1NLfdb5fdbrSFYmi6G9YRgJvy5g86tWKZ
dG3/SGyKdzwbvdyIBGo+UJdTqkgI72JtUrBWjjr0ULmKWZg6kmd4nGh/d8p0CzSH
A6u9iW9XsVjokXTBTHD1ggswJJrllfLXqaiRK45sHjHRBHJUA5bWayGCdeFywfKz
l0KrbtuCTlBxg6VMErRKTd4rVYIYlDhaKX0ooC+rrwbbWxRjo7U9BIkyUU11a8tx
KDotd4SKy2gw75pkc10+nWPaVwAVDnqZAclUz4Oe6V1BK+X9Pn4Sv2srMgw8MEin
6P0s389ZFRNKRMlU2PkvE2Op9zv8r7Odjx4GgUKXXG0+HGHv1goVeNKNWCB/LXyA
t1v7bcaptJpkJKCQPqSU
=U5rt
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 01:56 PM, quoth Kyle Wheeler:
On Friday, July 17 at 12:18 PM, quoth lee:
 Is there an RFC that defines how a MUA is supposed to deal with such 
 multipart messages? RFC 2183 seems to (reasonably) say only a 
 minimum about what MUAs should do.

Not that I know of... The closest I can find is RFC 1521, which says:

Actually, RFC 2046 is more recent, but says nearly the exact same 
thing. It adds:

 Systems should recognize that the content of the various parts [of
 multipart/alternative sections] are interchangeable.  Systems
 should choose the best type based on the local environment and
 references, in some cases even through user interaction.

By Systems, I'm pretty sure they mean recipient systems.

~Kyle
- -- 
The most important thing a father can do for his children is to love 
their mother.
   -- Fr. Theodore Hesburgh
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYMsvAAoJECuveozR/AWeCUEP/2ZK1QYpmvo9QjHS52C+IRMG
LpH+SrgiKtwx4tqFIqkpcCEzKvpuiUQpwGMBNGBkkX9FmcRyXesbGOUD1Lkey0uP
wbf0e5mkCCQA7YAeeTDCa/knpqAQjvck/1jdwiggsgCFh3AGeNS0aGcTRbY1G6SE
ONapoo5Pa7ZA6prnBYtrcLVABCiplfx69vAM2VID90T2LRpL7+IZOlakzJCqlEf+
Xt6fWRHq1g07wV9ezJnJi8kc7pnN1pbVQyIdnvSBeuo2jnNaT1+gzjK3epREnvgr
NcPG92awoG3ljiEQ3ICNeto4Cs3aqWYYZrzJ1XhJrF3gKWFMVXZHSyPV6kc5gJtF
JBsTiwEa1qtiSufq72B8qU7GutzJSUbcupzfOjWAxSJBu18KkLksPRfk2g2GRO0q
twhDrCgN3CSKtowZXt66HaQN5kvqM1BEH28qqsnS08RjN+aUFWIrpLNscHyKwFN2
gTDDbfVBovHUQs8oAleYBUubTVGKuL2RuXDiR21bjFxoN+CT9+fRQn8ZhTNnXvdj
xyNAm3bDxfEBa6SN1KSgRz8NcKPoIqmVh4IlyYSR0BdJo4DfqvyDUQo7vbg3cvDS
9obqBz4UIG51FZzI5uikkp+tg9ur3+BCzV1xZfHhOivsr9DH2kbXJFCJ08DbEd0V
r9U8Z5bX6cn4gwUGDyIQ
=xkNv
-END PGP SIGNATURE-

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 01:56:45PM -0500, Kyle Wheeler wrote:

 In other words, I think the suggestion here is to count attachments
 from only ONE of the alternatives, not from all of the alternatives,
 because to count attachments in ALL of the alternatives is
 equivalent to being show multiple versions of the same data.

Hm, I don't think that there is a suggestion about counting
attachments. But anyway, you could as well argue that all those
versions should be counted which could be displayed. However, all this
won't have to do much with counting attachments.

Maybe attachment isn't something that should be counted at all
because there can be so much disagreement about what an attachment
is and under what circumstances it should be counted or not.

 Of course, this is complicated by the preceeding paragraph:
 
  In the case where one of the alternatives is itself of type
  multipart and contains unrecognized sub-parts, the user agent
  may choose either to show that alternative, an earlier
  alternative, or both.
 
 It doesn't say what to do if multiple alternatives are of type 
 multipart, and showing both seems to directly contradict what is 
 most critical a mere few sentences later.

When sub-parts are unrecognizable, it makes sense to allow showing
several alternatives because the MUA may not be able to determine
which of the alternatives it should show since it contains parts the
MUA cannot recognize.

And how does a MUA show unrecognizable parts of a message?

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 02:04:15PM -0500, Kyle Wheeler wrote:
 Actually, RFC 2046 is more recent, but says nearly the exact same 
 thing. It adds:
 
  Systems should recognize that the content of the various parts [of
  multipart/alternative sections] are interchangeable.  Systems
  should choose the best type based on the local environment and
  references, in some cases even through user interaction.
 
 By Systems, I'm pretty sure they mean recipient systems.

That's pretty interesting: The MUA *should* choose the best type
based on the local environment and references, in some cases even
through user interaction.

I find that so interesting because it basically means that the MUA
should display a type (a message, or part of a message) in just the
way the user would want it. Insofar the user is the recipient, the RFC
says To hell with how the sender wanted something to be displayed!
Always display it as the recipient wants it to be displayed!

If you transcribe this to the counting of attachments, it means that
the MUA should count attachments the way the user wants them to be
counted.

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 01:38:04PM -0500, Kyle Wheeler wrote:

 For example, I often get emails from corporate secretaries that use
 Outlook and some goofy HTML stationery (complete with background
 picture, goofy fonts, corporate logo, etc.). Knowing that it's a
 complex MIME structure isn't a useful piece of information to me.

Yeah, you want to know what the message says and if something is
attached that you might want to do something with. For that, you don't
want/need to care about how a message is made up.

 But to each his own, I suppose.

yeah

  What is the usefulness of knowing if something is attached to a 
  message that you might want to save to a separate file? It's useful to 
  you, but not really useful to me.
 
 Well, the usefulness to me is that occasionally I receive messages 
 that don't make it clear that there IS an attachment in the text. For 
 example, I'll get an email that reads Can you make sure that the 
 schedules are right for next month?. It also has a copy of the 
 schedules attached (probably that's messed up and isn't what had 
 previously been established as the schedules), but that's an easy fact 
 to miss in a text-based email reader (GUI email programs, and webmail, 
 often make such things a bit more obvious).

Hm, somehow I've never had that problem. When reading the message, I
find out if something is attached.

But yes, you're right that for such cases it would be nice if it was
more obvious that there is an attachment. Perhaps you can somehow
change the color of the status line to white on red or change the
color of the message display to white on blue in case a message has a
part that is not designated as inline but as attachment.

For this, mutt would first have to be able to count attachments
exactly the way the user wants them to be counted.

  How do you want to unload, i. e. would you prefer to unload all the 
  bricks at once by unloading the container (save the whole container to 
  disk with everything in it), or would you rather open the container 
  and unload (save to disk) one brick (file) at a time?
 
 See, here's where I think the metaphor becomes a bit strained. I don't 
 know how what you're talking about maps back to email.

Well, you could have a message with a container. The container could
contain a number of files, JPEGs for example --- maybe portraits of
your relatives. You could have a choice: Do you want to go to every
file in the list and save one after another, or would you rather go to
the container and save the whole container with all the files in it at
once (as a new directory containing all the JPEGs).


 That, I think, pretty much restates what I was saying.
 In particular, mutt observes and respects the two disposition types 
 outlined in that RFC:

Now I see what you mean. Well, you're right when you say that not
every attachment is an attachment.

  2.1  The Inline Disposition Type
  2.2  The Attachment Disposition Type
  For the umpteenth time, no, not all MIME entities are attachments.
 
  To me, they are.
 
 Well, then I think it's safe to say that you have a rather unusual 
 view of MIME entities that is not shared by (at least some of) the 
 designers of the MIME standard.

Sort of ... When I started using email, there weren't any attachments
or inlines. If you wanted to send someone something that didn't
contain only ASCII characters (and a few others) --- i. e. a file ---
you would use an uuencoder to convert the file into characters you
could send in a mail. The recipient would save the mail and eventually
have to edit it to remove header lines and use an uudecoder to convert
the message back into a file. And that was all there was; base64 came
some time later but didn't work as well for that. Since different
users would use different uuencoders and uudecoders, recipients were
not always able to decode a message, or senders were not always able
to encode a message so that the recipient could decode it.

At some time, all this mime crap (that's how I still think of it) was
invented. It's very useful for the purpose of sending files because it
makes that easier and more reliable. What they did was basically
changing the encoding from uucode to base64 and moving the file from
the body of the mail to the end of the mail, i. e. they made it an
attachment instead of putting it into the mail. You were able to do
the same with uucode if you got a good en-/decoder, and you would even
see that the uucode is in the message.

To me, sending files is pretty much the only thing the mime stuff is
good for and the only thing it should be used for, with the exception
of using it for encryption (I used that before there was mime, too,
and mime only made it easier ...). I don't want and don't need mails
written in HTML or MS Word or something. That really isn't needed, and
I don't like it. Mails are plain text. (I'm aware it's not that easy
when different languages come into play ...) In the extremely rare
case that plain text 

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 03:58 PM, quoth lee:
 Hm, somehow I've never had that problem. When reading the message, I 
 find out if something is attached.

You're lucky! These days, I usually use the size as an indicator. A 
message that's 10K or so is probably text; but 100K or more probably 
means I need to have a look at its innards (at least that's ONE 
benefit to MSOffice's giant files). But every now and then, I still 
manage to miss an attached file (either because I didn't look, or 
because it was surprisingly small).

 For this, mutt would first have to be able to count attachments 
 exactly the way the user wants them to be counted.

Quite.

 Well, you could have a message with a container. The container could 
 contain a number of files, JPEGs for example --- maybe portraits of 
 your relatives. You could have a choice: Do you want to go to every 
 file in the list and save one after another, or would you rather go 
 to the container and save the whole container with all the files in 
 it at once (as a new directory containing all the JPEGs).

Hmm, well, I guess I see your point, but not even mutt supports 
batch-decoding like that. Do you perhaps have a perl script of some 
kind that you use to bulk-decode like that?

 At some time, all this mime crap (that's how I still think of it) 
 was invented.

HEH - way to make me feel old. The first MIME RFC was written in 1993, 
back when I was barely a teenager and was just about to discover the 
wonders of HyperCard. (My First Internet (tm) was AOL.)

But I see what you mean about your definition of an attachment... 
though by that logic, a message is essentially defined by its 
headers (From/To/Subject/etc.) rather than its content.

 And isn't it outright amazing that the mime guys, in a way, 
 massively failed in clearly defining what an attachment is and what 
 not?

Yes and no. I think a lot of those sorts of oversights tend to be the 
result of assumptions, influenced by popular software abstractions. 
For example, it's easy to assume that an attachment is anything the 
user explicitly attached (by clicking the attach button) and that 
any behind-the-scenes encoding nonsense doesn't count IF (and only if) 
you typically operate at a level where that stuff is handled 
transparently such that you never see it. If, on the other hand, you 
usually read mail with `more` (or `mail` or something else that 
usually shows raw email content), and you tend to *see* the MIME 
encoding, then its easier to think of that as attached to the plain 
text message.

 As I understand it, this means that a Message is generally a 
 series of text lines similar to that defined in RFC 822 but that 
 may also be divided into one or more sub-parts that are encoded 
 according to the MIME standard (RFC 2045). As such, a message can 
 contain another message, as long as the contained message is 
 encapsulated within a MIME entity/component of the other. Thus, 
 since a MIME entity can encapsulate another message, the entity's 
 body may be a full-blown message in and of itself.

 Why don't they just say that? But what is an entity?

Ehrm... it's defined in section 2.4:

 The term entity, refers specifically to the MIME-defined header
 fields and contents of either a message or one of the parts in the
 body of a multipart entity. The specification of such entities is
 the essence of MIME. Since the contents of an entity are often
 called the body, it makes sense to speak about the body of an
 entity. Any sort of field may be present in the header of an
 entity, but only those fields whose names begin with content-
 actually have any MIME-related meaning. Note that this does NOT
 imply that they have no meaning at all -- an entity that is also a
 message has non-MIME header fields whose meanings are defined by
 RFC 822.

So... it sounds like, because it's English, words got re-used and 
redefined into confusion. As I understand it, an entity is 
essentially anything between a pair of MIME delimiters. Entities have 
a two-part format based on RFC 822 messages: a header section and a 
the rest of it section. This latter section is referred to in RFC 
822 as the body, thus dooming us to talk about the entity's header 
and an entity's body. On top of that, since beginning of data and  
end of data count as MIME delimiters, an original RFC 822 message 
can be thought of (and often is) as a MIME entity, particularly since  
they usually include MIME information in their header sections.

When a MIME entity is a container for other entities, those 
sub-entities are contained within the body of their parent. The 
parent entity's body is segmented by MIME delimiters, and the 
sub-entities are always contiguous segments of that body, and can 
therefore be logically referred to as body parts. Of course, body 
part is an unfortunate piece of what amounts to slang (perhaps jargon 
is a better term) 

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 12:31:26AM -0400, Tim Gray wrote:
 On Wed 15, Jul'09 at 10:08 PM -0600, lee wrote:
 And more general, is there a way to get an indication that a mail does
 have an attachment or attachments? I would give them a different color
 in the list; that would prevent me from opening such messages without
 checking them before.

 You could set up a coloring rule using the ~X matching pattern.  
 Something like:

 color index red default ~X 1-

 should work.

Hm, I was reading the manual, and there's an object attachment that
can be used with color. But I don't understand what that is for:


color attachment brightred black


doesn't do what I thought it might.

 You can also use the %X sequence in your index_format  
 definition to display the number of attachments in a message.  However, I 
 don't think either of those methods pick up on inline attachments.

Hm, I would expect that attachments are attachments and count as
such ...


  I 1 no description  [multipa/alternativ, 7bit, 2.0K]
  I 2 no description [text/plain, quoted, iso-8859-1, 0.7K]
  I 3 no description [text/html, quoted, iso-8859-1, 1.0K]
  I 4 no description  [text/plain, 7bit, us-ascii, 0.2K]


For that one, %X says the mail has 1 (one) attachment. But apparently
it has 4 attachments, so what's %X for?

 Other than that, if I get a mail that isn't readable, I delete it. If
 someone sends me a mail but makes it difficult to read, he obviously
 doesn't care if I read it or not, so why should I waste my time with
 it.

 Unfortunately I have collaborators whom I must work with who aren't  
 particularly email savvy.  I can't just toss their emails.

Perhaps you can help them to fix their MUAs? If you can find out if
what they are doing is compliant with RFCs or not, you could act
accordingly. Unfortunately that's a difficult task, but if they are
compliant, you need to change something on your side.

It's hard to examine the problem without having an example email
... What happens when you notice that you got such a mail and have
mutt display what attachments there are? Can you view the attachments
from there?

Re: multipart/alternative question

[Tim Gray]

On Wed 15, Jul'09 at 11:59 PM -0600, lee wrote:

Hm, I was reading the manual, and there's an object attachment that
can be used with color. But I don't understand what that is for:


That colors the attachment in message display, like this:

[-- Attachment #1 --]
[-- Type: multipart/alternative, Encoding: 7bit, Size: 3.7K --]

would show up as colored.


Hm, I would expect that attachments are attachments and count as
such ...


 I 1 no description  [multipa/alternativ, 7bit, 2.0K]
 I 2 no description [text/plain, quoted, iso-8859-1, 0.7K]
 I 3 no description [text/html, quoted, iso-8859-1, 1.0K]
 I 4 no description  [text/plain, 7bit, us-ascii, 0.2K]


For that one, %X says the mail has 1 (one) attachment. But apparently
it has 4 attachments, so what's %X for?


Well, on my setup it counts attachments that aren't inlined, i.e. A. 
However I see in the manual there is an attachments command which lets you 
configure what is counted.  I need to read up on it but it might answer some 
of my questions.



Perhaps you can help them to fix their MUAs? If you can find out if
what they are doing is compliant with RFCs or not, you could act
accordingly. Unfortunately that's a difficult task, but if they are
compliant, you need to change something on your side.


Once I figure out a bit more I'll probably send a bug report to Apple. 
It'll probably be easier to get them to change it then to get all the users 
of Apple Mail to change.



It's hard to examine the problem without having an example email
... What happens when you notice that you got such a mail and have
mutt display what attachments there are? Can you view the attachments
from there?


Yes I can do that.  It's more of an issue of not realizing there is an 
alternative view, and since the attachment is buried in that alternative,  I 
don't realize it's there.  If I hit 'v' and look, it all shows up.


Playing around last night, I see if I set add 'multipart/related 
multipart/mixed' to the front of my alternative order, it does pick up these 
messages from Apple Mail and display them.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wednesday, July 15 at 11:02 PM, quoth Tim Gray:
 I have my alternative_order set to text/plain text/html.

So do I.

 However I have some people who use a mailer (Apple Mail) that send 
 multipart/alternative messages with attachments.

How bizarre.

 Since mutt is set to prefer text/plain, all I see is the plain text 
 message, with no indication that there is an attachment (or even an 
 html part).

First, of course there's no obvious indication that there's an html 
part. Why should there be? Unless you press v to view the MIME 
hierarchy of the message, mutt doesn't tell you about alternative 
components to your email.

As for an indication that there is an attachment... what do you mean 
by indication? Do you mean some sort of inline thing like mutt does 
for more usefully structured emails? Because you CAN put %X in your 
$pager_format string to let you know how many attachments there are in 
the current email.

 I don't know if this is normal behavior for multipart/alternative 
 messages with attachments, or a quirk of Apple Mail.

It's a quirk of Apple Mail.

The thing is that Apple realized that the concept of an attachment 
is somewhat artificial, given how MIME works. So they started building 
messages as multipart/alternative where you could put attachments in 
the middle of text blocks. And when they send a TEXT message, this 
works just fine. However, from what I can tell, when someone composes 
an HTML message, Apple Mail falls down on the conversion job, and 
rather than maintain the original (for example, 
htmlpart-filepart-htmlpart) structure, it simply glues the html parts 
together, and builds a single alternative text version of the whole 
message. It's technically correct, but not especially useful.

 I would have thought that the text/plain and text/html part of the 
 messages should make up the multi/alt part, with other file 
 attachments living at the same level as the multi/alt part, not 
 buried in *one* of the alternative components

If they did that, mutt would certainly be happier, yes.

 So, what is the best way to deal with this?  Is there anyway to just 
 prefer the text/plain but look for attachments in the text/html 
 branch?  Or have an indication that there is a text/html branch 
 onscreen so I know to look there?  Or is the only route to set my 
 alternative_order to prefer text/html first...

It depends on what you're going for. I recommend an attachment counter 
in $pager_format.

~Kyle
- -- 
Whenever you have an efficient government, you have a dictatorship.
  -- Harry Truman, lecturing at Columbia University, April 28, 1959
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzMkAAoJECuveozR/AWetyYP/3Jq3FGE9iFngrKqteXBwvfD
pjoW1Qxt39Ncer26d7CPLu9R37A/HEcX1ClZqF2467EyZgYgqcjHhdcSUG5vTNPJ
IK34TgCWX35zxIP4J78MKXVldP0xjtnl/jcTZiXZ8B98T402nWFLn6Ik3q3Y9q7l
9SOGyQRE0PiWwWDjtwsnMNz1CZ3qicR/S/KcA6BXGRIbSpk7TLl5XofbH5Mkm24b
qUT3LtV1Oq7cTdBo0WCrHE8GDmsYU/s2m+4PA93AKPN7r1CTwK23xKaFcsYE/NfH
/wMsKAkgj+lfXXNZShnBCaP6ID0UQ9xF2UCxdQIBBoxqbZtQntg3o4YH+WlK6Ev1
85t7tLwoTMMxWx1r81pqKVyCNAxZGTlH5AYOnY3p0HJVFPDIAEDlwHQT6flJAJ8O
tcLODohXLuaP1Twna99DSShpc+QSJef6ZXa7V5U5sqVIC5I82Yiz/FEnVfsWBmtC
8BTqawNCpnun/Ij+dpGVmHjg2uOsaKL20fm1jXH529pplPgYxKReUW2Eb1zbm0yM
NV9xg3PgQe850/DVM6KGwuLuFXL7D3n3Fr56jUw5DMiqGeorw9HbNRJHFfPg1ZI4
0N7ABCSkjfHC8n/KM54R/zENNp59MrAKFxyr7Tbv9Ih5pnz6lr3XmXLpEbNQA93+
8CdRuN0OKg4Ugsm+BmW7
=7eHI
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wednesday, July 15 at 11:59 PM, quoth lee:
 You can also use the %X sequence in your index_format definition to 
 display the number of attachments in a message.  However, I don't 
 think either of those methods pick up on inline attachments.

 Hm, I would expect that attachments are attachments and count as 
 such ...

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). The same problem exists with pictures in GUI mailers: 
they can display the picture, or treat it as a file, or both. This is 
what RFC 2813 (the Content-Disposition header) is designed to help 
with. And when multipart/alternative is involved... it gets nutty.

  I 1 no description  [multipa/alternativ, 7bit, 2.0K]
  I 2 no description [text/plain, quoted, iso-8859-1, 0.7K]
  I 3 no description [text/html, quoted, iso-8859-1, 1.0K]
  I 4 no description  [text/plain, 7bit, us-ascii, 0.2K]


 For that one, %X says the mail has 1 (one) attachment. But apparently 
 it has 4 attachments, so what's %X for?

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.

Details of how this works and why it's hard are here: 
http://www.mutt.org/doc/devel/manual.html#attachments

 If you can find out if what they are doing is compliant with RFCs or 
 not, you could act accordingly. Unfortunately that's a difficult 
 task, but if they are compliant, you need to change something on 
 your side.

It *is* (or at least, can be) compliant.

~Kyle
- -- 
Arguing with an engineer is like wrestling with a pig in mud, after a 
while you realize the pig is enjoying it.
 -- Unknown
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzbiAAoJECuveozR/AWeaP8P/Rwy5pNNGsYF1z18i3mnV+lz
qUH0msZ+/EyG/zpSOKHZFNCADT9AXvN1nWp6uRzolYwJccsz2hTCGAk9GxlYM4uB
YZow4vHAXpJ3Opk7q1aHOk6eg3U7nPUPKCGTA2FjNYaJNVavsQ00JhfAeqxfwrDF
kBq3YSJBxXK5rLh+Eikpu9hMQUL6ZKDtd+bDgEA+oRAmWejovN57AHaQ+jDbkwBd
POiu7aVbKslfy/ftNRkTR5NiUg2RQBPoVx/YeELjezNUx25wvvppufVu65dpi20I
mF/SSNu/q0BYPb91jozi8u2m123a1xIqHMZyKtfJjfOsiLTUuCg4DyeysiyW3P8b
vrQw3ajWSEBv7+sDjFi99tMOq9+k5G+Uz2tDuDApI5qJwpiTjN4MVIXrEq8d5KbP
znb3l4Nt4E2QGSK36CXP/NGbIk0PxD37tpDKHv3YcK3++SzJmP54QSLedi7lDVND
PaB7lKMdMwMcL+qBb0tMa7lHopHwNVV0mphPssDmPCZY/zv8fBHd0ve4NePtq0VE
Ciej5z62xBjSrYN8CmzIR6FjLsg6A1RwGQAQDYib+GlNsfNHjtL7E7lkOL9IbFhj
GVH4i3wdSAyIhvdNk+wCdfdmG7mbAMT5piMOwcOWyDAvsGUFxcwg36+ZnlYk63tL
PIqaZoZX9Cx6bhd8t7Dx
=W066
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 08:17 AM, quoth Tim Gray:
 Playing around last night, I see if I set add 'multipart/related 
 multipart/mixed' to the front of my alternative order, it does pick 
 up these messages from Apple Mail and display them.

Huh! Interesting solution...

~Kyle
- -- 
A lot of the truths we cling to depend greatly on our own point of 
view.
  -- Obi Wan Kenobi
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzdMAAoJECuveozR/AWedw4QAIVE8oZa7gc28DIs//r5m0mN
OB5Xqxw1rRox6ln8A0RFhsDoe42NZKDTHtkhQ+eUqH3QtqUmxJNPh+sSuA9HmESk
cKyK6oYvLesF5TSxR6Re756dVA/hfX1fPRfWKRFvGondbanLo863dpkBLu606Dv1
hscY3b+K9XcQV/tqQiU0s//96EpS868FbJBSF4iRoV92GoWtZ83Mp9i5L9X/MZij
KPQIFc/eYeFL8FkKu1lumxSJMn43/4yOrPxBtQ5bpvkzOTaQaAWrIRm+VPNVQlo+
4eA3OZfLX55VJhcGFWYq4Sg6OLB4Od31+aPhvcXJHXC421d4XcDMlIkS6HZM33l+
MKcOpVhHRzgvi2sXTMnz6Yw8XG5vKRAcziEwMkpmWklE1ci/Ntp4ARVJTtpHsZjQ
m4Wmv0Bdx4gALSflqPfzj//LpN1a5KahOTayvfHPFta9ajupuqhgiQlDk746CeU0
LJ9AXL+08CK8YAQtccN3t9bCmlMukxhJ+Rc4Ey0Ps3iaoOzZsLl2NWsi3pU8k38U
HjjGwJj6py4Il7XdT+H4K0ettXwQgDowpGuIbA9AWPA+augRzxqa3xwcx7lYGsbu
u0Ha5q0RHHI32PI0z0QjopH7MJuwyLMEXdHd0igi7hC3do1akeNnzUmv9bmjyGB3
ah+dt6uBxyLusthucE8L
=VbL3
-END PGP SIGNATURE-

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at  9:19 AM -0500, Kyle Wheeler wrote:

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.


Details of how this works and why it's hard are here: 
http://www.mutt.org/doc/devel/manual.html#attachments


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.


attachments +I application/.*

was not enough.

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at  9:03 AM -0500, Kyle Wheeler wrote:
It depends on what you're going for. I recommend an attachment counter in 
$pager_format.


I didn't realize this was there.  I think that's what I was asking for. 
Thanks.


I'll also start hitting them with some bug reports.  I have an outlet for 
that, so I might actually get to interact with some engineers on the matter.

Re: multipart/alternative question

[David Champion]

* 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.eduNSITUniversity of Chicago

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at 10:49 AM -0500, David Champion wrote:

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.


Unfortunately, I interact with a lot of people who use Apple Mail.  And I'm 
not sure what the default setting is in it, but I think it's to prefer rich 
text (html).  So there are a lot of people out there sending out problematic 
messages.

Re: multipart/alternative question

[Kyle Wheeler]

-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 

Re: multipart/alternative question

[David Champion]

* On 16 Jul 2009, Kyle Wheeler wrote: 
 
  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.

I mean which alternative you want the attachment counter to look at.


 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 

I think the RFC is leaves a lot of room for ambiguity, and this isn't
necessarily what anyone wants to happen, but I'll agree that it seems
like the most defensible last effort possible.

 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.

When this code was a patch, long back in the 1.3 days, there was a
means of instructing mutt how to descend containers while counting
attachments.  IIRC we decided to drop that in favor of simplicity.
It was more important to me to get the code pushed upstream than to
maintain options.


 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.)

Not necessarily.  The RFC says that if the alternatives are unequal
(whatever that might mean), then the last is the richest.  What if the
first is HTML with an inline addition, and the second is a PDF with all
content inlined within the PDF?  This isn't incorrect because the HTML
is not richer, fancier, or more faithful than the PDF.  It just requires
more parts (in this hypothetical case; certainly this is not necessary
for any hypothetical case.).


 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.

OK, instead of intent let me amend my previous statement to say best
representation in an unintended encoding of what she meant for you to
see.  I don't think it changes anything dramatically.


  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).

It's not really.  Maybe it's ugly if you don't like looking at structure
documents and suddenly you have to, but this is very straightforward and
reasonable and not at all inefficient for a computer to process.  A MIME
boundary is very cheap.  Maybe it looks cleaner to consider it as:

message
alternative-set
alternative
text/
pdf reference=blah/
text/
/alternative
alternative
html/
pdf reference=blah/
html/
/alternative
/alternative-set
pdf id=blah
/message

That's not very ugly or inefficient, as XML documents go.


 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?

Nothing in mutt understands references.  When being counted, a
MIME component is evaluated strictly by its Content-type and
Content-disposition.

-- 
 -D.d...@uchicago.eduNSITUniversity of Chicago

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 01:40 PM, quoth David Champion:
 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

 I think the RFC is leaves a lot of room for ambiguity, and this isn't 
 necessarily what anyone wants to happen, but I'll agree that it seems 
 like the most defensible last effort possible.

Sure, I can swallow that. Faithful to the original content is... 
well, like you said, makes no guarantees about the content.

But here's the thing, I think the most important thing is to be able 
to distinguish between 0 and 0 attachments; it's less important to 
get the 1 vs 2 vs 30 attachments count exactly correct, because it's 
the 1-vs-0 count makes a mutt user decide to look at the mime 
structure. It'd be nice if we could make the attachment count perfect, 
but I think it's a bigger problem to mistakenly say there are zero 
attachments when in fact there is at least one and maybe more.

 It was more important to me to get the code pushed upstream than to 
 maintain options.

I can respect that.

 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.)

 Not necessarily.  The RFC says that if the alternatives are unequal 
 (whatever that might mean), then the last is the richest.  What if the 
 first is HTML with an inline addition, and the second is a PDF with all 
 content inlined within the PDF?  This isn't incorrect because the HTML 
 is not richer, fancier, or more faithful than the PDF.  It just requires 
 more parts (in this hypothetical case; certainly this is not necessary 
 for any hypothetical case.).

That's an excellent example! Let's be a bit more precise, just for 
argument's sake:

  I   1 no description[multipart/alternative]
  I   2 |-no description [multipart/mixed]
  I   3 | |-no description   [text/html]
  I   4 | |-no description   [image/gif]
  I   5 | |-no description   [text/html]
  I   6 | |-no description   [image/gif]
  I   7 | |-no description   [text/html]
  I   8 | |-no description   [image/gif]
  I   9 | `-no description   [text/html]
  I  10 `-no description [application/pdf]

The problem is that the current attachment counting code would look at 
that and report that there are ZERO attachments, when in fact there's 
at least one (the PDF) and maybe more (all the image/gifs).

I think we can make a reasonable argument that, based on the RFC, an 
attachment count of 1 is valid, if not perfect. There may be 
reasonable arguments to say whether a count of 1 or 3 or 4 attachments 
is more preferable. But I think it's absolutely indefensible (from a 
MIME-parsing perspective) to say that there are 0 attachments in such  
an email.

On the other hand, if we have a message structured like this:

  I   1 no description[multipart/alternative]
  I   2 |-no description [multipart/mixed]
  I   3 | |-no description   [text/html]
  I   4 | |-no description   [image/gif]
  I   5 | |-no description   [text/html]
  I   6 | |-no description   [image/gif]
  I   7 | |-no description   [text/html]
  I   8 | |-no description   [image/gif]
  I   9 | `-no description   [text/html]
  I  10 `-no description [text/plain]

I think we can make a pretty good argument to say that this is a 
poorly formed email (not that I can't imagine some really circuitous 
arguments along the lines of the user wanted to send text/plain, so 
adding images was technically less-faithful), and that in that case, 
our attachment counting is allowed to be wrong.

Here's another thought: perhaps the attachment count for a 
multipart/alternative should be the maximum of all of its components. 
Thus, in both this case and the previous case, the attachment count is 
3 (which is a reasonable value, if not a perfect one).

Of course, like I said, I'm more worried about incorrectly saying 
there are 0 attachments when there is in fact (at least) 1 than I am 
with incorrectly saying there are 3 attachments when there are in fact 
(depending on how you count) 4 or even just 1.

 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 
 |   |- 

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 01:14:22PM -0500, Kyle Wheeler wrote:

 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.

Well, I think it depends on what the user of mutt wants to know. I
would want to know how many attachments there are, someone else might
want to know how many attachments would make up the most faithful
representation, and yet another person cares about how many
attachments mutt figures he/she might want to look at. You could as
well count only the attachments mutt can display (with or without the
help of external programs) because the user doesn't need to know about
attachments he cannot even display.

 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.

Hm, when it shouldn't matter for the count if an attachment is
displayed or not, why should it matter if an attachment would be part
of the most faithful representation of the message? Being part of the
most faithful representation or not is only relevant when the
attachment is displayed within the representation it is part of.

It shouldn't matter for the count what an attachment is part of or
where in the message it is. It's still there.

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 02:23:40PM -0500, Kyle Wheeler wrote:

 Of course, like I said, I'm more worried about incorrectly saying 
 there are 0 attachments when there is in fact (at least) 1 than I am 
 with incorrectly saying there are 3 attachments when there are in fact 
 (depending on how you count) 4 or even just 1.

Maybe it's a stupid idea: What if mutt only counts how many containers
are in a message?

Re: multipart/alternative question

[Kyle Wheeler]

-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

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 08:56 PM, quoth lee:
On Thu, Jul 16, 2009 at 02:23:40PM -0500, Kyle Wheeler wrote:

 Of course, like I said, I'm more worried about incorrectly saying
 there are 0 attachments when there is in fact (at least) 1 than I am
 with incorrectly saying there are 3 attachments when there are in fact
 (depending on how you count) 4 or even just 1.

Maybe it's a stupid idea: What if mutt only counts how many containers
are in a message?

Well, I get a lot of messages from people who use email clients with 
default message composition in HTML (that includes Outlook, 
Thunderbird, Apple Mail, and a whole host of others). When they send a 
basic message to say Hi!, their client sends a message structured 
like this:

 I   1 no description[multipart/alternative]
 I   2 |-no description [text/plain]
 I   3 `-no description [text/html]

In this case, the text/plain part says Hi!, and the text/html part 
says bodyHi!/body. It's completely idiotic.

But anyway, I don't consider this message to have ANY attachments. 
The person didn't send me any extra files to look at. They sent me the 
same message twice, one with extra formatting and one without. I don't 
think most people would consider that to be a message with 
attachments, so I don't think mutt should say that there is an 
attachment.

~Kyle
- -- 
There can be but little liberty on earth while men worship a tyrant in 
heaven.
  -- Robert Green Ingersoll
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKX+0pAAoJECuveozR/AWeZEYP/j+9bB9g0vgFYCkE1PduIgKE
RvI9ygNGDpB0XT+zaWDiJa+9DnSQYl3nYvDoeS+kAx8QhnXtlFLjWZvg/9NxoiJd
sOcti1U9JMZHFy4mpDSdtmEMKncw7uMX/F0Aflic/esbhhh1/GBlxMyITshTV2xF
JzV711rKmjNRyhO6irey9aKtWJE1rUaZB4LBfYT0a9VjZh1iHXRzoAlG/JIEJdJx
xQkvP+9ySJeIJ3cnKCvgmLsQJGX0sAz2JWiXgJzKyRvkMuLa0g2+Lx6neTa2nefW
BCJGruMGckTtSf4Yj9m3MsttOHWaO4lm156+2wAmosCgDELVT8bXcAbVu0oaTOv5
s+qYgMbfDxQhGdwRvEGZzo+3X5HnqVZ1wj69atgDnetKODQcpXZkVNe1+cg2l+U6
V4VEk7Qnq4CG2nipj3pkClgaBZVN9W4fQP3xa2Y7N3Lffwku3cQ2DTGrvVkPR+w2
RLXs+PQbSZNoeq8LIWx+/2864aRgDPQuT7AdAawelP9Jgrj5Jvqtlz+ieIAw3eTx
XoODC8Vo9Kqcuc4y/Yus4Ay7kAGRCYaAL+AYJEsbk3k2zMrC+9/KxySZzcXLfYxh
TJRatWl3gtV2jIn9E6/Rb+ZhjMXz9U45aFnMHPITiiV+4w5wWHuAnq3nZb4G7c/+
3wbYbn20rmATPgusxg41
=B0V/
-END PGP SIGNATURE-

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at 10:16 PM -0500, Kyle Wheeler wrote:
But anyway, I don't consider this message to have ANY attachments. The 
person didn't send me any extra files to look at. They sent me the same 
message twice, one with extra formatting and one without. I don't think 
most people would consider that to be a message with attachments, so I 
don't think mutt should say that there is an attachment.


I think we are on the same page Kyle.  You understand where I'm coming from 
with the Apple Mail messages.  I have collaborators who send a lot of files: 
pdfs, jpgs, whatever.  They just toss them in the message window and they 
get inlined just like the example I described early and you showed.  It'd be 
nice if they showed up or got counted somehow but I don't see how to make 
mutt do it.


Of all the ideas discussed so far, I think the one of counting all the non 
text/html attachments in the last part of the multipart makes the most 
sense. Especially if the last part is supposed to be the preferred/richest 
one according to the RFC.

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 10:09:16PM -0500, Kyle Wheeler wrote:
 On Thursday, July 16 at 08:18 PM, quoth lee:
 
  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.

You mean the difference between attachments and mime components is
only a semantical one?

 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.

Well, messages are plain text in the first place. If there's a message
that doesn't have text but a container, that container is an
attachment. You might argue whether things inside the container are
also attachments or not. To me they are because it doesn't matter to
me if things attached to a mail are contained in a container or not.

If you argue that things inside containers are not to be counted as
attachments, then you cannot count a container other than the mail
itself as attachments because the mail is a container (containing
other containers) itself.

  So what's the difference between inline and attachment?
 
 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.

That's what I meant. Still all the components are attachments, no
matter if they are to be displayed in line or not.

  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).

Even when mutt doesn't recurse into multipart/alternative, the
multipart/alternative itself is an attachment which should be counted:


  I 1 no description[multipa/alternativ, 7bit, 4.2K]
  I 2 no description   [text/plain, quoted, iso-8859-1, 1.3K]
  I 3 no description   [text/html, quoted, iso-8859-1, 2.5K]


Mutt says that there are 0 attachments. I say there's at least 1.

 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!

The interesting question is: *What* has been 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.

RFC822:



  A message consists of header fields and, optionally, a body.
 The  body  is simply a sequence of lines containing ASCII charac-
 ters.  It is separated from the headers by a null line  (i.e.,  a
 line with nothing preceding the CRLF).



You could argue that the message doesn't have an attachment because
everything is to be displayed in line. I would argue that everything
that isn't either headers or body as described in RFC822 is an
attachment.

Containers? If you put a container containing 1 bricks onto a
container ship, you have 1 bricks on the container ship (and one
container). For the purpose of counting containers, you loaded one
container; for the purpose of counting bricks, you loaded 1
bricks.

So what do you want to count, containers or everything that is
attached to the ship?

  (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.

Indeed --- or lets say I have a different understanding.

 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.

So you would say that all of them are attachments and therefore should
count as such, no matter how they are supposed to be displayed.

 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?

Once I received the message, I either already received the JPEG or the
icon or both, as an attachment or as attachments.

You shouldn't ask me that because if I wanted to send someone a
message and a JPEG, I would send a plain text message and attach the
JPEG. If I wanted the recipient to look at the 

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:

 But anyway, I don't consider this message to have ANY attachments. 
 The person didn't send me any extra files to look at. They sent me the 
 same message twice, one with extra formatting and one without. I don't 
 think most people would consider that to be a message with 
 attachments, so I don't think mutt should say that there is an 
 attachment.

Well, I would consider such a message as attachment only: No message
(i. e. no body), only three attachments.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 10:27 PM, quoth lee:
 On Thu, Jul 16, 2009 at 10:09:16PM -0500, Kyle Wheeler wrote:
 On Thursday, July 16 at 08:18 PM, quoth lee:

 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.

 You mean the difference between attachments and mime components is 
 only a semantical one?

No, I mean that MIME components (aka entities) have meanings that 
affect the interpretation of other MIME entities. For example, take 
PGP/MIME, where one MIME entity (the signature) can affect the 
understanding of another. As another example, take multipart/mixed, 
which is only a container for other MIME entities and has no inherent 
content itself.

The term attachment, on the other hand, is a poorly defined term 
that has different meanings based on who you ask. For example, you 
seem to think that all MIME entities count as attachments, while I 
tend to think of attachments as only those things that a user has 
explicitly attempted to attach (I don't think the body text of a 
message counts as an attachment).

I could appeal to something like Wikipedia (which says an email 
attachment is a computer file which is sent along with an email 
message), but I'm guessing you don't care much for so-called 
official definitions.

 Even when mutt doesn't recurse into multipart/alternative, the 
 multipart/alternative itself is an attachment which should be 
 counted:


  I 1 no description[multipa/alternativ, 7bit, 4.2K]
  I 2 no description   [text/plain, quoted, iso-8859-1, 1.3K]
  I 3 no description   [text/html, quoted, iso-8859-1, 2.5K]


 Mutt says that there are 0 attachments. I say there's at least 1.

We clearly have different definitions of the term.

I find my definition more useful, because then I can use it to tell me 
whether there's some component of the message that I can and will want 
to save to disk. In the message structure you show there, none of 
those MIME entities are things I have any interest in saving to disk. 
None of those MIME entities are things the sender explicitly 
attached to the message (by using the attach function of his/her 
mailer). It makes sense to me.

What's the utility of your definition?

 Containers? If you put a container containing 1 bricks onto a 
 container ship, you have 1 bricks on the container ship (and one 
 container). For the purpose of counting containers, you loaded one 
 container; for the purpose of counting bricks, you loaded 1 
 bricks.

 So what do you want to count, containers or everything that is 
 attached to the ship?

I want to know if I need to unload anything from the ship. I want to 
know the difference between a ship loaded full of empty containers 
(that I don't care about) and a ship loaded full of bricks (things 
that I want). Thus, I can ask how many things are on the ship? and 
get an answer. If the ship merely has a hundred empty containers, and 
my smart-alecky captain says there's a hundred things on the ship, 
I'm gonna be annoyed when I rifle through every last container and 
discover that they're all empty. On the other hand, if I paid to ship 
a thousand bricks, and there's one container with a thousand bricks, 
when he tells me there just one thing on the ship, I'm *still* going 
to be annoyed that he was playing goofy semantic games and didn't tell 
me that everything I ordered was in fact on the ship.

Why do *you* care how many containers are on the ship?

 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.

 So you would say that all of them are attachments and therefore should 
 count as such, no matter how they are supposed to be displayed.

Am I really that hard to understand, or are you just trying to get 
under my skin?

For the umpteenth time, no, not all MIME entities are attachments.

 RFC822:

RFC 2045:

 This set of documents, collectively called the Multipurpose
 Internet Mail Extensions, or MIME, redefines the format of
 messages to allow for

 (1) textual message bodies in character sets other than US-ASCII,
 (2) an extensible set of different formats for non-textual message
 bodies,
 (3) multi-part message bodies, and
 (4) textual header information in character sets other than
 US-ASCII.

Thus, in the context of MIME, the RFC 822 definition of a message 
format is no longer supreme. It has been, in the words of the MIME 
RFC, redefined.

 If you include a JPEG in an email, should that JPEG be displayed 
 when the user views 

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 10:51 PM, quoth lee:
On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:

 But anyway, I don't consider this message to have ANY attachments.
 The person didn't send me any extra files to look at. They sent me the
 same message twice, one with extra formatting and one without. I don't
 think most people would consider that to be a message with
 attachments, so I don't think mutt should say that there is an
 attachment.

Well, I would consider such a message as attachment only: No message
(i. e. no body), only three attachments.

Logically, an attachment needs something to be attached TO.

In snail mail, a letter is not an attachment, and when you staple 
something to a letter (such as a photograph), the photograph is 
considered the attachment, the letter is the thing to which the 
photograph is attached. They do not both become attachments of each 
other.

The MIME equivalent of what I just described is this:

 I   1 no description  [multipart/mixed]
 I   2 |-no description   [text/plain]
 A   3 `-no description   [image/jpeg]

Entity #3 is the attachment. It is attached to Entity #2. Entity #1 is 
the staple: it exists only for the purpose of attaching #3 to #2.

I understand, having read enough philosophy, that you can argue ad 
infinitum about the truth that the letter is just as much the 
attachment to the photograph as the photograph is an attachment to the 
letter, but that's a really pointless argument.

~Kyle
- -- 
Scientists have shown that the moon is moving away at a tiny, although 
measurable distance from earth every year. If you do the math, you can 
calculate that 65 million years ago, the moon was orbiting at a 
distance of about 35 feet from the earth's surface. This would explain 
the death of the dinosaurs ... the tallest ones, anyway.
 -- Unknown
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYBC8AAoJECuveozR/AWeD+8P/ifUZrtgI4Wxa68iDapDtrEE
QG9Mu+TVEOzvl/VGeeYa5+HWgrMgo49Z8dTwtLVNqG5y8osFCv4Fn20qm5tN9Kq7
AhueBVirIPCsE2RpOsYgEbtHfzvIb6iXcqDaw3oE0S/5HQDjhwbdkOmHdLAw/bW2
pjPNb9hTb7RGS0KtmFk9to9k0nqaxa0y3C/hVM1Tod/IdG3pelY6mnXTMhmfx/fO
TMCLjq3++9ahxPFyJS8qwTDoGDmK+k4M8TPEI3dsr4LZ713f+yUZrFK1rxcMnbV8
ZzB/z5id1nDj8lRMdJGtfVA0cxvWk2hK7Aw8sDGW8qDDn7DSxc0FIHMTow4456Sa
n/WDUtCKXKFdtBfJ9aQwA/PlPgmXb192DBPGt8uiD3qf1hQ32HDZ+j4zHUkCSpZK
bdhOGbdPqnXd9BOw+WD//n/SA8Wf4pZU+hoGREFaahJCYgs5oAiExeK0N2+U/Lzh
kKpX8JszIUnIkE4JCUoTLSVp+Dotyfl/AELWet3Vxz/Bf11uLeNhq9Xp52yKKaSM
JV6wbFHhgdOaq4T6pgEHzQfdm9JoYFMCB975onojRfnFjbbcac3VR+UlQoYs8m1C
Vq+vCRqv/eHN/mJGs+asIiwDBWAK7T3NXPjphJNPXDhAFOM07k9VSimC3I2VuiWg
EAaEkbAc4/l4+NJZgrUE
=N8SF
-END PGP SIGNATURE-

multipart/alternative question

[Tim Gray]

I have my alternative_order set to text/plain text/html.  All works as 
expected.  However I have some people who use a mailer (Apple Mail) that 
send multipart/alternative messages with attachments.  So the two parts of 
the message are a text/plain and a multipart/mixed.  The multipart/mixed 
consists of said file attachment and a text/html part.  Since mutt is set to 
prefer text/plain, all I see is the plain text message, with no indication 
that there is an attachment (or even an html part).


I don't know if this is normal behavior for multipart/alternative messages 
with attachments, or a quirk of Apple Mail.  I would have thought that the 
text/plain and text/html part of the messages should make up the multi/alt 
part, with other file attachments living at the same level as the multi/alt 
part, not buried in *one* of the alternative components


So, what is the best way to deal with this?  Is there anyway to just prefer 
the text/plain but look for attachments in the text/html branch?  Or have an 
indication that there is a text/html branch onscreen so I know to look 
there?  Or is the only route to set my alternative_order to prefer text/html 
first...


Thanks

Re: multipart/alternative question

[lee]

On Wed, Jul 15, 2009 at 11:02:38PM -0400, Tim Gray wrote:
 So, what is the best way to deal with this?  Is there anyway to just 
 prefer the text/plain but look for attachments in the text/html branch?  
 Or have an indication that there is a text/html branch onscreen so I know 
 to look there?

And more general, is there a way to get an indication that a mail does
have an attachment or attachments? I would give them a different color
in the list; that would prevent me from opening such messages without
checking them before.

Other than that, if I get a mail that isn't readable, I delete it. If
someone sends me a mail but makes it difficult to read, he obviously
doesn't care if I read it or not, so why should I waste my time with
it.

Re: multipart/alternative question

[Tim Gray]

On Wed 15, Jul'09 at 10:08 PM -0600, lee wrote:

And more general, is there a way to get an indication that a mail does
have an attachment or attachments? I would give them a different color
in the list; that would prevent me from opening such messages without
checking them before.


You could set up a coloring rule using the ~X matching pattern.  Something 
like:


color index red default ~X 1-

should work.  You can also use the %X sequence in your index_format 
definition to display the number of attachments in a message.  However, I 
don't think either of those methods pick up on inline attachments.



Other than that, if I get a mail that isn't readable, I delete it. If
someone sends me a mail but makes it difficult to read, he obviously
doesn't care if I read it or not, so why should I waste my time with
it.


Unfortunately I have collaborators whom I must work with who aren't 
particularly email savvy.  I can't just toss their emails.