Multipurpose Internet Mail Extensions
(MIME) Part One:
Format of Internet Message Bodies
[多目的インターネットメール拡張]
(MIME) パート1:
インターネットメッセージ本文のフォーマット

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書はインターネットコミュニティのためにインターネット標準トラックプロトコルを指定し、改良のために議論と提案を要求します。標準化状態のための「インターネット役員プロトコル標準」(STD 1)の現行版とこのプロトコルのステータスを参照してください。このメモの配布は無制限です。

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for

STD 11、RFC 822はUS-ASCIIメッセージヘッダについてかなりの詳細を指定しているメッセージ表現プロトコルをUS-ASCIIテキストと定義し、メッセージ中身または本文を置いていきます。正式には Multipurpose Internet Mail Extensions または MIME と呼ばれるこの一連の文書は、次のことを可能にするためにメッセージのフォーマットを再定義します。

These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

これらの文書は、RFC 934、STD 11、RFC 1049において文書化されたより早い仕事に基づき、けれどもそれらを拡張し、改訂します。RFC 822が本文についてほとんど言及しなかったので、これらの文書は主としてRFC 822(というよりも改正)に同列です。

This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

この最初の文書は、MIMEメッセージの構造を説明するために使われた様々なヘッダーを指定します。 2番目の文書、RFC 2046はMIMEメディアタイピングシステムの一般の構造を定義し、メディアタイプの初期のセットを定義します。 インターネットメールヘッダーフィールドで非US-ASCIIテキストデータを許すために、3番目の文書、RFC 2047はRFC 822への拡張を説明します。 4番目の文書、RFC 2048はMIMEに関連した施設のための様々なIANA登録手続を指定します。 5番目の、そして最終的な文書、RFC 2049はMIMEメッセージフォーマット、肯定応答、および文献目録のいくつかの説明に役立つ実例を提供することと同様に、MIME対応標準を説明します。

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

これらのドキュメントはRFC 1521、RFC 1522、およびRFC 1590の改正です。(その改正RFC 1341はとRFC 1342の改正でした)。 RFC 2049の付録は旧バージョンからの違いと変化について説明します。

1.　はじめに
2.　定義、規定、および一般的なBNF文法
　2.1.　CRLF
　2.2.　キャラクタセット
　2.3.　メッセージ
　2.4.　エンティティ
　2.5.　ボディパート
　2.6.　ボディ
　2.7.　7ビット データ
　2.8.　8ビット データ
　2.9.　バイナリデータ
　2.10.　行
3.　MIME ヘッダフィールド
4.　MIME-Version ヘッダフィールド
5.　Content-Type ヘッダフィールド
　5.1.　Content-Type ヘッダフィールドの文法
　5.2.　Content-Type デフォルト
6.　Content-Transfer-Encoding ヘッダフィールド
　6.1.　Content-Transfer-Encoding 構文
　6.2.　Content-Transfer-Encodings 語義
　6.3.　新しい Content-Transfer-Encodings
　6.4.　解釈と使用
　6.5.　翻訳と符号化
　6.6.　正規の符号化モデル
　6.7.　Quoted-Printable Content-Transfer-Encoding
　6.8.　Base64 Content-Transfer-Encoding
7.　Content-ID ヘッダフィールド
8.　Content-Description ヘッダフィールド
9.　付加的な MIME ヘッダフィールド
10.　要約
11.　セキュリティ対策
12.　奥付
A.　収集された文法

Since its publication in 1982, RFC 822 has defined the standard format of textual mail messages on the Internet. Its success has been such that the RFC 822 format has been adopted, wholly or partially, well beyond the confines of the Internet and the Internet SMTP transport defined by RFC 821. As the format has seen wider use, a number of limitations have proven increasingly restrictive for the user community.

1982年の公表以来、RFC 822はインターネットに関する原文のメールメッセージの標準書式を定義しています。 その成功はRFC 822形式が採用されたように完全かかなりSMTP輸送がRFC 821で定義したインターネットとインターネットの境界を超えたものです。 形式が、より広い使用を見たとき、多くの制限がますますユーザ社会において制限していると判明しました。

RFC 822 was intended to specify a format for text messages. As such, non-text messages, such as multimedia messages that might include audio or images, are simply not mentioned. Even in the case of text, however, RFC 822 is inadequate for the needs of mail users whose languages require the use of character sets richer than US-ASCII. Since RFC 822 does not specify mechanisms for mail containing audio, video, Asian language text, or even text in most European languages, additional specifications are needed.

RFC 822がテキストメッセージに形式を指定するのが意図されました。 そういうものとして、オーディオやイメージを含むかもしれないマルチメディアメッセージなどの非テキストメッセージは単に言及されません。 しかし、テキストの場合でさえ、RFC 822は言語がUS-ASCIIより豊かな文字集合の使用を必要とするメールユーザの必要性に不十分です。 RFC 822がオーディオ、ビデオ、アジアの言語テキスト、またはほとんどのヨーロッパの言語のテキストさえ含むメールにメカニズムを指定しないので、追加仕様が必要です。

One of the notable limitations of RFC 821/822 based mail systems is the fact that they limit the contents of electronic mail messages to relatively short lines (e.g. 1000 characters or less [RFC-821]) of 7bit US-ASCII. This forces users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable US-ASCII characters before invoking a local mail UA (User Agent, a program with which human users send and receive mail). Examples of such encodings currently used in the Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

RFC 821/822に基づいているメールシステムの注目に値する限界の1つは彼らが電子メールメッセージのコンテンツを7ビットのUS-ASCIIの比較的短い行(例えば、1000文字より少ない[RFC 821])に制限するという事実です。 これによって、ユーザはやむを得ず、地方のメールUA(ユーザエージェント、人間のユーザがメールを送って、受け取るプログラム)を呼び出す前にそれらがUS-ASCIIキャラクタを印刷可能であるとして7ビットのバイトに送りたがっているどんな非原文のデータも変換します。 現在インターネットで使用されているそのようなencodingsに関する例は純粋な16進、uuencode、RFC 1421で指定された3-4ベース64計画、アンドリューツールキット表現[ATK]、および多くの他のものを含んでいます。

The limitations of RFC 822 mail become even more apparent as gateways are designed to allow for the exchange of mail messages between RFC 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the inclusion of non-textual material within electronic mail messages. The current standards for the mapping of X.400 messages to RFC 822 messages specify either that X.400 non-textual material must be converted to (not encoded in) IA5Text format, or that they must be discarded, notifying the RFC 822 user that discarding has occurred. This is clearly undesirable, as information that a user may wish to receive is lost. Even though a user agent may not have the capability of dealing with the non-textual material, the user might have some mechanism external to the UA that can extract useful information from the material. Moreover, it does not allow for the fact that the message may eventually be gatewayed back into an X.400 message handling system (i.e., the X.400 message is "tunneled" through Internet mail), where the non-textual information would definitely become useful again.

出入口が、RFC 822ホストとX.400ホストの間で私信メッセージの交換を可能にするために設計される時に、RFC 822メールの制限はよりいっそう明白になります。X.400 [X400]は電子メールのメッセージの中で非原文の素材の含意のためにメカニズムを指定します。RFC 822メッセージへのX.400メッセージのマッピングのための現行基準は、X.400非原文素材が、IA5Textフォーマットに(中で符号化されません)変換されなければならないか、それらが、処分が起こったことをRFC 822ユーザに通知して、処分されなければならないと指定します。ユーザが、受け取ることを望むかもしれない情報がなくされる時に、これははっきりと不適当です。ユーザエージェントが、非原文の素材を扱う能力を持ってはならなくても、ユーザは、有益な情報を素材から抜き取ることができるUAに外部のあるメカニズムを持つかもしれません。さらに、それは、非原文の情報が再び間違いなく有益になるであろう所で、メッセージが、結局、X.400メッセージハンドリングシステムの(すなわちX.400メッセージはインターネットメールを通して「トンネルを掘られます」)中に後ろでgatewayedされるかもしれないという事実を考慮しません。

This document describes several mechanisms that combine to solve most of these problems without introducing any serious incompatibilities with the existing world of RFC 822 mail. In particular, it describes:

この文書は、RFC 822メールの既存の世界とのどのような重大な相容れなさでも導入せずにこれらの問題のほとんどを解決するために結合するいくつかのメカニズムを説明します。特に、それは説明します：

All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all of these header fields except for Content-Disposition can include RFC 822 comments, which have no semantic content and should be ignored during MIME processing.

この文書の中で定義されたヘッダーフィールドのすべてはRFC 822中で指定されたヘッダーフィールドのために一般の構文規則に主体です。特に、内容処置を除いたこれらのヘッダーフィールドのすべてはRFC 822コメントを含むことができます(それは意味論的な内容を全然持っていなく、MIME処理の間に無視されるべきです)。

Finally, to specify and promote interoperability, RFC 2049 provides a basic applicability statement for a subset of the above mechanisms that defines a minimal level of "conformance" with this document.

最終的に、インタオペラビリティを指定し、促進するために、この文書によって「対応」の最小のレベルを定義する上記のメカニズムのサブセットのために、RFC 2049は基本の適用可能性ステートメントを提供します。

Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. RFC 822 and STD 3, RFC 1123 also provide essential background for MIME since no conforming implementation of MIME can violate them. In addition, several other informational RFC documents will be of interest to the MIME implementor, in particular RFC 1344, RFC 1345, and RFC 1524.

どうか、標準化状態のための「インターネット役員プロトコル標準」の現行版とこのプロトコルのステータスを参照してください。MIMEのどの対応インプリメンテーションもそれらに違反することができないので、RFC 822とSTD 3で、RFC 1123はまたMIMEのために必須のバックグラウンドを提供します。さらに、いくつかの他の情報のRFC文書は特定のRFC 1344、RFC 1345、およびRFC 1524中でMIME作成者に興味をもつでしょう。

Although the mechanisms specified in this set of documents are all described in prose, most are also described formally in the augmented BNF notation of RFC 822. Implementors will need to be familiar with this notation in order to understand this set of documents, and are referred to RFC 822 for a complete explanation of the augmented BNF notation.

文書のこのセットにおいて指定されたメカニズムが散文の中ですべて説明されるけれども、多くはRFC 822の増大したBNF記法の中でフォーマルにまた説明されます。 作成者は、文書のこのセットを理解するために、この表記法に精通している必要があるであろうし、増大したBNF記法の完全な説明のためにRFC 822に差し向けられます。

Some of the augmented BNF in this set of documents makes named references to syntax rules defined in RFC 822. A complete formal grammar, then, is obtained by combining the collected grammar appendices in each document in this set with the BNF of RFC 822 plus the modifications to RFC 822 defined in RFC 1123 (which specifically changes the syntax for `return', `date' and `mailbox').

文書のこのセットにおける増大したBNFのいくらかがRFC 822中で定義された構文規則への名指しされたリファレンスをします。そして、完全な形式文法は、RFC 1123(特に、‘リターン’、‘日付’、および‘メールボックス’のためにシンタックスを変更します)中で定義されたRFC 822への修正に加えてRFC 822のBNFに設定されたこれにおける各文書の中で収集された文法付録を結合することによって得られます。

All numeric and octet values are given in decimal notation in this set of documents. All media type values, subtype values, and parameter names as defined are case-insensitive. However, parameter values are case-sensitive unless otherwise specified for the specific parameter.

すべての数値で、8ビットバイトの値は文書のこのセットにおける10進法において与えられます。 すべてのメディアタイプは見積もり、サブタイプは見積もり、定義されるようなパラメータ名はケースインセンシティブです。しかし、特定のパラメータのために違った形で指定されない限り、パラメータ値はケースセンシティブです。

The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.

文書のこのセットにおける項CRLFは、この注文の中で一緒にとられて、RFC 822メールの中でライン破壊を示す2つの米国ASCII文字CR(10進値13)とLF(10進値10)と一致している8ビットバイトのシーケンスを参照します。

The term "character set" is used in MIME to refer to a method of converting a sequence of octets into a sequence of characters. Note that unconditional and unambiguous conversion in the other direction is not required, in that not all characters may be representable by a given character set and a character set may provide more than one sequence of octets to represent a particular sequence of characters.

項「文字セット」は、8ビットバイトのシーケンスをキャラクタのシーケンスに変換する方法を参照するためにMIMEの中で使われます。すべてのキャラクタが与えられた文字セットによって表現可能でないかもしれず、文字セットが、キャラクタの特定のシーケンスを表すために8ビットバイトの複数のシーケンスを提供するかもしれないことにおいて、他の方向の中の無条件で、明白なコンバージョンが必要とされていないことに注意してください。

This definition is intended to allow various kinds of character encodings, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO 2022's techniques, to be used as character sets. However, the definition associated with a MIME character set name must fully specify the mapping to be performed. In particular, use of external profiling information to determine the exact mapping is not permitted.

この定義は、US-ASCIIなどの単純なシングルテーブルマッピングから、ISO2022の技術を使うそれらなどの複雑なテーブル交換方法までのキャラクタエンコーディングの様々な種類がキャラクタセットとして使われることを可能にすることを意図しています。しかし、MIME文字セット名と関連づけられた定義は、完全に、実行されるマッピングを指定しなければなりません。特に、正確なマッピングを決定する外部のプロファイリング情報の使用は許されません。

The term "message", when not further qualified, means either a (complete or "top-level") RFC 822 message being transferred on a network, or a message encapsulated in a body of type "message/rfc822" or "message/partial".

さらに有資格でない項「メッセージ」は、ネットワークの上で転送されている、(完全でまたは「トップレベル」)RFC 822メッセージまたはタイプ「message/rfc822」または「message/partial」のボディの中でカプセル化したメッセージのどちらかを意味しています。

The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all -- an entity that is also a message has non-MIME header fields whose meanings are defined by RFC 822.

項、「実体」は特にメッセージまたは複数パート実体のボディの中の部分の1つのどちらかのMIMEで定義されたヘッダーフィールドと内容を参照します。そのような実体の仕様はMIMEの本質です。実体の内容がしばしば「ボディ」と呼ばれるので、実体のボディについて話すことは意味をなします。どのような種類のフィールドでも実体のヘッダーに存在するかもしれないけれども、名前が実際「満足-」から始まるそれらのフィールドだけがどのようなMIME関連の意味でも持っています。これが彼らがすべて意味を全然持っていないthayを暗示していないことに注意してください--また、メッセージである実体は、意味がRFC 822によって定義される非MIMEヘッダーフィールドを持っています。

The term "body part" refers to an entity inside of a multipart entity.

項「ボディ部分」は複数パート実体の中で実体を参照します。

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.

項「ボディ」はさらに有資格でない時に、実体(すなわちどちらのメッセージのボディ)のまたはボディのボディも分かれるのを意味しています。

"7bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]. No octets with decimal values greater than 127 are allowed and neither are NULs (octets with decimal value 0). CR (decimal value 13) and LF (decimal value 10) octets only occur as part of CRLF line separation sequences.

「7ビットのデータ」は、998の8ビットバイトによって相対的に短いラインとしてすべて見せられるデータを参照するか、CRLF系統分離の間のより少しは[RFC-821]を配列します。127より大きい10進値を持つどの8ビットバイトも許されなく、また、NULs(10進値0を持つ8ビットバイト)です。CR(10進値13)とLF(10進値10)8ビットバイトはただCRLFラインセパレーションシーケンスの一部として起こります。

"8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]), but octets with decimal values greater than 127 may be used. As with "7bit data" CR and LF octets only occur as part of CRLF line separation sequences and no NULs are allowed.

「8ビットのデータ」は、CRLFラインセパレーションシーケンス[RFC-821])間で998以下の8ビットバイトによって相対的に短いラインとしてすべて見せられるデータを参照するけれども、127より大きい10進値を持つ8ビットバイトは使われるかもしれません。「7ビットのデータ」と同様に、CRとLFの8ビットバイトはただCRLFラインセパレーションシーケンスの一部として起こり、どのNULも許されません。

"Binary data" refers to data where any sequence of octets whatsoever is allowed.

「バイナリ・データ」は全く8ビットバイトのどんな系列も許容されているデータを示します。

"Lines" are defined as sequences of octets separated by a CRLF sequences. This is consistent with both RFC 821 and RFC 822.
"Lines" only refers to a unit of data in a message, which may or may not correspond to something that is actually displayed by a user agent.

「行」はCRLFシーケンスによって分離された8ビットバイトのシーケンスと定義されます。これはRFC 821とRFC 822両方と一致しています。「行」はただメッセージの中のデータのユニットを参照します(それは、実際ユーザエージェントによって表示される何かと一致するはずがないか、かもしれません)。

MIME defines a number of new RFC 822 header fields that are used to describe the content of a MIME entity. These header fields occur in at least two contexts:

MIMEは、MIME実体の内容を説明するために使われる多くの新しいRFC 822ヘッダーフィールドと定義します。これらのヘッダーフィールドは少なくとも2つのコンテキストに存在しています：

The formal definition of these header fields is as follows:

これらのヘッダーフィールドの形式定義は次の通りです：

entity-headers := [ content CRLF ]
                  [ encoding CRLF ]
                  [ id CRLF ]
                  [ description CRLF ]
                  *( MIME-extension-field CRLF )

MIME-message-headers := entity-headers
                        fields
                        version CRLF
                        ; The ordering of the header
                        ; fields implied by this BNF
                        ; definition should be ignored.
    ; このBNF定義によって暗示されているヘッダーフィールドの
    ; オーダリングは無視されるべきです。

MIME-part-headers := entity-headers
                     [ fields ]
                     ; Any field not beginning with
                     ; "content-" can have no defined
                     ; meaning and may be ignored.
                     ; The ordering of the header
                     ; fields implied by this BNF
                     ; definition should be ignored.
     ; 「content-」から始まっていないどのようなフィールドでも
     ; 定義された意味を全然持つことができなく、無視されるかも
     ; しれません。 このBNF定義によって暗示されているヘッダー
     ; フィールドのオーダリングは無視されるべきです。

The syntax of the various specific MIME header fields will be described in the following sections.

様々な特定のMIMEヘッダーフィールドのシンタックスは以下のセクションの中で説明されるでしょう。

Since RFC 822 was published in 1982, there has really been only one format standard for Internet messages, and there has been little perceived need to declare the format standard in use. This document is an independent specification that complements RFC 822. Although the extensions in this document have been defined in such a way as to be compatible with RFC 822, there are still circumstances in which it might be desirable for a mail-processing agent to know whether a message was composed with the new standard in mind.

RFC 822が1982年に出版されたので、本当はインターネットメッセージのためのフォーマット標準は1つしかなく、フォーマット標準を宣言する気づかれている必要が使用においてほとんどありませんでした。この文書は、RFC 822を補足する独立な仕様です。この文書の中の拡張が、RFC 822と互換のためのそのような方法で定義されたけれども、メール処理エージェントが、メッセージが新しい標準を思って作成されたかどうかを知ることが望ましいかもしれない状況がまだあります。

Therefore, this document defines a new header field, "MIME-Version", which is to be used to declare the version of the Internet message body format standard in use.

従って、この文書は、使用においてインターネット本文フォーマット標準のバージョンを宣言するために使われることになっている新しいヘッダーフィールド、「MIMEバージョン」を定義します。

Messages composed in accordance with this document MUST include such a header field, with the following verbatim text:

この文書に従って作成されたメッセージはそのようなヘッダーフィールドを以下の全く同じのテキストに含めなければなりません：

MIME-Version: 1.0

The presence of this header field is an assertion that the message has been composed in compliance with this document.

このヘッダーフィールドの存在は、メッセージがこの文書に従って作成されているという主張です。

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:

未来の文書が再びメッセージフォーマット標準を拡張するかもしれないことが可能なので、形式的なBNFはMIME-Versionフィールドの内容のために与えられます：

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Thus, future format specifiers, which might replace or extend "1.0", are constrained to be two integer fields, separated by a period. If a message is received with a MIME-version value other than "1.0", it cannot be assumed to conform with this document.

従って、「1.0」を置換するか、拡張するかもしれない未来の書式指定子は、ピリオドによって分離されて2つの整数フィールドであることを強制されます。メッセージが「1.0」以外のMIMEバージョン値によって受け取られるならば、それは、この文書に対応するために仮定されることができません。

Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type "message/rfc822" or "message/partial" if and only if the embedded message is itself claimed to be MIME-conformant.

MIMEバージョンヘッダーフィールドがメッセージのトップレベルで必要とされていることに注意してください。それは複数パート実体の各ボディ部分のために必要とされていません。埋め込まれたメッセージが自身で、MIMEで前述すると主張されるならば、それはタイプ「message/rfc822」または「message/partial」のボディの埋め込まれたヘッダーのために必要とされています。

It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0".

どのように、この文書の中で定義されるように、MIMEに対応するメールリーダが、「1.0」以外のMIMEバージョンのいくらかの値によって未来に到着するかもしれないメッセージを扱うべきであるかを完全に指定することは可能でありません。

It is also worth noting that version control for specific media types is not accomplished using the MIME-Version mechanism. In particular, some formats (such as application/postscript) have version numbering conventions that are internal to the media format. Where such conventions exist, MIME does nothing to supersede them. Where no such conventions exist, a MIME media type might use a "version" parameter in the content-type field if necessary.

特定のメディアタイプのためのバージョン管理が、MIMEバージョンメカニズムを使って、遂行されないことはまた注目する価値があります。特に、いくつかのフォーマット(アプリケーション/ポストスクリプトなどの)は、メディアフォーマットへの内部である規定を数えているバージョンを持っています。そのような規定が存在している所で、それらに取って代るために、MIMEは何もしません。どのそのような規定も存在していない所で、MIMEメディアタイプは必要なら内部形式フィールドで「バージョン」パラメータを使うかもしれません。

MIME-Version: 1.0

MIME-Version: 1.0 (produced by MetaSend Vx.x)

MIME-Version: (produced by MetaSend Vx.x) 1.0

MIME-Version: 1.(produced by MetaSend Vx.x)0

In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything.

MIMEバージョンフィールドの不在において、受領メールユーザエージェント(MIME必要条件への対応)は、ローカルな規定に従ってメッセージのボディを解釈することをオプションで選ぶことができます。多くのそのような規定は現在使用されていて、実際の場で、非MIMEメッセージがだいたい何でも含むことができることは注目されるべきです。

It is impossible to be certain that a non-MIME mail message is actually plain text in the US-ASCII character set since it might well be a message that, using some set of nonstandard local conventions that predate MIME, includes text in another character set or non-textual data presented in a manner that cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file).

MIMEに先行している標準外のローカルな規定のあるセットを使って、テキストを、自動的に認められる(例えばuuencodedはUNIXのtar式圧縮ファイル)ことができない方法で提出された別の文字セットまたは非原文のデータに含めているのがメッセージであるのももっともであるので、非MIME私信メッセージが実際米国ASCII文字セットの中で普通テキストであると確信していることは不可能です。