Talk:MIME/Archive 1

Archive 1

How much mail is actually MIME?

There's been a revert between "large portions" of Internet mail is MIME and "virtually all" Internet mail is MIME. These two statements are not equivalent. Please discuss, don't just change. (Having been part of writing MIME, I'm too close to the action to want to have strong opinion.) Alvestrand 08:37, 12 January 2006 (UTC)

it seems to me that virtually all human written e-mail is MIME but quite a bit of automated mail isn't. Plugwash 10:57, 12 January 2006 (UTC)

In a sample of 12690 messages I found (a log from October), 10814 messages had the MIME-Version: 1.0 header. That's 85%, but no guarantee that it's typical.

were those human written messages automated messages or a mixture of the two? Plugwash 13:00,12 January 2006 (UTC)

Mixture. Sorry - no proportion available. But I think the amount of spam was in the 1000-2000 range; 947 of the 1061 tagged-as-spam messages in the folder had a MIME-Version: field (89%). (I do run another spam filter in front of this - the 1061 messages were "almost certainly spam" - the "almost completely certainly spam" stuff doesn't get that far).

The solution here is to find and cite a reputable source for internet email format statistics. I'd think yahoo or aol or any of the top tier ISPs could have such data, but I'm not aware of any that publish such data. An alternative would be to ask someone who might be in a position to know or be able to find out such data, and would be willing to be quoted. Lacking a source, it's really just anecdotal (and I'm pretty sure I added the "virtually all" bit a while ago, not based on any hard statistics). Perhaps an email to postmaster@yahoo.com (for example) might get a response. -- Rick Block (talk) 02:38, 13 January 2006 (UTC)

History of MIME

This article needs being heavily expanded. What about the history of MIME? It's creators (Nathaniel Borenstein...), how started to being created, first apps being used, MIME in the actuality...

Multipart Example: used munpack but no decoded secret message satisfaction

I like the Multipart Example, but why don't you use something that decodes to e.g., English, instead of just random seeming data?

amb proposal

I propose that Mime be a redirect to MIME and a dictionary definition link be put at the top of this page, as that is why most of the links to Mime are trying to do. --Spook ^{(my talk | my contribs)} 08:43, 21 February 2006 (UTC)

Someone's been awfully busy, I guess. Among the ~150 links to Mime, I couldn't see one that was obviously trying to get to MIME - they mostly seem to be acting-related. --Alvestrand 10:05, 21 February 2006 (UTC)

The MIME links, I'm guessing, have been fixed. the remaining ones have nothing to be linked to. --Spook ^{(my talk | my contribs)} 10:18, 21 February 2006 (UTC)

BTW is there a policy on linking to wiktionary inline when a dicdef for a word is desired? Plugwash 22:06, 20 October 2006 (UTC)

Moved Multipart_message to MIME

The article Multipart_message was marked for expert cleanup. I'm not an expert on mime, but what it needed was to be merged with this article, so I added it to the multipart example section, and renamed that section. Zab 11:44, 21 February 2006 (UTC)

Content-Transfer-Encoding: binary

Can anyone explain how this deals with binary data that includes the mime-boundary string? Is there some sort of escaping mechanism? -- Chris Q 14:04, 5 April 2006 (UTC)

Its up to the sending app to choose a boundry string that doesn't exist in the body content. Most real mail apps tend to achive this by using a long string of random data as part of the boundry (thus making the chance of a clash vanishingly small), i don't know if they actually contain checks for the exceedingly small chance that thier random string matches something in the message. Our example only uses the word "frontier" to keep clutter down, no real mail client would use a fixed dictionary word.

P.S. Binary content transfer encoding is not usable with internet mail anyway it was just included for completeness. Plugwash 15:56, 5 April 2006 (UTC)

Thanks. I am looking into MTOM and XOP, where binary content is the preferred method (and may be compulsory. All examples seem to use it, but this is not mentioned in the spec.) I have has a quick look at the Apache axis2 source and that seems to work in the way you mention for most mail apps, having a long string of random data and relying on the probability of it occurring being insignificant. -- Chris Q 11:10, 6 April 2006 (UTC)

removed sentences

There is no encoding defined which is explicitly designed for sending arbitrary binary data through 8BITMIME transports, thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used.

This is just not true. In fact binary was mentioned in the list just before this. -- Chris Q 14:11, 14 June 2006 (UTC)

did you actually read the specifications?

Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets. Given that this restriction still applies, this extension does NOT provide a means for transferring unencoded binary via SMTP.

-- Plugwash 20:14, 14 June 2006 (UTC)

I did, but the whole article is SMTP-Centric, and the sentence did not make it clear that this only applied to SMTP email. See [1] for example of the use of Content-Transfer-Encoding: binary. -- Chris Q 06:58, 15 June 2006 (UTC)

There is another specification that does give a binary MIME transport: It is RFC 3030, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages". It is a Proposed Standard, and I have no idea whether anyone's using it in production. --Alvestrand 21:28, 14 June 2006 (UTC)

That RFC said it was expected to become a standards track, do you know if there is any way to find out what if anything has happened in that regard since? and do you think it is notable enough to mention here? Plugwash 22:47, 14 June 2006 (UTC)

Formalities: When it's a Proposed Standard, it's standards track. So nothing more will happen until someone decides it needs updating, or wants to progress it to Draft Standard, or give up and declare it Historic. --Alvestrand 06:22, 27 June 2006 (UTC)

I've seen BDAT in fresh drafts some weeks ago, IIRC it was about submitting mail with body parts taken from an IMAP message store. Or related, look for "BURL BDAT" at the IETF site. -- Omniplex 14:32, 16 June 2006 (UTC)

Juniper claims that Microsoft Exchange has a security vulnerability in BDAT, so I guess Exchange implements it: [2]. --Alvestrand 06:26, 27 June 2006 (UTC)

broken link: MailCap

This was working as of 6/22. What happened?
Question by User:HogPrime.

The page log says "deleted 2005-04-07", that doesn't match your observation. -- Omniplex 03:38, 27 June 2006 (UTC)

MIME Pronounciation

I added how MIME is pronounced. The pronounciation was taken from: http://www.uic.edu/depts/accc/newsletter/adn13/mime.html#0 (4th line). -- Defilerc 09:00, 15 October 2006 (UTC)

I'm removing the word again, for several reasons:

1. for non-native English speakers, it's not clear how "the word mime" is pronounced
2. In Scandinavia, we pronounce MIME roughly like "mi" in "miniature" followed by "me" as in "metric" (which is, accidentally, how the word "mime" is pronounced there too).
3. All material should be referenced, and the references should be in the article
4. This is not important enough to go into the introduction section. Perhaps a trivia section.

--Alvestrand 10:11, 15 October 2006 (UTC)

Greetings Alvestrand and thanks for the comments. I reconsidered my addition to: (pronounced /maɪm/ [3]). Concering your comments:

1-2. You're right. I'm neither a native English speaker, that's why I added the pronounciation; because the first time I read the article I was curious how the word MIME is pronounced. According to International Phonetic Alphabet for English a better transcription is /maɪm/.

3. I added the reference next to the pronounciation.

4. I added the pronounciation to the introduction because that's where the word appears for the first time. In my opinion, a user shouldn't keep reading through the whole document just to find out at the end how the word MIME is pronounced correctly. In many other technical articles I have read the pronounciation is added at the beginning, that's why I did the same.

If you agree with the above, reconsider adding the revised sentence to the article.

-- Defilerc 21:22, 15 October 2006 (UTC)

This doesn't make much sense, to be honest.

Mime redirects to the email encoding and not the performance art? I propose Mime be redirected to the Mime (disambiguation) page, if not redirected to the performance art article outright. While it's true that people wanting to know what MIME is may incorrectly input Mime as a search time, it's more probable that anyone searching for Mime would be searching for the performance artist.

I also think the articles on MIME and Mime could use some better toplinking, but I'm going to withhold any action until I get some input or a few days pass. Cheers, Lankybugger 13:52, 23 January 2007 (UTC)

Here's a vote in support of changing the redirect to disambiguation (DAB) page, not so much in support of redirect to the man trapped in the box, however. Not sure what is the WP policy for redirects to a DAB, if there is one. dr.ef.tymac 14:23, 23 January 2007 (UTC)

As the edit history of Mime shows, I can see there's a lot of resistance from editors as regards the switch from Mime as a redirect to this article. However, the What Links Here report for Mime tells me that a fair number of editors are linking to Mime under the assumption it's about the performance art. Editors with an interest in accuracy have already corrected any instances of Mime referring to MIME, it would seem.

Honestly, the more I investigate this the less sense the relinking Mime to MIME makes. Is there any real reason the Mime artist article hasn't been merged with Mime already? Toplinking would take care of any problematic searches quite easily and this current setup is messy and illogical. The Mime (disambiguation) page contains only four choices and unlike some others with forks, they're not related in any way. Heck, toplinking between the M.I.M.E program and MIME, as well as Mime as a performance art and Mime as a Final Fantasy Character class could easily take care of the need for a Disambiguation page. Cheers, Lankybugger 15:37, 23 January 2007 (UTC)

I would prefer that it redirect to the disambiguation page. To my knowledge, most search engines that I use are not case sensitive - and this is what I've come to expect when I use one. I expect "mime" and "MIME" to return exactly the same query results. I had a heck of a time finding this article (I am so disinterested in "mime art" that I didn't even begin reading it - and consequently never saw any link to this page that other people are reporting exists there) JimH443 19:45, 28 April 2007 (UTC)

Renaming page for better accuracy

I propose that we rename this page to spell out the acronym (Wikipedia:Naming_conventions#Prefer_spelled-out_phrases_to_abbreviations). Unfortunately, the redirect at Multipurpose Internet Mail Extensions has a just barely non-trivial page history, so I can't move it without reverting the edit. (Go to the page history to see what I mean.) —Preceding unsigned comment added by Web-Crawling Stickler (talk • contribs)

I disagree - for better or worse, MIME is much better known by its acronym than by its longname. Just like Light Amplification by Stimulated Emission of Radiation. Put the article at its best known name. --Alvestrand 20:57, 8 March 2007 (UTC)

I agree with Alvestrand. Mime redirects to Mime artist which has a "for the other, see" (as does {MIME]]) so I don't think ambiguity is an issue. Not that it's authoritative, but a google search for "MIME email" returns more than 12,000,000 hits, while "multipurpose internet mail extension" returns only 69,000 (I added "email" to both searches since google's search is case insensitive). -- Rick Block (talk) 02:12, 9 March 2007 (UTC)

I thought it was spelled out previously, I just got here from a diff on my watchlist on another page. It should be spelled out, with a redirect at MIME and a link from Mime artist. For example, see Transmission Control Protocol (not 'TCP), Simple Mail Transfer Protocol (not 'SMTP'), and Hypertext Transfer Protocol (not 'HTTP'). It looks like all the other protocols are spelled out (yes, I know that MIME is not a network protocol per se, but the examples apply). — RevRagnarok ^{Talk Contrib} 11:51, 9 March 2007 (UTC)

Suggestion for future addition

RFC2047, Section 3 contains the following paragraph

Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.)

Having attempted to implement this RFC, to implement this paragraph with available character set and encoding libraries is extraordinarily difficult (practically impossible to do reliably without tailoring your own conversion algorithms for all relevant standard sets and encodings). So it would be interesting in this article to discuss whether this "MUST" clause is generally obeyed - if anybody has any sources on this. If somebody does have a source, I can write something up. TristanDC 23:29, 1 December 2007 (UTC)

Spelling: multi-part OR multipart?

Hi, in this article, the spelling varies. Are they both correct? Robert Illes (talk) 12:09, 23 May 2008 (UTC)

I think it consistently uses "multi-part" in general prose and "multipart" when referring specifically to the MIME content-type (which has no hyphen). To avoid any confusion I don't think it would be a bad idea to use "multipart" exclusively, perhaps rewording the two or three occurrences of "multi-part message" to "messages with multiple parts". -- Rick Block (talk) 13:56, 23 May 2008 (UTC)

Content-Transfer-Encoding: base64

The article states:

The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary"...

But the example uses both the default (which I believe is 7bit) and "base64". So,what gives? Am I just misunderstanding this?

DRogers (talk) 19:48, 5 December 2008 (UTC)

The example is one message with an outer multipart wrapper using the default content-transfer-encoding (which is 7bit). The sentence you quote says that these multipart wrappers must use 7bit, 8bit, or binary. In the example there are two nested parts inside the multipart wrapper, a text/plain and an application/octet-stream. The application/octet-stream uses base64 which is fine since it's not a multipart. -- Rick Block (talk) 22:44, 5 December 2008 (UTC)

The content transfer encoding of the multipart type itself has to be 7bit 8bit or binary but the content-type of the parts inside does not (unless of course those parts inside are themselves multipart types). Plugwash (talk) 00:03, 30 December 2008 (UTC)