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 isn't sufficient, you can always attach a file, like PDF, or zip up a LaTeX source and attach that. (One thing I keep wondering about is why they didn't invent a standard for using footnotes in email. It isn't really needed, but could be useful ...) Then read RFC822 ... That's where my understanding of what an attachment is comes from --- call me old fashioned if you want to. The mime designers may have a different understanding and have managed to (re-)define things. Fine, but to me, an attachment is an attachment, no matter what it contains or how it's supposed to be displayed, simply because it's attached to a mail. Sure, if you define what a mail (message) is differently, it can become difficult to decide if something is an attachment or not. 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? The distinction they came up with (inline vs. not-inline) appears to me as very artificial and as something that doesn't really matter. They even go so far as to say that it doesn't matter and that a MUA should display a message the way the user wants. That eventually negates their artificial distinction. > > 2045 says: > > 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? > > Keep reading: > > 2.6. Body > > The term "body", when not further qualified, means the body of > an entity, that is, the body of either a message or of a body > part. > > NOTE: The previous four definitions are clearly circular. This > is unavoidable, since the overall structure of a MIME message > is indeed recursive. They could just say that a message is everything that is transferred between the DATA command and the end marker in an SMTP session (see RFC 821). They wouldn't even have to redefine what RFC822 says because it basically says the same. The "body of a body part"?! These people must be confused somehow. A body part doesn't have a body, the body *is* the body part. > 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? > > I'm afraid we can turn this back and forth as long as we want > > without getting anywhere. > > Agreed.
