MIME
The Multipurpose Internet Mail Extensions (MIME) are extensions (since 2008 replaced by RFC 5322 ) that defines the data format of e-mails of Internet standards RFC 822. This provides only the American Standard Code for Information Interchange ( ASCII). The MIME create compatibility for additional characters such as umlauts and multimedia (such as for mail attachments ). They were defined in RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049. RFC 2048 has been classified by the Internet Engineering Task Force only as Best Current Practice.
In addition, MIME application found in the declaration of contents in various Internet protocols, like HTTP, as well as desktop environments such as KDE, Gnome, Xfce or aqua.
- 2.2.1 text
- 2.2.2 image
- 2.2.3 audio
- 2.2.4 video
- 2.2.5 application
- 2.2.6 multipart
- 2.2.7 message
General Description
MIME allows you to specify share information about the type of data transmitted between the transmitter and receiver ( Content-Type field, Internet Media Type) and also a safe for the transmission path used character encoding ( Content-Transfer- Encoding).
There are several specified encoding methods that enable the transmission of non-ASCII characters in texts as well as from non-text documents such as images, voice and video to text-based communication systems such as e- mail or Usenet. The non-text elements are coded at the sender and decoded at the receiver.
The coding of non -7 -bit ASCII characters often relies Quoted-Printable encoding, binary data, however, are usually Base64-encoded. In this encoding way, the overall size of the attached files increased by 33-36 % ( see explanation Base64). From 752 KiB be 1 MiB (1024 KiB) and from 1 MiB 1393 KiB be. Alternatively, it is for text data using Content-Transfer -Encoding: 8bit also possible to transfer the non- ASCII characters directly ( the encoding has to be specified, such as UTF -8 or ISO -8859-15 for German texts).
When used in other protocols such as HTTP, the transport coding can be used binary, can be sent directly to the arbitrary bytes without special coding - for emails this is not allowed.
There is an extension of this standard called S / MIME ( Secure MIME ), which allows you to encrypt and digitally sign messages. In addition, there is PGP / MIME ( described in RFC 2015 and RFC 3156 ) is also a PGP - compatible extension for secure data exchange.
A multipart message contains multiple body parts that are delimited by designated boundaries ( boundary ) must be ensured in their identifier, that this does not occur in the remaining body part. Example of a simple multipart message ( with a truncated boundary, which is defined here as frontier ):
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 - Details of the specification
MIME Part 1 - Format of Internet Message Bodies
This first part of the specification, RFC 2045, performs basic additional fields in the header of an e-mail:
Is the Content-Transfer- Encoding specifies whether the transfer after Internet standard RFC 6152 is to take place, this has occurred, or an encoding for Internet standard RFC 822 occurs, which must be reversed at the receiver:
- 8bit - transmission via Extended SMTP
- Quoted-printable - coding not the corresponding ASCII character is done
- Base64 - Encoding to ISO 646 is done
Which is not a text, in any case requires coding, which then takes place in principle in Base64. Nothing more than containing any text e- mails, however, do not require forming:
Example
From:
This second part of the specification, RFC 2046, defined for the field Content-type main types and subtypes of content:
Text
The parameters of this main type can specify the character set is provided. As a sub-type is predefined simple text without formatting:
- Text / plain
Image
As a sub-type for JPEG images is predefined:
- Image / jpeg
Audio
As a sub-type of tone of the ISDN codec is predefined:
- Audio / basic
Video
As a subtype for MPEG movies is predefined:
Application
This main type is designed for data from application programs. Predefined are two subtypes:
- Application / octet-stream
Multipart
This main type is designed for combinations of several content. Predefined are five subtypes:
- Multipart / mixed
- Multipart / alternative
- Multipart / digest
- Multipart / parallel
- Multipart / related
Message
This main type is intended for handling other emails. Predefined are three subtypes:
- Message/rfc822
- Message / partial
- Message / external-body
MIME Part 3 - Header Extensions for Non- ASCII Text
This third part of the specification removes the restriction to the English character set for the subject and other fields in the header of email messages.
MIME Part 4 - Registration Procedures
This fourth part of the specifications, now RFC 4289, describes the registration of additional extensions with the Internet Assigned Numbers Authority. The registered media types there are many and include explicitly obsolete and deprecated. Back in 1994, registrations were accepted without considering the MIME. Since 1995, the entire registry only Best Current Practice. End of 2005, the registration of media types from the specification of MIME was taken to counteract widespread misconceptions. As a registered MIME media type to behave, is only revealed from the specifications.
MIME Part 5 - Conformance Criteria and Examples
This fifth part of the specification, RFC 2049, specifies minimum requirements for e- mail programs that:
- Mandatory additional header of each generated email:
- Send all non-RFC 822 corresponding emails with codes and headers of the MIME.
- Report of character sets of ISO 8859 in received e-mails.
- Detecting and displaying the content type message/rfc822.
- Far-reaching recognition and representation of the content type multipart.
- Processing all unrecognized content type as a content type octet-stream.
Encoding
RFC 1847 defines encryption and electronic signature by means MIME fundamentally. Two additional media types will be covered:
- Multipart / signed
- Multipart / encrypted
The defined in RFC 5751 Secure / Multipurpose Internet Mail Extensions Set Cryptographic Message Syntax on it.
The defined in RFC 2015 MIME Security with Pretty Good Privacy instead it uses Pretty Good Privacy.
Specifications
- RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
- RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
- RFC 2047 MIME ( Multipurpose Internet Mail Extensions ) Part Three: Message Header Extensions for Non- ASCII Text
- RFC 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
- RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples