Multipurpose Internet Mail Extensions
（多目的インターネットメール拡張）は、規格上US-ASCIIのテキストしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格である。通常はMIME（マイム）と略される。RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289、RFC 2049 で規定されている。
インターネットでメールの書式を定めている RFC 5322 (旧 RFC 822、RFC 2822)では、英数字といくつかの記号を7 ビットで表現する「US-ASCII」と呼ばれる文字コードを利用し、1行あたり1000 バイト(改行を含む)のテキストデータしか許していない。そのため、規格に不適合になるような長い行、US-ASCIIだけで表現できない文字や、バイナリデータ、画像、音声などの非文字データを利用することができなかった。
MIMEはこれらのデータを取り扱うために新しくいくつかのヘッダを定義し、かつUS-ASCII上でさまざまなデータタイプを表現するための符号化方式を規定している。
RFC 5322 (旧 RFC 822、RFC 2822)では1 通のメールで1つの本文しか扱うことができないが、MIMEでは本文を分割して複数のコンテンツを扱うことができるようにした。これをマルチパートと呼ぶ。MIMEヘッダには、MIMEメッセージヘッダとMIMEパートヘッダの二つがある。MIMEメッセージヘッダはメッセージ全体に適用され、MIMEパートヘッダはマルチパートメッセージの各部分に適用される。マルチパートにより、1つのメールに複数の種類のファイルを扱うことができるようになった。
また、HTTPにおけるデータの伝送に関しても、MIMEの枠組みが援用されている。
従来のRFC 5322 (RFC 822, RFC 2822) 準拠のメッセージとの区別、あるいは将来MIMEが拡張されたときにバージョンを区別するためのヘッダ。現在は1.0のみが規定されている。
このメッセージ中のデータのタイプを指定する。
一般的な書式は次の通り。
"type"には、codice_1（テキスト）、codice_2（画像）、codice_3（音声）、codice_4（動画）、codice_5（アプリケーションプログラム固有のフォーマット）などを指定して、データそのものの型を指定できる他、codice_6、codice_7 を指定することで、ひとつのMIMEメッセージの中にさらに別のMIMEメッセージを指定することもできる。
"subtype"には、"type"の詳細な形式を指定する。以下のようなものがよく使われる。
なお、正式な"subtype"が与えられていないデータ形式には、codice_21で始まる独自の名称を使うことができる（例: codice_22）。また、codice_23 で始まるベンダー固有の名称を使うこともできる（例: codice_24）。
"parameter"は追加の情報を指定する。よく使われるものに、codice_8 や codice_9 の文字コード系を明記する codice_27 パラメータがある。
"type"によってはデフォルトの"subtype"が規定されており、受信側は自分の扱えない"subtype"であってもデフォルトの"subtype"として扱うことにより最低限の取り扱いが可能となる。codice_1 のデフォルトは codice_8、codice_5 のデフォルトは codice_15、codice_7 のデフォルトは codice_33 である。
MIMEではUS-ASCIIだけでなくデータのさまざまな符号化方法の指定がこのヘッダで可能になっている。
書式は以下の通り。
"mechanism"として、codice_35、codice_36、codice_37、codice_38、codice_39 が指定できる。一般的に利用できるのは codice_35、codice_38、codice_39 であり、codice_36、codice_37 は一定の条件を満たす場合しか利用できない。
デフォルト値。7 ビットのテキストを表す。codice_34 ヘッダフィールドを省略した場合は、この codice_35 を指定したのと同じ意味となる。US-ASCIIやISO-2022-JPは確実に7 ビットのテキストであるため、これにあたる。
8 ビットのテキストを表す。
RFC 5322 (旧RFC 822、RFC 2822)は7 ビットのテキストを前提としており、この8bitは意図的に違反するものである。メールを転送するためのSMTPは基本的に7 ビットのテキストしか転送できないため、このエンコーディングを用いることはできない。RFC 1652で定義されるSMTPの拡張(ESMTP)の8BITMIMEを用いるか、8 ビットを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
データがテキストではなくバイナリであることを表す。RFC 5322 (旧RFC 822、RFC 2822)はテキストを前提としており、このbinaryは意図的に違反するものである。SMTPは基本的に行単位でデータを扱うため、行の概念すらないバイナリは転送できない。RFC 3030で定義されるESMTPの1つであるBINARYMIMEを用いるか、バイナリを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
US-ASCIIに存在する文字はそのまま使い、存在しない文字などを codice_51"HH"のような形で符号化する。ここで、"HH" には文字のコードを大文字の16進数で指定する。その他、以下のような規則がある。
ヨーロッパ系の言語では、多くの文字がUS-ASCIIと同一で一部に独自の文字を使っているものが多い。
この場合に codice_38 を用いると、US-ASCIIはそのままの文字を使用しているので、データがほとんど大きくならず、codice_57 対応プログラムを使わなくても、大体の内容が読めるという利点がある。
しかし通常のバイナリデータや、Shift_JISやEUC-JPといった仮名漢字などの非ヨーロッパ系の文字のテキストデータに codice_38 を適用した場合は、base64を使用した場合よりも大幅にデータが大きくなる。
3オクテット（24 ビット）を6 ビットずつ4つに分割し、各6 ビットの値に対してそれぞれUS-ASCIIの64 文字（英字52 文字、数字10 文字、「+」、「/」）を割り当てる符号化方式。
この符号化によって、SMTPなどUS-ASCIIしか許されていない通信路でもバイナリデータを交換できるメリットはあるが、データ容量は約33%増加する。
上記のヘッダの導入によって、body部のデータタイプや符号化方式は指定できるようになったが、このままではヘッダ部は相変わらずUS-ASCIIしか利用できない。MIMEではRFC 2047やRFC 2231によって、ヘッダ部分での非US-ASCII文字の扱いを規定している。RFC 2047によれば、
という形式により、文字コード系が"charset"、符号化方法が"encoding"で、"encoded-text"と符号化された単語を表現できる。"charset"は codice_60 における codice_27 パラメータで指定するのと同じ、IANAに登録された文字列を用いる。"encoding" は codice_62 または codice_63（大文字でも小文字でもよい）であり、前者はほぼ codice_38 と同じ符号化方法、後者は codice_39を用いることを表す。