The Full Wiki

MIME: Wikis

  
  

Encyclopedia

From Wikipedia, the free encyclopedia

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)
Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of e-mail to support:
  • Text in character sets other than ASCII
  • Non-text attachments
  • Message bodies with multiple parts
  • Header information in non-ASCII character sets
.MIME's use, however, has grown beyond describing the content of e-mail to describing content type in general, including for the web (see Internet media type).^ MIME Types Skip to: content , navigation .

^ Mime Content Types used in OpenOffice.org2.0 / StarOffice 8 and later .

^ It makes use of the multipart/signed MIME type described in [MIME-SECURE].
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

.Virtually all human-written Internet e-mail and a fairly large proportion of automated e-mail is transmitted via SMTP in MIME format.^ MIME is a standard for format of e-mail messages.
  • MIMEBlackbox (MIME, S/MIME and OpenPGP/MIME parser, assembler, control, components, object, class, .NET component) - SecureBlackbox® 11 January 2010 2:58 UTC www.eldos.com [Source type: FILTERED WITH BAYES]

^ MIME multipurpose Internet mail extensions .
  • Mime Definition | Definition of Mime at Dictionary.com 11 January 2010 2:58 UTC dictionary.reference.com [Source type: Reference]

^ Review This Crazy World — Authority: 163 Multipurpose Internet Mail Extension (MIME) is a technical specification indicating how multimedia data and e-mail attachments are to be transferred.
  • mime Articles, Posts, Blogs, Videos - Technorati 11 January 2010 2:58 UTC technorati.com [Source type: General]

.Internet e-mail is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME e-mail.^ MIME is a specification for enhancing the capabilities of standard Internet electronic mail.
  • MIME - Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC www2.rad.com [Source type: Reference]

^ Review This Crazy World — Authority: 163 Multipurpose Internet Mail Extension (MIME) is a technical specification indicating how multimedia data and e-mail attachments are to be transferred.
  • mime Articles, Posts, Blogs, Videos - Technorati 11 January 2010 2:58 UTC technorati.com [Source type: General]

^ The MIME component allows for easy implementation of the Multipurpose Internet Mail Extensions or MIME as defined in RFC 1521 and updated in RFCs 2045-2049.
  • ASP.Net MIME Controls MIME Components 20 September 2009 17:59 UTC www.devdirect.com [Source type: General]
  • MIME Controls MIME Components - for .Net ASP.Net Java ActiveX Delphi C/C++ 20 September 2009 17:59 UTC www.devdirect.com [Source type: Reference]

[1]
.The content types defined by MIME standards are also of importance outside of e-mail, such as in communication protocols like HTTP for the World Wide Web.^ MIME Types Skip to: content , navigation .

^ View MIME types by content type .
  • MIME Types by File Extension - List of MIME Types 20 September 2009 17:59 UTC webdesign.about.com [Source type: General]

^ HTTP protocol is defined by RFC 2068 .
  • Introduction to i18n - the Internet 11 January 2010 2:58 UTC www.debian.org [Source type: Reference]

.HTTP requires that data be transmitted in the context of e-mail-like messages, although the data most often is not actually e-mail.^ The actual message data.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ The actual boundary string will be randomly generated by the sender's mail agent and, although the MIME RFCs (1341 and 1521 through 1524) don't require that it be enclosed in double quotes, most modern MIME mail agents will do so in order to ensure that the contents of the boundary string are clearly defined.
  • @internet -- A Walk Through the MIME Fields 11 January 2010 2:58 UTC users.rcn.com [Source type: FILTERED WITH BAYES]

^ MIME Multipurpose Internet Mail Extensions The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • mime Resources | ZDNet 11 January 2010 2:58 UTC updates.zdnet.com [Source type: General]

.MIME is specified in six linked RFC memoranda: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049, which together define the specifications.^ MIME is currently defined in RFCs 2045 , 2046 , 2047 , 2048 , and 2049 and registered values for MIME types are available in IANA .

^ MIME is described mainly in RFC 2045 , 2046 , 2047 , 2048 , and 2049 .

^ MIMEBlackbox is fully conformant to existing MIME standards as defined by RFC 2045 to 2049.
  • MIMEBlackbox (MIME, S/MIME and OpenPGP/MIME parser, assembler, control, components, object, class, .NET component) - SecureBlackbox® 11 January 2010 2:58 UTC www.eldos.com [Source type: FILTERED WITH BAYES]

Contents

Introduction

.The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME).^ Original SMTP can only send ASCII characters.
  • Introduction to i18n - the Internet 11 January 2010 2:58 UTC www.debian.org [Source type: Reference]

^ Many email clients also support MIME, enabling them to send and receive embedded media via the internet mail system.

^ MIME Multipurpose Internet Mail Extensions The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • mime Resources | ZDNet 11 January 2010 2:58 UTC updates.zdnet.com [Source type: General]

.This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English.^ In fact, we learned that, Multipurpose Internet Mail Extensions (MIME) types can allow us to include non-ASCII content in Internet Mail messages, despite the fact that Internet Mail is, by default, currently limited to transmitting only the first 128 US ASCII characters (characters 0 through 127) in order to maintain downward compatibility with older Mail Transfer Agents (MTAs).
  • @internet -- A Walk Through the MIME Fields 11 January 2010 2:58 UTC users.rcn.com [Source type: FILTERED WITH BAYES]

^ MIME Multipurpose Internet Mail Extensions The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • mime Resources | ZDNet 11 January 2010 2:58 UTC updates.zdnet.com [Source type: General]

^ According to the MIME FAQ, MIME, the Multi-purpose Internet Mail Extensions, is a freely available specification that offers a way to interchange text in languages with different character sets, and multi-media e-mail among many different computer systems that use Internet mail standards.
  • Using MIME at Maryland 11 January 2010 2:58 UTC www.cs.umd.edu [Source type: Reference]

.Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail.^ MIME Multipurpose Internet Mail Extensions The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • mime Resources | ZDNet 11 January 2010 2:58 UTC updates.zdnet.com [Source type: General]

^ [ISO88591] "Information Processing -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No.
  • HTML 4 Specification References 20 September 2009 17:59 UTC www.ooad.org [Source type: Academic]
  • HTML 4.0 Specification References 20 September 2009 17:59 UTC www.blythe.org [Source type: Academic]

^ M ultipurpose I nternet M ail E xtensions) The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • ChannelWeb Encyclopedia 11 January 2010 2:58 UTC www.crn.com [Source type: General]

.MIME defines mechanisms for sending other kinds of information in e-mail.^ The MIME component allows for easy implementation of the Multipurpose Internet Mail Extensions or MIME as defined in RFC 1521 and updated in RFCs 2045-2049.
  • ASP.Net MIME Controls MIME Components 20 September 2009 17:59 UTC www.devdirect.com [Source type: General]
  • MIME Controls MIME Components - for .Net ASP.Net Java ActiveX Delphi C/C++ 20 September 2009 17:59 UTC www.devdirect.com [Source type: Reference]

^ If you set up your Internet Agent program with two foreign domains, one defined to send in MIME format, the other defined to send in RFC-822 format, you can easily choose the best way to send the message.
  • What Is Mime Encoding? Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC bugclub.org [Source type: Reference]

^ The Multipurpose Internet Mail Extensions ( MIME ) define a standard means for structuring mail messages.
  • MIME Support - IMAIL 1.19 11 January 2010 2:58 UTC www.gnu.org [Source type: Reference]

.These include text in languages other than English using character encodings other than ASCII, and 8-bit binary content such as files containing images, sounds, movies, and computer programs.^ A file containing a byte-for-byte representation of the contents of a program's memory.
  • Software Carpentry:Glossary (Version 1121) 20 September 2009 17:59 UTC swc.scipy.org [Source type: Reference]

^ It is really intended for binary files that have been sent in an ascii-encoded manner.
  • Using MIME at Maryland 11 January 2010 2:58 UTC www.cs.umd.edu [Source type: Reference]

^ The contents of the file are plain ASCII text in 4-5 columns.
  • mod_mime_magic - Apache HTTP Server 11 January 2010 2:58 UTC httpd.apache.org [Source type: Reference]
  • Apache module mod_mime_magic 11 January 2010 2:58 UTC vigyan.nsu.edu [Source type: Reference]

.MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages even though the data might not (and usually doesn't) actually have anything to do with e-mail.^ The actual message data.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ The MIME protocol comprises two components.
  • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

^ Such data cannot be transmitted over some transport protocols.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail.^ SOAP payloads in SMTP MUST to be packaged into a MIME [4] message.
  • SMTP Transport Binding for SOAP 1.1 11 January 2010 2:58 UTC www.pocketsoap.com [Source type: Reference]

^ "This is a multi-part message in MIME format.
  • mail attachment problem? - PHP 11 January 2010 2:58 UTC www.daniweb.com [Source type: FILTERED WITH BAYES]

^ This is a multi-part message in MIME format.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]
  • mail attachment problem? - PHP 11 January 2010 2:58 UTC www.daniweb.com [Source type: FILTERED WITH BAYES]

.The basic format of Internet e-mail is defined in RFC 5322, which is an updated version of RFC 2822 and RFC 822.^ RFC 822 This RFC defines that standard format of e-Mail messages on the Internet.
  • Multipurpose Internet Mail Extensions (MIME) Encoding - OIT Help Desk 11 January 2010 2:58 UTC www.helpdesk.umd.edu [Source type: Reference]

^ The new Internet mail standard - MIME (defined in RFCs 1521 & 1522 ) is an extension of the basic Internet mail standard ( RFC 822 ).
  • MIME - Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC www2.rad.com [Source type: Reference]

^ The MIME format includes a mail header identical to the RFC-822 header.
  • What Is Mime Encoding? Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC bugclub.org [Source type: Reference]

.These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set.^ ASCII characters (octets with the high-order bit set).
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The MIME charset name for this character set is "US-ASCII".
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ EnvelopedData Content Type This content type is used to apply data confidentiality to a message.
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

.MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.^ Don't generate header fields that contain unencoded non-ASCII characters.
  • Recipient-Friendly MIME generation 11 January 2010 2:58 UTC www.cs.utk.edu [Source type: Original source]

^ Message and body part headers consist entirely of ASCII characters.
  • Recipient-Friendly MIME generation 11 January 2010 2:58 UTC www.cs.utk.edu [Source type: Original source]

^ The message header fields that were added to the RFC 822 mail structure are: .
  • MIME Overview 11 January 2010 2:58 UTC www.dart.com [Source type: Reference]

MIME is extensible. .Its definition includes a method to register new content types and other MIME attribute values.^ Mime type names can get officially registered.
  • MIME::Type(3) - Definition of one MIME type 11 January 2010 2:58 UTC www.gsp.com [Source type: Reference]

^ MIME Type window and create a new type.
  • developerWorks : Rational : Rational Method Composer - RMC : "error loading tree" ... 11 January 2010 2:58 UTC www.ibm.com [Source type: FILTERED WITH BAYES]

^ Mime Content Types used in StarOffice 5.x .

.The goals of the MIME definition included requiring no changes to existent e-mail servers and allowing plain text e-mail to function in both directions with existing clients.^ MIME is a set of extensions to the standard Internet message format that allows reliable transmission of arbitrary data including images, audio and video, as well as ordinary text.
  • VM User's Manual - Reading MIME Messages 11 January 2010 2:58 UTC www.wonderworks.com [Source type: Reference]
  • Reading MIME Messages 11 January 2010 2:58 UTC w3.pppl.gov [Source type: Reference]

^ This module provides functions to encode and decode strings into and from the base64 encoding specified in RFC 2045 - MIME (Multipurpose Internet Mail Extensions) .
  • MIME::Base64 - search.cpan.org 11 January 2010 2:58 UTC search.cpan.org [Source type: Reference]

^ This includes even the text/plain MIME content that usually precedes a binary attachment.

.These goals were achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client.^ A body part is NOT to be interpreted as actually being an RFC 822 message.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Using a MIME capable mail reader all the time .
  • Using MIME at Maryland 11 January 2010 2:58 UTC www.cs.umd.edu [Source type: Reference]

^ The message header fields that were added to the RFC 822 mail structure are: .
  • MIME Overview 11 January 2010 2:58 UTC www.dart.com [Source type: Reference]

.A simple MIME text message is therefore likely to be interpreted correctly by a non-MIME client although if it has e-mail headers the non-MIME client won't know how to interpret.^ For example, an usual mail with Japanese text has a header like that: .
  • Introduction to i18n - the Internet 11 January 2010 2:58 UTC www.debian.org [Source type: Reference]

^ Represents a collection of all the headers of a mail message or a MIME part.

^ Add header fields to a MIME message.
  • MIME Controls MIME Components - for .Net ASP.Net Java ActiveX Delphi C/C++ 20 September 2009 17:59 UTC www.devdirect.com [Source type: Reference]

.Similarly, if the quoted printable transfer encoding (see below) is used, the ASCII part of the message will be intelligible to users with non-MIME clients.^ (A simple way to do this is to use the quoted-printable encoding.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ (A simple way to do this is to use the quoted- printable encoding.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Eudora uses quoted-printable encoding by default.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

MIME headers

MIME-Version

.The presence of this header indicates the message is MIME-formatted.^ The presence of MIME format structure is indicated by the MIME-Version: tag inserted in the email message.
  • Multipurpose Internet Mail Extensions - Hill2dot0 20 September 2009 17:59 UTC wiki.hill.com [Source type: Reference]

^ Here are the headers used in a MIME message.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ This is a multi-part message in MIME format.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

The value is typically "1.0" so this header appears as
MIME-Version: 1.0
.It should be noted that implementers have attempted to change the version number in the past and the change had unforeseen results.^ It should be noted that the anime version of Mr. Mime always had five fingers.
  • Mr. Mime (Pokémon) - Bulbapedia, the community-driven Pokémon encyclopedia 11 January 2010 2:58 UTC bulbapedia.bulbagarden.net [Source type: FILTERED WITH BAYES]

^ Changes Since S/MIME v3 The RSA public key algorithm was changed to a MUST implement key wrapping algorithm, and the Diffie-Hellman algorithm changed to a SHOULD implement.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

It was decided at an IETF meeting[2] to leave the version number as is even though there have been many updates and versions of MIME.

Content-ID

.The Content-ID header is primarily of use in multi-part messages (as discussed below); a Content-ID is a unique identifier for a message part, allowing it to be referred to (e.g., in IMG tags of an HTML message allowing the inline display of attached images).^ The Content-ID header is primarily of use in multi-part messages (as discussed below); a Content-ID is a unique identifier for a message part, allowing it to be referred to (e.g., in IMG tags of an HTML message allowing the inline display of attached images).
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Some headers discussed in the Other Headers article make use of message IDs.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Content-ID Content-ID headers are world-unique values that identify body parts, individually or as groups.

.The content ID is contained within angle brackets in the Content-ID header.^ The content ID is contained within angle brackets in the Content-ID header.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ When referenced in the form of a Web URI (the term "URL" is being deprecated by the newest proposed Web standards in favor of "URI"), content IDs and message IDs are placed within the URI schemes cid and mid respectively, without the angle brackets: .
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ MIME defines four keys that may appear in the headers: Content-Type: describes the data contained in the body ("the content"); Content-Transfer-Encoding: describes how the content is encoded for transmission in an ASCII stream; Content-Description: a textual description of the content; and, Content-ID: a globally-unique identifier for the content.

Here is an example:
Content-ID: <5.31.32252.1057009685@server01.example.net>
.The standards don't really have a lot to say about exactly what is in a Content-ID; they're only supposed to be globally and permanently unique (meaning that no two are the same, even when generated by different people in different times and places).^ They will each differ by their specific Content-Type.
  • Multipurpose Internet Mail Extensions - Hill2dot0 20 September 2009 17:59 UTC wiki.hill.com [Source type: Reference]

^ The standards don't really have a lot to say about exactly what is in a Content-ID ; they're only supposed to be globally and permanently unique (meaning that no two are the same, even when generated by different people in different times and places).
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Content-Transfer-Encoding Content-Transfer-Encoding headers can have two different meanings.

.To achieve this, some conventions have been adopted; one of them is to include an at sign (@), with the hostname of the computer which created the content ID to the right of it.^ To achieve this, some conventions have been adopted; one of them is to include an at sign, with the hostname of the computer which created the content ID to the right of it.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ This ensures the content ID is different from any created by other computers (well, at least it is when the originating computer has a unique Internet hostname; if, as sometimes happens, an anonymous machine inserts something generic like localhost , uniqueness is no longer guaranteed).
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Content-ID (optional), which enables labeling bodies, thus allowing one body to reference another.
  • MIME - Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC www2.rad.com [Source type: Reference]

.This ensures the content ID is different from any created by other computers (well, at least it is when the originating computer has a unique Internet hostname; if, as sometimes happens, an anonymous machine inserts something generic like localhost, uniqueness is no longer guaranteed).^ After it corrected them, my computer was no longer crashing!

^ A standard Windows interface for messaging that enables different mail programs and other mail-aware applications like word processors and spreadsheets to exchange messages and attachments with each other.
  • Interactive Glossary of Internet Terms: Letter M 11 January 2010 2:58 UTC www.walthowe.com [Source type: Reference]

^ The capabilities must be extremely limited, to ensure that it can represent no more than is likely to be representable by the user's primary word processor.
  • Enriched Text Format -- A Primer 20 September 2009 17:59 UTC users.starpower.net [Source type: FILTERED WITH BAYES]

.Then, the part to the left of the at sign is designed to be unique within that machine; a good way to do this is to append several constantly-changing strings that programs have access to.^ Then, the part to the left of the at sign is designed to be unique within that machine; a good way to do this is to append several constantly-changing strings that programs have access to.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ The prose and BNF describing the multipart media type have been changed to make it clear that the body parts within a multipart object MUST NOT contain any lines beginning with the boundary parameter string.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ As with the PROGRAM/ARGS form, the name of the temporary file that contains the MIME object will be appended to the command line if ` %f ' does not appear in the command line string.
  • Reading MIME Messages 11 January 2010 2:58 UTC w3.pppl.gov [Source type: Reference]

.In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far.^ In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ That's just an example of how a unique content ID can be generated; different programs do it differently.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ The Content-ID header is primarily of use in multi-part messages (as discussed below); a Content-ID is a unique identifier for a message part, allowing it to be referred to (e.g., in IMG tags of an HTML message allowing the inline display of attached images).
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

.Put together, these guarantee that the content ID will never repeat; even if multiple messages are generated within the same second, they either have different process IDs or a different count of messages generated by the same process.^ These are the same content types as in MIME e-mail messages, but they have nothing to do with e-mail.
  • Etresoft: MIME 11 January 2010 2:58 UTC www.etresoft.com [Source type: FILTERED WITH BAYES]

^ They will each differ by their specific Content-Type.
  • Multipurpose Internet Mail Extensions - Hill2dot0 20 September 2009 17:59 UTC wiki.hill.com [Source type: Reference]

^ Related sections can be grouped together, or sections can contain alternative representations of the same data so that clients can choose one that they are able to best display.
  • MT-NW Manual: MIME 11 January 2010 2:58 UTC www.smfr.org [Source type: FILTERED WITH BAYES]

.That's just an example of how a unique content ID can be generated; different programs do it differently.^ That's just an example of how a unique content ID can be generated; different programs do it differently.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ The standards don't really have a lot to say about exactly what is in a Content-ID ; they're only supposed to be globally and permanently unique (meaning that no two are the same, even when generated by different people in different times and places).
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ MIME defines four keys that may appear in the headers: Content-Type: describes the data contained in the body ("the content"); Content-Transfer-Encoding: describes how the content is encoded for transmission in an ASCII stream; Content-Description: a textual description of the content; and, Content-ID: a globally-unique identifier for the content.

.It's only necessary that they remain unique, a requirement that is necessary to ensure that, even if a bunch of different messages are joined together as part of a bigger multi-part message (as happens when a message is forwarded as an attachment, or assembled into a MIME-format digest), you won't have two parts with the same content ID, which would be likely to confuse mail programs greatly.^ Represents a collection of all the headers of a mail message or a MIME part.

^ What would you like to see him mime?” .
  • The Amazing Mime « Improv Everywhere 11 January 2010 2:58 UTC improveverywhere.com [Source type: General]

^ This message contains a text part and an attachment.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

.There's a similar header called Message-ID which assigns a unique identifier to the message as a whole; this is not actually part of the MIME standards, since it can be used on non-MIME as well as MIME messages.^ This is most useful for standard MIME- compliant message forwarding.
  • draft-ietf-openpgp-mime-08 - MIME Security with OpenPGP 11 January 2010 2:58 UTC tools.ietf.org [Source type: Reference]

^ MessageHeaders The headers of the MIME message.
  • IP*Works! MIME Component : MIME OCX, MIME .NET Component, MIME Class, MIME Bean, MIME Object 11 January 2010 2:58 UTC www.nsoftware.com [Source type: Reference]

^ MIME headers appear at the beginning of a MIME message as well as within the separate body parts.

.If the originating mail program doesn't add a message ID, a server handling the message later on probably will, since a number of programs (both clients and servers) want every message to have one in order to keep track of them.^ If the originating mail program doesn't add a message ID, a server handling the message later on probably will, since a number of programs (both clients and servers) want every message to have one in order to keep track of them.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ You could also add "multipart/alternative" to this list to display radio buttons that allow you to choose one of two media types those mails include.
  • Frequently Asked Questions: MIME Commands 11 January 2010 2:58 UTC gnus.org [Source type: FILTERED WITH BAYES]

.Some headers discussed in the Other Headers article make use of message IDs.^ Some headers discussed in the Other Headers article make use of message IDs.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Here are the headers used in a MIME message.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ Some MIME headers can be used both as message headers and in MIME body parts.

When referenced in the form of a Web URI (the term "URL" is being deprecated by the newest proposed Web standards in favor of "URI"), content IDs and message IDs are placed within the URI schemes cid and mid respectively, without the angle brackets:
cid:5.31.32252.1057009685@server01.example.net

Content-Type

This header indicates the Internet media type of the message content, consisting of a type and subtype, for example
Content-Type: text/plain
.Through the use of the multipart type, MIME allows messages to have parts arranged in a tree structure where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of a variety of multipart types.^ MIME allows the use of multiple parts.
  • MIME Overview 11 January 2010 2:58 UTC www.dart.com [Source type: Reference]

^ The "multipart/digest" Content-Type is intended to be used to send collections of messages.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ MIME message tree structure .
  • Email Parser and MIME Parser for VB.Net, C# - Mime4Net component supports RFC822 and MHTML. Automatic emails processing 11 January 2010 2:58 UTC www.mime4.net [Source type: FILTERED WITH BAYES]

This mechanism supports:
.
  • simple text messages using text/plain (the default value for "Content-Type: ")
  • text plus attachments (multipart/mixed with a text/plain part and other non-text parts).^ EnvelopedData Content Type This content type is used to apply data confidentiality to a message.
    • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
    • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

    ^ Such messages have a content type of multipart/alternative.
    • VM User's Manual - Reading MIME Messages 11 January 2010 2:58 UTC www.wonderworks.com [Source type: Reference]

    ^ All text/* types are subclasses of text/plain.

    A MIME message including an attached file generally indicates the file's original name with the "Content-disposition:" header, so the type of file is indicated both by the MIME content-type and the (usually OS-specific) filename extension
  • reply with original attached (multipart/mixed with a text/plain part and the original message as a message/rfc822 part)
  • alternative content, such as a message sent in both plain text and another format such as HTML (multipart/alternative with the same content in text/plain and text/html forms)
  • image, audio, video and application (for example, image/jpg, audio/mp3, video/mp4, and application/msword and so on)
  • many other message constructs

Content-Disposition

.The original MIME specifications only provided a means to associate filenames with application/octet-stream parts.^ MIME Multipurpose Internet Mail Extensions The most common method for transmitting non-text files via Internet e-mail, which was originally designed for only ASCII text.
  • mime Resources | ZDNet 11 January 2010 2:58 UTC updates.zdnet.com [Source type: General]

^ MIME type simply refers to a specific kind of MIME that supports a unique file type or application like images, video or binary executables .

^ Unrecognized subtypes of "audio" should at a miniumum be treated as "application/octet-stream".
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.This was done through the use of a name= parameter on the content-type.^ Use appropriate, registered content-types.
  • Recipient-Friendly MIME generation 11 January 2010 2:58 UTC www.cs.utk.edu [Source type: Original source]

^ Ignore any content type parameters whose names they do not recognize.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ HTTP more frequently uses binary content types than MIME , so it is worth noting that, in such cases, the byte order used to compute the ...
  • MIME - Hypertext Transfer Protocol -- HTTP/1.1 [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

.The theory here was that filenames were mostly used for type information and therefore did not need to be present in most cases.^ HTTP more frequently uses binary content types than MIME , so it is worth noting that, in such cases, the byte order used to compute the ...
  • MIME - Hypertext Transfer Protocol -- HTTP/1.1 [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

^ The information and software presented on this web site are intended for educational use only by sysops and OpenVMS application developers.
  • OpenVMS Notes: MIME, SMTP, POP3 11 January 2010 2:58 UTC www3.sympatico.ca [Source type: Reference]

^ The type given here should normally be used in preference to any guessed type, since the user is able to set it explicitly.

It was a mistake. .The specification of content-disposition attempted to provide a more general means of providing file name information by defining a filename parameter as part of the content-disposition field.^ It provides for determining the types of files from the filename.

^ Headers that begin with "Content-" are the only headers that have defined meaning in body parts.

^ The only header fields that have defined meaning for body parts are those the names of which begin with "Content-".
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

[4]
The following example is taken from RFC 2183, where the header is defined
 Content-Disposition: attachment; filename=genome.jpeg;
         modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
.The filename may be encoded as defined by RFC 2231.^ This encoding is virtually identical to the one used in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421 .
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The "multipart" MIME type defined in RFC 2046 draft [ 11 ] MAY be used within ...
  • MIME - SIP: Session Initiation Protocol [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

.Besides attachment, one can specify inline, or any other disposition type.^ Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ This is specified with a "charset" parameter, as in: Content-type: text/plain; charset=us-ascii Unlike some other parameter values, the values of the charset parameter are NOT case sensitive.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ When you derive a message class (and agents) to handle other content types, begin your new codes with this one.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

.Unfortunately, no name is defined for the nominal "default" disposition that corresponds to no content-disposition being present.^ When a body part is to be treated as an attached file, the Content-Disposition header will include a file name attribute.

^ The file suffix in the table below comes from the "name" parameter in the content-type header, or the "filename" parameter on the content- disposition header.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ With no argument, returns the filename as dictated by the content-disposition.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

.Thus the recommended practice for generating agents is to only include filename information when it is necessary, also to avoid leaking sensitive information.^ Thus a Content-Transfer-Encoding is not generally necessary, though it is permitted.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ It's generally a good idea to encode lines that begin with From=20because some mail transport agents will insert a greater- than (> ) sign, thus invalidating the signature.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

.If filename information has to be included, an agent should either put it in a filename= parameter or both a filename= and name= parameter.^ Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Unless the name contains a special character, the double quotes should not be included.
  • Recipient-Friendly MIME generation 11 January 2010 2:58 UTC www.cs.utk.edu [Source type: Original source]

^ Offer the ability to remove either of the quoted- printable or base64 encodings defined in this document if they were used and put the resulting information in a user file.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

.Never ever use just a name= parameter because that opens up to gratuitous interpretation of the part using an unintended disposition value.^ "I don't like to use the word 'educate,' because it's presumptuous, but I'd like to have people who've never experienced mime discover this art."

^ The chosen charset SHOULD be named in the charset parameter so that the receiving agent can unambiguously determine the charset used.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Parameters can be appended, separated by a semicolon from the main value; the most common parameter is filename , which allows you to suggest what name the file should be saved as.
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

[4]

Content-Transfer-Encoding

.In June 1992, MIME (RFC 1341, since made obsolete by RFC 2045) defined a set of methods for representing binary data in ASCII text format.^ MIME was first defined and published as RFCs 1341 and 1342 [ RFC-1341 ] [ RFC-1342 ].
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ A format for representing tabular data.
  • Software Carpentry:Glossary (Version 1121) 20 September 2009 17:59 UTC swc.scipy.org [Source type: Reference]

^ An additional parameter, "CONVERSIONS", was defined in RFC 1341 but has since been removed.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

The content-transfer-encoding: MIME header has 2-sided significance:
  1. It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header, and
  2. If such a binary-to-text encoding method has been used it states which one.
.The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive.^ Location of Registered Transfer Encodings List The list of transfer encoding registrations can be found at: http://www.iana.org/assignments/transfer-encodings 4 .
  • RFC 4289 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Transfer codings are analogous to the Content-Transfer-Encoding values of MIME , which were designed to enable safe transport of binary data ...
  • MIME - Hypertext Transfer Protocol -- HTTP/1.1 [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

^ Certain Content-Transfer-Encoding values may only be used on certain Content-Types.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Note that '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used.^ It should be noted that the 7bit and 8bit encodings do not conform to this requirement.
  • RFC 4289 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ When using compression, keep the following guidelines in mind: - Compression of binary encoded encrypted data is discouraged, since it will not yield significant compression.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Note that there is no fixed relationship between the content type and the transfer encoding.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.In these cases, the header is actually redundant for the email client to decode the message body, but it may still be useful as an indicator of what type of object is being sent.^ Thus, previously cached copies may still be used by a client or proxy, with the previous headers.
  • Apache module mod_mime 11 January 2010 2:58 UTC goforit.unk.edu [Source type: Reference]

^ This header defines what type of data is being sent, using what is known as "MIME types".
  • Dan's Mail Format Site | Headers | MIME 11 January 2010 2:58 UTC mailformat.dan.info [Source type: FILTERED WITH BAYES]

^ A body part is NOT to be interpreted as actually being an RFC 822 message.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Values 'quoted-printable' and 'base64' tell the email client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e.g.^ (A simple way to do this is to use the quoted-printable encoding.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Use of encoded-words in message headers .
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ The component may be used for decoding or encoding of messages.
  • IP*Works! MIME Component : MIME OCX, MIME .NET Component, MIME Class, MIME Bean, MIME Object 11 January 2010 2:58 UTC www.nsoftware.com [Source type: Reference]

UTF-8).
.
  • Suitable for use with normal SMTP:
    • 7bit – up to 998 octets per line of the code range 1..127 with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending.^ Use of CR and LF outside of line break sequences is also forbidden.
      • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

      ^ The definitions of "7bit" and "8bit" have been tightened so that use of bare CR, LF can only be used as end-of-line sequences.
      • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

      ^ Note in particular that the use of an input element forces the brower to use ENCTYPE ="multipart/form-data", since this is the only mechanism that can encode a file and send it as a part of the FORM .

      .This is the default value.
    • quoted-printable – used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit.^ Eudora uses quoted-printable encoding by default.
      • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

      ^ For example, Microsoft Exchange's SMTP component incorrectly uses quoted-printable encoding in an attempt to control message formatting.
      • comp.mail.mime meta-FAQ: Help for MIME problems 11 January 2010 2:58 UTC www.faqs.org [Source type: FILTERED WITH BAYES]

      ^ (A simple way to do this is to use the quoted-printable encoding.
      • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

      .Designed to be efficient and mostly human readable when used for text data consisting primarily of US-ASCII characters but also containing a small proportion of bytes with values outside that range.
    • base64 – used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit.^ Base64 Content-Transfer-Encoding The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.
      • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

      ^ Any characters outside of the base64 alphabet are to be ignored in base64-encoded data.
      • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

      ^ (US-ASCII decimal value 63) .
      • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

      .Designed to be efficient for non-text 8 bit data.^ Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.
      • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
      • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

      ^ Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters.
      • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
      • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

      ^ The third document, RFC 2047, describes extensions to RFC 822 to allow non-US- ASCII text data in Internet mail header fields.
      • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

      Sometimes used for text data that frequently uses non-US-ASCII characters.
  • Suitable for use with SMTP servers that support the 8BITMIME SMTP extension:
    • 8bit – up to 998 octets per line with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending.
  • Suitable only for use with SMTP servers that support the BINARYMIME SMTP extension (RFC 3030):
    • binary – any sequence of octets.
.There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension.^ Binary data: Arbitrary data.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

^ So there is no data loss here.
  • Ade Famoti's Unified Communications Blog 11 January 2010 2:58 UTC blogs.msdn.com [Source type: Academic]

^ When using compression, keep the following guidelines in mind: - Compression of binary encoded encrypted data is discouraged, since it will not yield significant compression.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

.Thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used.^ These have not yet been adopted, largely because it seems likely that common sense will suffice to encourage people to use, for example, base64 rather than quoted-printable when transmitting audio data.
  • MIME - Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC www2.rad.com [Source type: Reference]

^ (A simple way to do this is to use the quoted-printable encoding.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Therefore, when decoding a Quoted-Printable body, any trailing white space on a line must be deleted, as it will necessarily have been added by intermediate transport agents.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM

Encoded-Word

.Since RFC 2822, message header names and values are always ASCII characters; values that contain non-ASCII data must use the MIME encoded-word syntax (RFC 2047) instead of a literal string.^ MIME-enc is the MIME encoding to use for documents containing the extension .
  • Apache module mod_mime 11 January 2010 2:58 UTC goforit.unk.edu [Source type: Reference]

^ MIME charset name for that encoding (or "" if the charset name is unknown).

^ [FILEHANDLE] Get/set the FILEHANDLE which contains the message data.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

.This syntax uses a string of ASCII characters indicating both the original character encoding (the "charset") and the content-transfer-encoding used to map the bytes of the charset into ASCII characters.^ The Content-Transfer-Encoding header field indicates the mechanism used to perform such an encoding.
  • MIME - Multipurpose Internet Mail Extensions 11 January 2010 2:58 UTC www2.rad.com [Source type: Reference]

^ Use of 'encoded-word's to represent strings of purely ASCII characters is allowed, but discouraged.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Content transfer encodings .
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

The form is: "=?charset?encoding ?encoded text?=".
.
  • charset may be any character set registered with IANA.^ The MIME charset name for this character set is "US-ASCII".
    • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

    ^ Conversion to the proper canonical form may involve character set conversion, transformation of audio data, compression, or various other operations specific to the various media types.
    • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

    ^ If character set conversion is involved, however, care must be taken to understand the semantics of the content-type, which may have strong implications for any character set conversion, e.g.
    • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

    Typically it would be the same charset as the message body.
  • encoding can be either "Q" denoting Q-encoding that is similar to the quoted-printable encoding, or "B" denoting base64 encoding.
  • encoded text is the Q-encoded or base64-encoded text.

Difference between Q-encoding and quoted-printable

.The ASCII codes for the question mark (?) and equals sign may not be represented directly as they are used to delimit the encoded-word.^ Use of encoded-words in message headers .
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Use of encoded-words in message headers 7.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Use of 'encoded-word's to represent strings of purely ASCII characters is allowed, but discouraged.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

.The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably.^ Warning: the CRLF+SPACE separator that splits up long encoded words into shorter sequences (see the Subject: example above) gets lost when the field is unfolded, and so decoding after unfolding causes a spurious space to be left in the field.
  • Man page of MIME::Head 11 January 2010 2:58 UTC www.cs.potsdam.edu [Source type: FILTERED WITH BAYES]

^ ISO-8859-1?Q?a_b?=) (a b) In order to cause a SPACE to be displayed within a portion of encoded text, the SPACE MUST be encoded as part of the 'encoded-word'.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Within a 'comment', any sequence of up to 75 printable characters (not containing 'linear-white-space'), that meets the syntax rules in section 2, should be treated as an 'encoded-word'.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

.To make the encoding smaller and easier to read the underscore is used to represent the ASCII code for space creating the side effect that underscore cannot be represented directly.^ To make this long story short, you should always use x-gzip and x-compress for these two specific encodings.
  • Apache module mod_mime 11 January 2010 2:58 UTC goforit.unk.edu [Source type: Reference]

^ Some character sets use code-switching techniques to switch between "ASCII mode" and other modes.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ If Quoted-Printable is used, at least one of the characters in the string should be encoded using the hexadecimal coding rule.
  • draft-ietf-openpgp-mime-08 - MIME Security with OpenPGP 11 January 2010 2:58 UTC tools.ietf.org [Source type: Reference]

.Use of encoded words in certain parts of headers imposes further restrictions on which characters may be represented directly.^ Recognition of 'encoded-word's in message headers .
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Each 'encoded-word' MUST represent an integral number of characters.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Use of encoded-words in message headers .
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

For example,
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=
is interpreted as "Subject: ¡Hola, señor!".
.The encoded-word format is not used for the names of the headers (for example Subject).^ Used as an encoding scheme for the Format element in Dublin Core.
  • Dublin Core User's Guide Glossary 20 September 2009 17:59 UTC library.csun.edu [Source type: Reference]

^ A Content-Type header field, generalized from RFC 1049 [ RFC-1049 ], which can be used to specify the type and subtype of data in the body of a message and to fully specify the native representation (encoding) of such data.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The Content-Transfer-Encoding header identifies the mechanism a decoder should use in order to convert the message body back into its original form.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

.These header names are always in English in the raw message.^ The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ This name appears in the access-type parameter in the message/external-body content-type header field and MUST conform to MIME content type parameter syntax.
  • RFC 4289 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Always generate a "MIME-Version: 1.0" header field in any message it creates.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

.When viewing a message with a non-English e-mail client, the header names are usually translated by the client.^ Note: the name comes from Mail::Header.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ A message, usually another mail or MIME message.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ MIME is an e-mail message protocol (described in RFCs 1521 and 1522) that allows messages to incorporate non-text content while still remaining compliant with RFC 822.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

Multipart messages

A MIME multipart message contains a boundary in the "Content-Type: " header; this boundary, which must not occur in any of the parts, is placed between the parts, and at the beginning and end of the body of the message, as follows:
.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"

This is a message with multiple parts in MIME format.^ Such messages have a content type of multipart/alternative.
  • VM User's Manual - Reading MIME Messages 11 January 2010 2:58 UTC www.wonderworks.com [Source type: Reference]

^ MIME allows a message to be sent with its content encoded in multiple formats, simultaneously, in the same message.
  • VM User's Manual - Reading MIME Messages 11 January 2010 2:58 UTC www.wonderworks.com [Source type: Reference]

^ Note that "message/sip" bodies can be sent as a part of a MIME " multipart/mixed " body if any unsecured MIME types ...
  • MIME - SIP: Session Initiation Protocol [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

--frontier .Content-Type: text/plain This is the body of the message.^ Content-Type: specifies type of data contained in the body of message.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

^ The message content-type is for including a complete email message within the body.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

^ Content-type: text/richtext This is richtext.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

--frontier Content-Type: application/octet-stream Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--
.Each part consists of its own content header (zero or more Content- header fields) and a body.^ All other header fields may be ignored in body parts.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ All other header fields are generally to be ignored in body parts.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ If a Content-Transfer-Encoding header field appears as part of a body part's headers, it applies only to the body of that body part.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

Multipart content can be nested. .The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding.^ Similarly, any Content-transfer-encoding other than "7bit" must also be declared here.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ If the body contains binary data, the "binary" Content-Transfer-Encoding token must be used.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ A higher level of confidence is offered by the base64 Content-Transfer-Encoding.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.^ The encoded body is inserted into a MIME entity with appropriate headers.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ How do content-type headers work?

^ The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

Notes:
.
  • Before the first boundary is an area that is ignored by MIME compliant clients.^ I think we can probably solve the first issue by creating (on the client side) a mime-type associated with an extension.
    • RSS and MIME types - Greg Reinacker’s Weblog - Musings on just about everything. 11 January 2010 2:58 UTC www.rassoc.com [Source type: General]

    ^ These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one.
    • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

    ^ Data before the first or after the last 00388 // boundary delimiter are ignored 00389 current_child_entity -> Deliver (len, data, trailing_CRLF); 00390 } 00391 else 00392 { 00393 if ( mime_decode_data ) 00394 DecodeDataLine (len, data, trailing_CRLF); 00395 } 00396 } .
    • bro_docs.8a82: MIME_Entity class Reference 11 January 2010 2:58 UTC www.nersc.gov [Source type: Reference]

    .This area is generally used to put a message to users of old non-MIME clients.
  • It is up to the sending mail client to choose a boundary string that doesn't clash with the body text.^ The email program can be used to extract the appropriate component of the multipart message attachment (in this example separated by the unique string 1320854989), decoding it if necessary from the base-64 scheme adopted to ensure 7-bit transparency of the file, and to save the file to the user's filebase in a segregated area identified for such attachments.
    • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

    ^ MyBoundaryString-- Text before the first boundary and after the end-of-message boundary is ignored by decoders, but since a non-MIME reader will simply display the whole thing as text, these areas can be used to tell the user to get a better mail reader.
    • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

    ^ MIME is an e-mail message protocol (described in RFCs 1521 and 1522) that allows messages to incorporate non-text content while still remaining compliant with RFC 822.
    • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

    Typically this is done by inserting a long random string.
  • The last boundary must have two hyphens at the end.

Multipart subtypes

.The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another.^ The multipart/related content type denotes a message containing parts that are related one to another.

^ (For the special case in which parts actually are messages, a "digest" subtype is also defined.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ The parts of a multipart message are not top-level.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

.The subtype is specified in the "Content-Type" header of the overall message.^ How do content-type headers work?

^ Content-Type: specifies type of data contained in the body of message.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

^ The boundary string is specified as a parameter to the Content-Type header: .
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

For example, a multipart MIME message using the digest subtype would have its Content-Type set as "multipart/digest".
.The RFC initially defined 4 subtypes: mixed, digest, alternative and parallel.^ An initial subtype "mpeg" is defined in this document.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ An initial subtype "basic" is defined in this document.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Content-type: multipart Subtypes defined by this document: mixed, alternative, digest, parallel.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.A minimally compliant application must support mixed and digest; other subtypes are optional.^ Other Message Subtypes MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream".
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ If this approach is used, other implementations will not recognize the new subtype, but will treat it as the primary subtype (multipart/mixed) and will thus be able to show the user the parts that are recognized.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Other Application subtypes It is expected that many other subtypes of application will be defined in the future.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.^ An additional parameter, "CONVERSIONS", was defined in RFC 1341 but has since been removed.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Fundamentally, the data is created in the "native" form specified by the type/subtype information.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Two additional parameters are defined for this access type: (1) NAME -- The name of the file that contains the actual body data.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.The following is a list of the most commonly used subtypes; it is not intended to be a comprehensive list.^ Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Mixed Subtype The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ The Multipart/mixed (primary) subtype The primary subtype for multipart, "mixed", is intended for use when the body parts are independent and need to be bundled in a particular order.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

Mixed

.Multipart/mixed is used for sending files with different "Content-Type" headers inline (or as attachments).^ The "multipart/digest" Content-Type is intended to be used to send collections of messages.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ This type is syntactically identical to multipart/mixed, but the semantics are different.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ This type is syntactically identical to "multipart/mixed", but the semantics are different.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.If sending pictures or other easily readable files, most mail clients will display them inline (unless otherwise specified with the "Content-disposition" header).^ If most of your content is binary, such as applications # or images, you may want to use "application/octet-stream" instead to # keep browsers from trying to display binary files as though they are # text.
  • Help With Apache Virtual Host Configuration - Spiceworks Community 11 January 2010 2:58 UTC community.spiceworks.com [Source type: FILTERED WITH BAYES]

^ MPACK/MUNPACK. To send a MIME mail, construct the message with attachments manually using MPACK. You cannot send the resulting file directly through MAIL because an extra blank header line will be inserted between your message and the OpenVMS MAIL headers, which will cause the message to appear as plain text in most mail programs .
  • OpenVMS Notes: MIME, SMTP, POP3 11 January 2010 2:58 UTC www3.sympatico.ca [Source type: Reference]

^ Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

Otherwise it will offer them as attachments. The default content-type for each part is "text/plain".

Message

.A message/rfc822 part contains an email message, including any headers.^ This message contains a text part and an attachment.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Thus the headers on the outer and inner parts must be merged using the same rules as for message/partial.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ However, forwarded and rejected messages can be handled as multipart messages in which the first part contains any control or descriptive information, and a second part, of type "message/ rfc822 ", is the forwarded or rejected message.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.Rfc822 is a misnomer, since the message may be a full MIME message.^ In other words, a message/rfc822 message may be a MIME message.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Since it is possible that a future document might extend the message format standard again, a formal BNF is given for the content of the MIME-Version field: version := "MIME-Version" ":" 1*DIGIT "."
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ More specifically, a "message/ rfc822 " message could well be a News article or a MIME message.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

This is used for digests as well as for E-mail forwarding.
.Defined in RFC 2046.^ RFC 2046, which defines the general structure of the MIME media typing system and defines an initial set of media types, .
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ The "multipart" MIME type defined in RFC 2046 draft [ 11 ] MAY be used within ...
  • MIME - SIP: Session Initiation Protocol [RFC-Ref] 11 January 2010 2:58 UTC rfc-ref.org [Source type: Reference]

Digest

.Multipart/digest is a simple way to send multiple text messages.^ If multiple message digest algorithms are used they MUST be separated by commas per [MIME- SECURE].
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ The message was sent out as multipart/alternative format (that means > as both text and html ...
  • GMail and S/MIME - Thunderbird Webmail Extension | Google Groups 11 January 2010 2:58 UTC groups.google.com [Source type: FILTERED WITH BAYES]

The default content-type for each part is "message/rfc822".

Alternative

.The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header.^ The Multipart/digest subtype This document defines a "digest" subtype of the multipart Content- Type.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Digest Subtype This document defines a "digest" subtype of the "multipart" Content- Type.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ The Multipart/parallel subtype This document defines a "parallel" subtype of the multipart Content- Type.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.The formats are ordered by how faithful they are to the original, with the least faithful first and the most faithful last.^ For fancy text, the sending user agent should put the plainest format first and the richest format last.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ When encoding a bit stream via the base64 encoding, the bit stream must be presumed to be ordered with the most-significant-bit first.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ In general, user agents that compose "multipart/alternative" entities must place the body parts in increasing order of preference, that is, with the preferred format last.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.^ Implementations may optionally elect to pass subtypes of "image" that they do not specifically recognize to a secure and robust general-purpose image viewing application, if such an application is available.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Although most parameters make sense only with certain content-types, others are "global" in the sense that they might apply to any subtype.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ RemoveType directives are processed after any AddType directives, so it is possible they may undo the effects of the latter if both occur within the same directory configuration.

.Since a client is unlikely to want to send a version that is less faithful than the plain text version this structure places the plain text version (if present) first.^ Unlike mailing lists , blogs use a publish-subscribe model: readers pull content when they want it, rather than having it sent to them.
  • Software Carpentry:Glossary (Version 1121) 20 September 2009 17:59 UTC swc.scipy.org [Source type: Reference]

^ This is specified with a "charset" parameter, as in: Content-type: text/plain; charset=us-ascii Unlike some other parameter values, the values of the charset parameter are NOT case sensitive.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The first body part of the sample MIME message is a standard email message; like all standard email messages, its content-type is: Content-Type: TEXT/plain; charset=US-ASCII This is the default MIME content-type.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

.This makes life easier for users of clients that do not understand multipart messages.^ Users can easily understand why calling their text file README.mp3 makes the system think it's an MP3, whereas they have trouble understanding why their computer thinks README.txt is a PostScript file.

^ If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ It’s a purely client-side thing… the user clicks a feed: link, it is captured by an aggregator, and then the aggregator goes from there, making calls via http: or whatever.
  • RSS and MIME types - Greg Reinacker’s Weblog - Musings on just about everything. 11 January 2010 2:58 UTC www.rassoc.com [Source type: General]

.Most commonly multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html).^ These examples should also serve as prototypes for setting up other commonly used email handling systems that support MIME. Example 1.
  • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

^ NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ An overview of how MIME can be applied to the transport of specific chemical data types using the two principle Internet mechanisms of email and the WWW is illustrated in Scheme 1 .
  • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

.The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks.^ NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ HTML text files contain content that is rendered on a computer screen and markup, or tags, that can be used to tell the computer how to format that content.
  • Dublin Core User's Guide Glossary 20 September 2009 17:59 UTC library.csun.edu [Source type: Reference]

^ Such formatted textual data should be represented using subtypes of "text".
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.^ This message contains a text part and an attachment.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Outlook supports text/html , so it can display HTML messages to the user directly.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

^ For example, in the case of text/plain data, the text must be converted to a supported character set and lines must be delimited with CRLF delimiters in accordance with RFC822 .
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way.^ When message-parts are added to the message, this same code is used.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

^ Since it is possible that a future document might extend the message format standard again, a formal BNF is given for the content of the MIME-Version field: version := "MIME-Version" ":" 1*DIGIT "."
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ If a Content-Transfer-Encoding header field appears as part of a message header, it applies to the entire body of that message.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.At one time, anti-spam filters would only examine the text/plain part of a message, because it is easier to parse than the text/html part.^ This message contains a text part and an attachment.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ The default behavior is that any content type other than text/* or message/* is binmode'd; this should in general work fine.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ Email Not HTML Email Not HTML is the only email security content-filtering program, that copes with the threats of HTML and MIME-based emails.It prevents viruses and other malicious code from being executedautomatically on message open or preview.
  • Mime Software - Chilkat S/MIME Encryption ActiveX Component, Chilkat Java MIME Library, Chilkat Perl MIME Library, Chilkat Python MIME Library 11 January 2010 2:58 UTC finaldownload.com [Source type: General]

.But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part.^ This message contains a text part and an attachment.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ The message was sent out as multipart/alternative format (that means > as both text and html ...
  • GMail and S/MIME - Thunderbird Webmail Extension | Google Groups 11 January 2010 2:58 UTC groups.google.com [Source type: FILTERED WITH BAYES]

^ For example, a downloader should not pass a file directly to a launcher application without confirmation simply because the type looks `harmless' (eg, text/plain).

.Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.^ The handling of the combination of multipart/alternative and message/external-body is now specifically addressed.
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ If a "text/plain" part is needed, it should be included as a seperate part of a "multipart/mixed" message.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

Related

.A multipart/related is used to indicate that message parts should not be considered individually but rather as parts of an aggregate whole.^ The parts of a multipart message are not top-level.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ When message-parts are added to the message, this same code is used.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

.The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts.^ However, forwarded and rejected messages can be handled as multipart messages in which the first part contains any control or descriptive information, and a second part, of type "message/ rfc822 ", is the forwarded or rejected message.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ S/MIME uses other than interpersonal messaging MAY require the explicit presence of the extended key usage extension or other OIDs to be present in the extension or both.
  • RFC 3850 (rfc3850) - Secure/Multipurpose Internet Mail Extensions (S/MIME) 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ If an external body is accessible via multiple mechanisms, the sender may include multiple parts of type message/external-body within an entity of type multipart/alternative.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Message parts are commonly referenced by the "Content-ID" part header.^ The top-level content-type of a MIME message with multiple body parts is "multipart", and the content-type header line includes the "boundary-string" parameter, which defines the string that separates the different parts of the message body.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

^ The Content-Transfer-Encoding header identifies the mechanism a decoder should use in order to convert the message body back into its original form.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

^ If a Content-Transfer-Encoding header field appears as part of a message header, it applies to the entire body of that message.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.^ It is possible that an 'encoded-word' that is legal according to the syntax defined in section 2, is incorrectly formed according to the rules for the encoding being used.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Instead, the ftp protocol will be used with login "anonymous" and a password that corresponds to the user's email address.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The term "character set" is used in this document to refer to a method used with one or more tables to convert encoded text to a series of octets.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.One common usage of this subtype is to send a web page complete with images in a single message.^ The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the Ramsdell Standards Track [Page 12] .
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

^ If the message has already been altered to display on the web page, then there's nothing the extension can do to prevent the signature failing.
  • GMail and S/MIME - Thunderbird Webmail Extension | Google Groups 11 January 2010 2:58 UTC groups.google.com [Source type: FILTERED WITH BAYES]

.The root part would contain the HTML document, and use image tags to reference images stored in the latter parts.^ HTML text files contain content that is rendered on a computer screen and markup, or tags, that can be used to tell the computer how to format that content.
  • Dublin Core User's Guide Glossary 20 September 2009 17:59 UTC library.csun.edu [Source type: Reference]

^ The term "character set" is used in this document to refer to a method used with one or more tables to convert encoded text to a series of octets.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Tags come in matched opening and closing pairs, such as and ; if the element the tag pair represents does not contain text or other elements, the short form may be used.
  • Software Carpentry:Glossary (Version 1121) 20 September 2009 17:59 UTC swc.scipy.org [Source type: Reference]

Defined in RFC 2387

Report

.Multipart/report is a message type that contains data formatted for a mail server to read.^ Let the message object pump its own data to the mail server.
  • E-Mail File Attachments Using MIME — CodeGuru.com 11 January 2010 2:58 UTC www.codeguru.com [Source type: FILTERED WITH BAYES]

^ [FILEHANDLE] Get/set the FILEHANDLE which contains the message data.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

^ Filehandle containing the data, opened for reading.
  • MIME::Lite - low-calorie MIME generator 11 January 2010 2:58 UTC www.xav.com [Source type: FILTERED WITH BAYES]

.It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for the mail server to read.^ EnvelopedData Content Type This content type is used to apply data confidentiality to a message.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Some types may or may not be instances of other types.

^ The Audio Content-Type A Content-Type of "audio" indicates that the body contains audio data.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

Defined in RFC 3462

Signed

.A multipart/signed message is used to attach a digital signature to a message.^ Signing Using the multipart/signed Format This format is a clear-signing format.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Creating a multipart/signed Message Step 1.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

.It has two parts, a body part and a signature part.^ Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ This string, preceded by two dashes, is placed in the message body before each part of the message.
  • Making Email Talk with MIME 11 January 2010 2:58 UTC www.uic.edu [Source type: FILTERED WITH BAYES]

^ This means that if the body of the "message/external-body" message contains two consecutive CRLFs, everything after those pairs is NOT part of the message itself.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.The whole of the body part, including mime headers, is used to create the signature part.^ RFC822 headers and MIME body part headers, but NOT as parameter values.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ Thus the headers on the outer and inner parts must be merged using the same rules as for message/partial.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ Such alterations are explicitly forbidden for the body part headers embedded in the bodies of messages of type "multipart."
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.Many signature types are possible, like application/pgp-signature (RFC 3156) and application/x-pkcs7-signature (S/MIME).^ The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- Ramsdell Standards Track [Page 25] .
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

^ MIME type: application/pkcs7-mime parameters: any file suffix: any MIME type: multipart/signed parameters: protocol="application/pkcs7-signature" file suffix: any MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z Ramsdell Standards Track [Page 28] .
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

Encrypted

.A multipart/encrypted message has two parts.^ However, forwarded and rejected messages can be handled as multipart messages in which the first part contains any control or descriptive information, and a second part, of type "message/ rfc822 ", is the forwarded or rejected message.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Such alterations are explicitly forbidden for the body part headers embedded in the bodies of messages of type "multipart."
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ If an external body is accessible via multiple mechanisms, the sender may include multiple parts of type message/external-body within an entity of type multipart/alternative.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.The first part has control information that is needed to decrypt the application/octet-stream second part.^ Unrecognized subtypes of "audio" should at a miniumum be treated as "application/octet-stream".
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ The primary subtype, "octet-stream", is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

.Similar to signed messages, there are different implementations which are identified by their separate content types for the control part.^ EnvelopedData Content Type This content type is used to apply data confidentiality to a message.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ Note that there is no fixed relationship between the content type and the transfer encoding.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The MIME protocol also defines a secondary media type header which allows the definition of more specific information on the expected content of a message attachment.
  • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

.The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME).^ MIME type: application/pkcs7-mime parameters: any file suffix: any MIME type: multipart/signed parameters: protocol="application/pkcs7-signature" file suffix: any MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c, p7z Ramsdell Standards Track [Page 28] .
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

^ Security Considerations Security issues are discussed in the context of the "application/postscript" type, the "message/external-body" type, and in RFC 2048 .
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Common types (such as MS Word Documents) will be provided in the X Desktop Group's package, which MUST be required by all applications using this specification.

Form Data

.As its name implies, multipart/form-data is used to express values submitted through a form.^ However, it is conceivable that non-textual data might also wish to specify a charset value for some purpose, in which case the same syntax and values should be used.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

.Originally defined as part of HTML 4.0, it is most commonly used for submitting files via HTTP.^ RFC 1341 also defined the use of a "NAME" parameter which gave a suggested file name to be used if the data were to be written to a file.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ P3   If defined, use second mode (via port 25) instead of TCPWARE mode.
  • OpenVMS Notes: MIME, SMTP, POP3 11 January 2010 2:58 UTC www3.sympatico.ca [Source type: Reference]

^ HTML text files contain content that is rendered on a computer screen and markup, or tags, that can be used to tell the computer how to format that content.
  • Dublin Core User's Guide Glossary 20 September 2009 17:59 UTC library.csun.edu [Source type: Reference]

Defined in RFC 2388

Mixed-Replace (Experimental)

The content type multipart/x-mixed-replace was developed as part of a technology to emulate server push and streaming over HTTP.
.All parts of a mixed-replace message have the same semantic meaning.^ Thus the headers on the outer and inner parts must be merged using the same rules as for message/partial.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ 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.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ An 'encoded-word' may replace a 'text' token (as defined by RFC 822) in any Subject or Comments header field, any extension message header field, or any MIME body part field for which the field body is defined as '*text'.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

However, each part invalidates - "replaces" - the previous parts as soon as it is received completely. .Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.^ Message receiving and displaying software should not allow such operators to be used if they exist.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ However, it is recommended that the Content-ID values used by the parts should not be the same Content-ID value that describes the multipart/alternative as a whole, if there is any such Content-ID field.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

^ The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used.
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

Originally developed by Netscape, it is still supported by Mozilla, Firefox, Safari (but not in Safari on the iPhone) and Opera, but traditionally ignored by Microsoft. .It is commonly used in IP cameras as the MIME type for MJPEG streams.^ MIME types for local use.
  • Rzepa, Murray-Rust and Whitaker: The Application of Chemical MIME 20 September 2009 17:59 UTC www.ch.ic.ac.uk [Source type: Reference]

^ Of these, only the Data, SignedData, EnvelopedData, and CompressedData content types are currently used for S/MIME. 2.4.1 .
  • draft-ietf-smime-3851bis-01 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification 20 September 2009 17:59 UTC tools.ietf.org [Source type: Reference]

^ It makes use of the multipart/signed MIME type described in [MIME-SECURE].
  • RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. 20 September 2009 17:59 UTC rfc.sunsite.dk [Source type: Reference]

Byteranges

.The multipart/byteranges is used to represent noncontiguous byte ranges of a single message.^ NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types.
  • RFC 2046 - (rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 20 September 2009 17:59 UTC www.rfcsearch.org [Source type: Reference]

^ Most programming languages use 32 bits to represent integers, which permits values in the range -2 31 …2 31 -1 (or -2147483648 to 2147483647).
  • Software Carpentry:Glossary (Version 1121) 20 September 2009 17:59 UTC swc.scipy.org [Source type: Reference]

^ Such compound types should be represented using the "multipart" or "application" types.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

.It is used by HTTP when a server returns multiple byte ranges and is defined in RFC 2068.^ In particular, the syntax for the ABNF used in this memo is defined in RFC 822, as well as many of the terminal or nonterminal symbols from RFC 822 are used in the grammar for the header extensions defined here.
  • MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text 20 September 2009 17:59 UTC xml.resource.org [Source type: Reference]

^ (Status: INFORMATIONAL) Date: October 1996 Go to: http://www.xyweb.com/rfc/rfc2036.html RFC 2037 Entity MIB using SMIv2.
  • The Online Request For Comments - RFCs 20 September 2009 17:59 UTC www.xyweb.com [Source type: Academic]

^ (Status: INFORMATIONAL) Date: October 1996 Go to: http://www.xyweb.com/rfc/rfc2054.html RFC 2055 WebNFS Server Specification.
  • The Online Request For Comments - RFCs 20 September 2009 17:59 UTC www.xyweb.com [Source type: Academic]

See also

References

  1. ^ Promises, Promises - By Dan Backman - Network Computing
  2. ^ "Proceedings for the Twenty-sixth IETF" (pdf). 1993. pp. 65-66. http://www.ietf.org/proceedings/26.pdf. Retrieved 2009-12-29.  
  3. ^ Daniel R. Tobias (2007-01-21). "Dan's Mail Format Site - Headers - MIME". http://mailformat.dan.info/headers/mime.html. Retrieved 2009-10-14.  
  4. ^ a b Ned Freed (2008-06-21). "name and filename parameters". http://www.imc.org/ietf-smtp/mail-archive/msg05023.html. Retrieved 2008-06-23.  
Notes
RFC 1426 
SMTP Service Extension for 8bit-MIMEtransport. .J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.^ RFC-1426 ] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME transport", RFC 1426 , United Nations Universit, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
  • RFC 1521 (rfc1521) - MIME (Multipurpose Internet Mail Extensions) Part One 20 September 2009 17:59 UTC www.faqs.org [Source type: Reference]

February 1993.
RFC 1847 
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 3156 
MIME Security with OpenPGP
RFC 2045 
MIME Part One: Format of Internet Message Bodies.
RFC 2046 
MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
RFC 2047 
MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
RFC 4288 
MIME Part Four: Media Type Specifications and Registration Procedures.
RFC 4289 
MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049 
MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2183 
Communicating Presentation Information in Internet Messages: The Content-Disposition Header. Troost, R., Dorner, S. and K. Moore. August 1997.
RFC 2231 
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387 
The MIME Multipart/Related Content-type
RFC 1521 
Mechanisms for Specifying and Describing the Format of Internet Message Bodies

External links


Internet Protocol Suite
Application Layer

BGP

  1. REDIRECT template:· DHCP
  2. REDIRECT template:· DNS
  3. REDIRECT template:· FTP
  4. REDIRECT template:· HTTP
  5. REDIRECT template:· IMAP
  6. REDIRECT template:· IRC
  7. REDIRECT template:· LDAP
  8. REDIRECT template:· MGCP
  9. REDIRECT template:· NNTP
  10. REDIRECT template:· NTP
  11. REDIRECT template:· POP
  12. REDIRECT template:· RIP
  13. REDIRECT template:· RPC
  14. REDIRECT template:· RTP
  15. REDIRECT template:· SIP
  16. REDIRECT template:· SMTP
  17. REDIRECT template:· SNMP
  18. REDIRECT template:· SSH
  19. REDIRECT template:· Telnet
  20. REDIRECT template:· TLS/SSL
  21. REDIRECT template:· XMPPTemplate:·
(more)
Transport Layer

TCP

  1. REDIRECT template:· UDP
  2. REDIRECT template:· DCCP
  3. REDIRECT template:· SCTP
  4. REDIRECT template:· RSVP
  5. REDIRECT template:· ECNTemplate:·
(more)
Internet Layer

IP (IPv4, IPv6)

  1. REDIRECT template:· ICMP
  2. REDIRECT template:· ICMPv6
  3. REDIRECT template:· IGMP
  4. REDIRECT template:· IPsecTemplate:·
(more)
Link Layer

ARP/InARP

  1. REDIRECT template:· NDP
  2. REDIRECT template:· OSPF
  3. REDIRECT template:· Tunnels (L2TP)
  4. REDIRECT template:· PPP
  5. REDIRECT template:· Media Access Control (Ethernet, DSL, ISDN, FDDI)Template:· (more)

Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of e-mail to support:

  • Text in character sets other than ASCII
  • Non-text attachments
  • Message bodies with multiple parts
  • Header information in non-ASCII character sets

MIME's use, however, has grown beyond describing the content of e-mail to describing content type in general, including for the web (see Internet media type).

Virtually all human-written Internet e-mail and a fairly large proportion of automated e-mail is transmitted via SMTP in MIME format. Internet e-mail is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME e-mail.[1]

The content types defined by MIME standards are also of importance outside of e-mail, such as in communication protocols like HTTP for the World Wide Web. HTTP requires that data be transmitted in the context of e-mail-like messages, although the data most often is not actually e-mail.

MIME is specified in six linked RFC memoranda: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049, which together define the specifications.

Contents

Introduction

The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English. Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail.

MIME defines mechanisms for sending other kinds of information in e-mail. These include text in languages other than English using character encodings other than ASCII, and 8-bit binary content such as files containing images, sounds, movies, and computer programs. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages even though the data might not (and usually doesn't) actually have anything to do with e-mail. Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail.

The basic format of Internet e-mail is defined in RFC 5322, which is an updated version of RFC 2822 and RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.

MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.

The goals of the MIME definition included requiring no changes to existent e-mail servers and allowing plain text e-mail to function in both directions with existing clients. These goals were achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client. A simple MIME text message is therefore likely to be interpreted correctly by a non-MIME client although if it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ASCII part of the message will be intelligible to users with non-MIME clients.

MIME headers

MIME-Version

The presence of this header indicates the message is MIME-formatted. The value is typically "1.0" so this header appears as

MIME-Version: 1.0

It should be noted that implementers have attempted to change the version number in the past and the change had unforeseen results.[citation needed] It was decided at an IETF meeting[2] to leave the version number as is even though there have been many updates and versions of MIME.

Content-ID[3]

The Content-ID header is primarily of use in multi-part messages (as discussed below); a Content-ID is a unique identifier for a message part, allowing it to be referred to (e.g., in IMG tags of an HTML message allowing the inline display of attached images). The content ID is contained within angle brackets in the Content-ID header. Here is an example:

Content-ID: <5.31.32252.1057009685@server01.example.net>

The standards don't really have a lot to say about exactly what is in a Content-ID; they're only supposed to be globally and permanently unique (meaning that no two are the same, even when generated by different people in different times and places). To achieve this, some conventions have been adopted; one of them is to include an at sign (@), with the hostname of the computer which created the content ID to the right of it. This ensures the content ID is different from any created by other computers (well, at least it is when the originating computer has a unique Internet hostname; if, as sometimes happens, an anonymous machine inserts something generic like localhost, uniqueness is no longer guaranteed). Then, the part to the left of the at sign is designed to be unique within that machine; a good way to do this is to append several constantly-changing strings that programs have access to. In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970, known as the Unix epoch; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far. Put together, these guarantee that the content ID will never repeat; even if multiple messages are generated within the same second, they either have different process IDs or a different count of messages generated by the same process.

That's just an example of how a unique content ID can be generated; different programs do it differently. It's only necessary that they remain unique, a requirement that is necessary to ensure that, even if a bunch of different messages are joined together as part of a bigger multi-part message (as happens when a message is forwarded as an attachment, or assembled into a MIME-format digest), you won't have two parts with the same content ID, which would be likely to confuse mail programs greatly.

There's a similar header called Message-ID which assigns a unique identifier to the message as a whole; this is not actually part of the MIME standards, since it can be used on non-MIME as well as MIME messages. If the originating mail program doesn't add a message ID, a server handling the message later on probably will, since a number of programs (both clients and servers) want every message to have one to keep track of them. Some headers discussed in the Other Headers article make use of message IDs.

When referenced in the form of a Web URI, content IDs and message IDs are placed within the URI schemes cid and mid respectively, without the angle brackets:

cid:5.31.32252.1057009685@server01.example.net

Content-Type

This header indicates the Internet media type of the message content, consisting of a type and subtype, for example

Content-Type: text/plain

Through the use of the multipart type, MIME allows messages to have parts arranged in a tree structure where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of a variety of multipart types. This mechanism supports:

  • simple text messages using text/plain (the default value for "Content-Type: ")
  • text plus attachments (multipart/mixed with a text/plain part and other non-text parts). A MIME message including an attached file generally indicates the file's original name with the "Content-disposition:" header, so the type of file is indicated both by the MIME content-type and the (usually OS-specific) filename extension
  • reply with original attached (multipart/mixed with a text/plain part and the original message as a message/rfc822 part)
  • alternative content, such as a message sent in both plain text and another format such as HTML (multipart/alternative with the same content in text/plain and text/html forms)
  • image, audio, video and application (for example, image/jpg, audio/mp3, video/mp4, and application/msword and so on)
  • many other message constructs

Content-Disposition

The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in RFC 2183 to specify the presentation style. A MIME part can have:

  • an inline content-disposition, which means that it should be automatically displayed when the message is displayed, or
  • an attachment content-disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.

In addition to the presentation style, the content-disposition header also provides fields for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.

The following example is taken from RFC 2183, where the header is defined

 Content-Disposition: attachment; filename=;
         modification-date="Wed, 12 February 1997 16:29:51 -0500";

The filename may be encoded as defined by RFC 2231.

As of 2010, a good majority of mail user agents do not follow this prescription fully. The widely used Mozilla Thunderbird mail client makes its own decisions about which MIME parts should be automatically displayed, ignoring the content-disposition headers in the messages. It also sends out newly composed messages with inline content-disposition for all MIME parts. Most users are unaware of how to set the content-disposition to attachment.[4] Many mail user agents also send messages where they put the file name in the name parameter of the content-type header instead of the filename parameter of the content-disposition header. This practice is discouraged.[5]

Content-Transfer-Encoding

In June 1992, MIME (RFC 1341, since made obsolete by RFC 2045) defined a set of methods for representing binary data in ASCII text format. The content-transfer-encoding: MIME header has 2-sided significance:

  1. It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header, and
  2. If such a binary-to-text encoding method has been used it states which one.

The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive. Note that '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header is actually redundant for the e-mail client to decode the message body, but it may still be useful as an indicator of what type of object is being sent. Values 'quoted-printable' and 'base64' tell the e-mail client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e.g. UTF-8).

  • Suitable for use with normal SMTP:
    • 7bit – up to 998 octets per line of the code range 1..127 with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending. This is the default value.
    • quoted-printable – used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Designed to be efficient and mostly human readable when used for text data consisting primarily of US-ASCII characters but also containing a small proportion of bytes with values outside that range.
    • base64 – used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Designed to be efficient for non-text 8 bit data. Sometimes used for text data that frequently uses non-US-ASCII characters.
  • Suitable for use with SMTP servers that support the 8BITMIME SMTP extension:
    • 8bit – up to 998 octets per line with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending.
  • Suitable only for use with SMTP servers that support the BINARYMIME SMTP extension (RFC 3030):
    • binary – any sequence of octets.

There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension. Thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM

Encoded-Word

Since RFC 2822, message header names and values are always ASCII characters; values that contain non-ASCII data must use the MIME encoded-word syntax (RFC 2047) instead of a literal string. This syntax uses a string of ASCII characters indicating both the original character encoding (the "charset") and the content-transfer-encoding used to map the bytes of the charset into ASCII characters.

The form is: "=?charset?encoding?encoded text?=".

  • charset may be any character set registered with IANA. Typically it would be the same charset as the message body.
  • encoding can be either "Q" denoting Q-encoding that is similar to the quoted-printable encoding, or "B" denoting base64 encoding.
  • encoded text is the Q-encoded or base64-encoded text.

Difference between Q-encoding and quoted-printable

The ASCII codes for the question mark (?) and equals sign may not be represented directly as they are used to delimit the encoded-word. The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably. To make the encoding smaller and easier to read the underscore is used to represent the ASCII code for space creating the side effect that underscore cannot be represented directly. Use of encoded words in certain parts of headers imposes further restrictions on which characters may be represented directly.

For example,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

is interpreted as "Subject: ¡Hola, señor!".

The encoded-word format is not used for the names of the headers (for example Subject). These header names are always in English in the raw message. When viewing a message with a non-English e-mail client, the header names are usually translated by the client.

Multipart messages

A MIME multipart message contains a boundary in the "Content-Type: " header; this boundary, which must not occur in any of the parts, is placed between the parts, and at the beginning and end of the body of the message, as follows:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"

This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain

This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.

Notes:

  • Before the first boundary is an area that is ignored by MIME-compliant clients. This area is generally used to put a message to users of old non-MIME clients.
  • It is up to the sending mail client to choose a boundary string that doesn't clash with the body text. Typically this is done by inserting a long random string.
  • The last boundary must have two hyphens at the end.

Multipart subtypes

The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another. The subtype is specified in the "Content-Type" header of the overall message. For example, a multipart MIME message using the digest subtype would have its Content-Type set as "multipart/digest".

The RFC initially defined 4 subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognised subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.

The following is a list of the most commonly used subtypes; it is not intended to be a comprehensive list.

Mixed

Multipart/mixed is used for sending files with different "Content-Type" headers inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless otherwise specified with the "Content-disposition" header). Otherwise it will offer them as attachments. The default content-type for each part is "text/plain".

Defined in RFC 2046, Section 5.1.3

Message

A message/rfc822 part contains an e-mail message, including any headers. Rfc822 is a misnomer, since the message may be a full MIME message. This is used for digests as well as for E-mail forwarding.

Defined in RFC 2046.

Digest

Multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".

Defined in RFC 2046, Section 5.1.5

Alternative

The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The formats are ordered by how faithful they are to the original, with the least faithful first and the most faithful last. Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.

Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.

Most commonly, multipart/alternative is used for e-mail with two parts, one plain text (text/plain) and one HTML (text/html). The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most e-mail clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.

While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, anti-spam filters would only examine the text/plain part of a message,[citation needed] because it is easier to parse than the text/html part. But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.[citation needed]

Defined in RFC 2046, Section 5.1.4

Related

A multipart/related is used to indicate that message parts should not be considered individually but rather as parts of an aggregate whole. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by the "Content-ID" part header. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.

One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the HTML document, and use image tags to reference images stored in the latter parts.

Defined in RFC 2387

Report

Multipart/report is a message type that contains data formatted for a mail server to read. It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for the mail server to read.

Defined in RFC 3462

Signed

A multipart/signed message is used to attach a digital signature to a message. It has two parts, a body part and a signature part. The whole of the body part, including mime headers, is used to create the signature part. Many signature types are possible, like application/pgp-signature (RFC 3156) and application/x-pkcs7-signature (S/MIME).

Defined in RFC 1847, Section 2.1

Encrypted

A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are identified by their separate content types for the control part. The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME).

Defined in RFC 1847, Section 2.2

Form Data

As its name implies, multipart/form-data is used to express values submitted through a form. Originally defined as part of HTML 4.0, it is most commonly used for submitting files via HTTP.

Defined in RFC 2388 it is edited by jyothish prakash

Mixed-Replace (Experimental)

The content type multipart/x-mixed-replace was developed as part of a technology to emulate server push and streaming over HTTP.

All parts of a mixed-replace message have the same semantic meaning. However, each part invalidates - "replaces" - the previous parts as soon as it is received completely. Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.

Originally developed by Netscape,[6] it is still supported by Mozilla, Firefox, Chrome,[7] Safari (but not in Safari on the iPhone)[citation needed] and Opera, but traditionally ignored by Microsoft. It is commonly used in IP camera s as the MIME type for MJPEG streams.[8]

Byteranges

The multipart/byteranges is used to represent noncontiguous byte ranges of a single message. It is used by HTTP when a server returns multiple byte ranges and is defined in RFC 2616.

See also

References

Notes
RFC 1426 
SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. February 1993.
RFC 1847 
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 3156 
MIME Security with OpenPGP
RFC 2045 
MIME Part One: Format of Internet Message Bodies.
RFC 2046 
MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
RFC 2047 
MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
RFC 4288 
MIME Part Four: Media Type Specifications and Registration Procedures.
RFC 4289 
MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049 
MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2183 
Communicating Presentation Information in Internet Messages: The Content-Disposition Header. Troost, R., Dorner, S. and K. Moore. August 1997.
RFC 2231 
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387 
The MIME Multipart/Related Content-type
RFC 1521 
Mechanisms for Specifying and Describing the Format of Internet Message Bodies

Further reading

  • Hughes, L (1998). Internet e-mail Protocols, Standards and Implementation. Artech House Publishers. ISBN 0890069395. 
  • Johnson, K (2000). Internet E-mail Protocols: A Developer's Guide. Addison-Wesley Professional. ISBN 0201432889. 
  • Loshin, P (1999). Essential E-mail Standards: RFCs and Protocols Made Practical. John Wiley & Sons. ISBN 0471345970. 
  • Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. ISBN 1555582125. 
  • Wood, D (1999). Programming Internet Mail. O'Reilly. ISBN 1565924797. 

External links


Wiktionary

Up to date as of January 15, 2010

Definition from Wiktionary, a free dictionary

English

Wikipedia-logo.png
Wikipedia has an article on:

Acronym

MIME
  1. (networking) Multipurpose Internet Mail Extensions, an Internet standard that extends the formatting and content capabilities of email.

Simple English

Mime is a type of acting that does not use words or speech. Mime is all about physical movement and exaggerating your expressions. Mimes (people who practice mime) must use their actions to send a message or tell a story. They are not allowed to speak directly to the audience.

Probably the most well-known mime was Marcel Marceau.


Citable sentences

Up to date as of December 22, 2010

Here are sentences from other pages on MIME, which are similar to those in the above article.








Got something to say? Make a comment.
Your name
Your email address
Message