Network Working Group J. Palme Request for Comments: 2076 Stockholm University/KTH Category: Informational February 1997 Common Internet Message Headers ｜共通インターネットメッセージヘッダ Status of this Memo ｜このメモの状態 This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ｜このメモはインターネットコミュニティに対し情報を提供するものである。 ｜このメモはいかなるインターネット標準も規定するものではない。この ｜メモの配布に制限はない。 Abstract ｜概要 This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined. ｜このメモはｅメールメッセージのヘッディング(heading)に共通的に存在 ｜するヘッダ(header)の一覧を含んでいる。この文書は、RFC822、RFC1036, ｜RFC1123、RFC1327、RFC1496、RFC1521、RFC1766、RFC1806、RFC1864 ｜及び RFC1911 といった、他の RFC からの情報を集めたものである。また、 ｜RFC に定義されていないものの共通的に使用されているヘッダもまた少し ｜含んいる。それぞれのヘッダについて、このメモは短い解説と、その ｜ヘッダが定義されている RFC への参照を与える。 Table of contents ｜目次 1. Introduction.............................................. 2 2. Use of gatewaying headers................................. 3 3. Table of headers.......................................... 3 3.1 Phrases used in the tables.......................... 3 3.2 Trace information................................... 5 3.3 Format and control information...................... 5 3.4 Sender and recipient indication..................... 6 3.5 Response control.................................... 9 3.6 Message identification and referral headers......... 11 3.7 Other textual headers............................... 12 3.8 Headers containing dates and times.................. 13 3.9 Quality information................................. 13 3.10 Language information............................... 14 3.11 Size information................................... 14 3.12 Conversion control................................. 15 3.13 Encoding information............................... 15 3.14 Resent-headers..................................... 16 3.15 Security and reliability........................... 16 3.16 Miscellaneous...................................... 16 4. Acknowledgments........................................... 18 5. References................................................ 18 6. Author's Address.......................................... 20 Appendix A: Headers sorted by Internet RFC document in which they appear. 21 Appendix B: Alphabetical index........................................... 25 1. Introduction ｜はじめに Many different Internet standards and RFCs define headers which may occur on Internet Mail Messages and Usenet News Articles. The intention of this document is to list all such headers in one document as an aid to people developing message systems or interested in Internet Mail standards. ｜様々なインターネット標準及び RFC が、インターネットメールメッセージ ｜やユーズネットニュースの記事に現われるヘッダを定義している。この文書 ｜の狙いは、メッセージシステムを開発したり、インターネットメールの ｜標準に興味のある人々の手助けとなるよう、一つの文書にこのようなヘッダ ｜のすべてをリストすることである。 The document contains all headers which the author has found in the following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included. PEM and MOSS headers only appear inside the body of a message, and thus are not headers in the RFC 822 sense. Mail attributes in envelopes, i.e. attributes controlling the message transport mechanism between mail and news servers, are not included. This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are mainly not covered either. Headings used only in HTTP [19] are not included yet, but may be included in future version of this memo. A few additional headers which often can be found in e-mail headings but are not part of any Internet standard are also included. ｜この文書には以下のインターネット標準の中で筆者が見つけた全てのヘッダ ｜が含まれている： RFC822 [2]、RFC1036 [3]、RFC1123[5]、RFC1327 [7], ｜RFC1496 [8]、RFC1521 [11]、RFC1766 [12]、RFC1806 [14]、RFC1864[17] ｜及び RFC1911[20]。これには PEM(RFC 1421-1424)と MOSS(RFC1848[16])で ｜定義されている、ヘッディング属性を含んでいないことに特に注意すること。 ｜PEM と MOSS ヘッダはメッセージのボディ(body)の内部だけに存在し、 ｜ゆえに RFC822 の感覚でいえば、これはヘッダではない。エンベロープの ｜メール属性、例えば、メールとニュースサービス間のメッセージ転送 ｜メカニズムを制御する属性、は含まない。これは、SMTP [1]、UUCP[18]、 ｜及び NNTP [15]の属性もまた、主にはカバーしないことを意味している。 ｜HTTP[19]でだけ使用されるヘッディングもまだ含んでいないが、これは ｜このメモの将来の版では含むつもりである。ｅメールのヘッディングで ｜しばしば見ることのできる幾つかの追加ヘッダは、インターネット標準の ｜一部ではないが、これもまた含んでいる。 For each header, the document gives a short description and a reference to the Internet standard or RFC, in which they are defined. ｜各ヘッダについて、この文書は短い解説と、それを定義している ｜インターネット標準又は RFC への参照を与える。 The header names given here are spelled the same way as when they are actually used. This is usually American but sometimes English spelling. One header in particular, "Organisation/Organization", occurs in e-mail headers sometimes with the English and other times with the American spelling. ｜ここで与えるヘッダの名前は、実際に使用されているのと同じ方法で ｜綴られている。これは通常、米国式のスペルであるが、まれに英国式 ｜である。特別に１つのヘッダ、"Organisation/Organization"、が ｜ｅメールヘッダの中で、ある時は英国式で、またある時は米国式の ｜スペルで現われることがある。 The following words are used in this memo with the meaning specified below: ｜以下の単語はこのメモでは次に示す特別の意味をもって使用される。 heading Formatted text at the top of a message, ended by a blank line ｜ヘッディング 空行で終了する、メッセージの先頭にある書式化された ｜ テキスト header = heading One field in the heading, beginning with a field field name, colon, and followed by the field value(s) ｜ヘッダ＝ヘッディングフィールド ｜ フィールド名、コロンで始まり、フィールドの値が ｜ 後に続く、ヘッディングの中の一つのフィールド It is my intention to continue updating this document after its publication as an RFC. The latest version, which may be more up-to- date (but also less fully checked out) will be kept available for downloading from URL ｜RFC として公開された後も、この文章の更新を継続しようと私は意図して ｜いる。より更新された（しかし完全にチェックされていない）最新の版は ｜以下の URL からのダウンロードを可能にしておくつもりである。 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf. Please e-mail me (Jacob Palme ) if you have noted headers which should be included in this memo but are not. ｜もしこのメモに含むべき、あるいは含むべきでないヘッダーに気づいた ｜ならば、私にｅメール (Jacob Palme ) して下さい。 2. Use of gatewaying headers ｜プロトコルを橋渡しするヘッダの使用 RFC 1327 defines a number of new headers in Internet mail, which are defined to map headers which X.400 has but which were previously not standardized in Internet mail. The fact that a header occurs in RFC 1327 indicates that it is recommended for use in gatewaying messages between X.400 and Internet mail, but does not mean that the header is recommended for messages wholly within Internet mail. Some of these headers may eventually see widespread implementation and use in Internet mail, but at the time of this writing (1996) they are not widely implemented or used. ｜RFC1327 は インターネットメールの多くの新しいヘッダを定義していて、 ｜これは X.400 が持つ、しかしそれ以前までインターネットメール標準では ｜なかったと位置づけられるヘッダを定義している。ヘッダが RFC1327 で ｜現われたという事実は、X.400 とインターネットメール間でメッセージが ｜橋渡しされる際に使用するのを推奨していることを示しているが、全く、 ｜インターネットメール内部でのメッセージで推奨されているわけではない。 ｜これらのヘッダのいくつかは、結局、広い範囲で実装され、インター ｜ネットメールの中で使用されるのを見るかも知れないが、これを書いた ｜時点(1966)では、広く実装されてはいないし使用されてもいない。 Headers defined only in RFC 1036 for use in Usenet News sometimes appear in mail messages, either because the messages have been gatewayed from Usenet News to e-mail, or because the messages were written in combined clients supporting both e-mail and Usenet News in the same client. These headers are not standardized for use in Internet e-mail and should be handled with caution by e-mail agents. ｜メッセージがユーズネットニュースからｅメールへ橋渡しされたか、 ｜同一のクライアントでｅメールとユーズネットニュースの両方を ｜サポートする統合型クライアントでメッセージが書かれたかの理由で、 ｜ユーズネットニュースでの使用のために RFC1036 にだけ定義されている ｜ヘッダが、時にメールメッセージの中に現われる。これらのヘッダは ｜インターネットｅメールの使用のためには標準化されていなく、ｅメール ｜のエージェントによって注意して扱うべきである。 3. Table of headers ｜ヘッダの一覧 3.1 Phrases used in the tables ｜一覧で使用される言い回し "not for general Used to mark headers which are defined in RFC usage" 1327 for use in messages from or to Internet mail/X.400 gateways. These headers have not been standardized for general usage in the exchange of messages between Internet mail- based systems. ｜インターネットメール／X.400 ゲートウェイ間で ｜橋渡しされるメッセージで使用するために RFC1327 ｜で定義されているヘッダを識別するために使用する。 "not standardized Used to mark headers defined only in RFC 1036 for use in e-mail" for use in Usenet News. These headers have no standard meaning when appearing in e-mail, some of them may even be used in different ways by different software. When appearing in e-mail, they should be handled with caution. Note that RFC 1036, although generally used as a de-facto standard for Usenet News, is not an official IETF standard or even on the IETF standards track. ｜ユーズネットニュースで使用するために RFC1036 ｜にだけ定義されているヘッダを識別するために使用 ｜する。これらのヘッダがｅメールの中に現われた ｜際には、標準化された意味はないが、他のソフト ｜ウェアによって他の用途で使用されるかもしれない。 ｜これらがｅメールの中で現われた際には、注意を ｜払って扱われるべきである。RFC1036 は、ユーズ ｜ネットニュースのデファクトスタンダードで、 ｜一般に使用されているが、これは正式なIETF標準 ｜ではなく、IETF標準トラックでさえないことに注意 ｜すること。 "non-standard" This header is not specified in any of referenced RFCs which define Internet protocols, including Internet Standards, draft standards or proposed standards. The header appears here because it often appears in e- mail or Usenet News. Usage of these headers is not in general recommended. Some header proposed in ongoing IETF standards development work, but not yet accepted, are also marked in this way. ｜このヘッダは、インターネット標準、ドラフト標準、 ｜又は標準提案を含め、インターネットプロトコルを ｜定義する、どの参照 RFC にも定められていない。 ｜このヘッダは、しばしばｅメール又はユーズネット ｜ニュースで、しばしば見受けられるので、ここに ｜登場している。これらのヘッダの使用は一般的には ｜推奨されない。いくつかのヘッダは現在進行中の ｜IETF 標準開発作業で提案されているが、まだ認可 ｜されていなく、また、このため、これを区別する。 "discouraged" This header, which is non-standard, is known to create problems and should not be generated. Handling of such headers in incoming mail should be done with great caution. ｜このヘッダは、非標準で、問題が生じることが ｜知られており一般的に使用すべきでない。やって ｜きたメールに含まれるこのようなヘッダを処理 ｜する際には、非常に注意を払って行なうべきである。 "controversial" The meaning and usage of this header is controversial, i.e. different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations. ｜このヘッダの意味と使い方には議論の余地があり ｜例えば、異なる用途で、異なった実装が選択され ｜ているようなものがある。この理由で、このような ｜ヘッダは注意を払うと同時に、異なる解釈の可能 ｜性も考え、処理すべきである。 "experimental" This header is used for newly defined headers, which are to be tried out before entering the IETF standards track. These should only be used if both communicating parties agree on using them. In practice, some experimental protocols become de-facto-standards before they are made into IETF standards. ｜このヘッダは新しく定義されたヘッダのために使用 ｜され、IETF標準トラックに提出する前に試用される。 ｜これらは、共に連絡可能な関係者でこれの使用が ｜合意されている時にだけ使用すべきである。実際 ｜には、いくつかの実験的プロトコルは、IETF標準に ｜なる前に、デファクトスタンダードになっている。 3.2 Trace information ｜トレース情報 Used to convey the information Return-Path: RFC 821, from the MAIL FROM envelope RFC 1123: 5.2.13. attribute in final delivery, when the message leaves the SMTP environment in which "MAIL FROM" is used. ｜"MAIL FROM" が使用されるSMTP環境で ｜メッセージが送信された際に、最終 ｜配送で MAIL FROM エンベロープ属性 ｜から情報を伝達するために使用される。 Trace of MTAs which a message has Received: RFC 822: 4.3.2, passed. RFC 1123: 5.2.8. ｜メッセージが通過したMTAのトレース。 List of MTAs passed. Path: RFC 1036: 2.1.6, ｜通過したMTAのリスト。 only in Usenet News, not in e- mail. Trace of distribution lists DL-Expansion- RFC 1327, not for passed. History- general usage. ｜通過した配信リストのトレース。 Indication: 3.3 Format and control information ｜フォーマット及びコントロール情報 An indicator that this message is MIME-Version: RFC 1521: 3. formatted according to the MIME standard, and an indication of which version of MIME is utilized. ｜MIME 標準に従ってフォーマットされた ｜メッセージを示し、使用された MIME ｜のバージョンを表示する。 Special Usenet News actions only. Control: RFC 1036: 2.1.6, ｜特殊なユーズネットニュース動作 only in Usenet ｜にだけ。 mail. Special Usenet News actions and a Also-Control: son-of-RFC1036 normal article at the same time. [21], non- ｜特殊なユーズネットニュース動作 standard, only in ｜と通常の記事を同時に。 Usenet News, not in e-mail Which body part types occur in Original- RFC 1327, not for this message. Encoded- general usage. ｜このメッセージで出現する Information- ｜ボディタイプの種別。 Types: Controls whether this message may Alternate- RFC 1327, not for be forwarded to alternate Recipient: general usage. recipients such as a postmaster if delivery is not possible to the intended recipient. Default: Allowed. ｜もし対象とする受信者に配送する ｜ことが不可能な場合に、この ｜メッセージをメール管理者のよう ｜な、他の受信者に転送させるか ｜どうかの制御。デフォルトは許可。 Whether recipients are to be told Disclose- RFC 1327, not for the names of other recipients of Recipients: general usage. the same message. This is primarily an X.400 facility. In X.400, this is an envelope attribute and refers to disclosure of the envelope recipient list. Disclosure of other recipients is in Internet mail done via the To:, cc: and bcc: headers. ｜同じメッセージの、他の受信者に ｜受信者の名前を告げるか否か。 ｜これは 主に、X.400 の代表的な ｜機能の一つである。X.400では、 ｜これはエンベロープ属性で、 ｜エンベロープ受信者リストの ｜開示を問い合わせる。インター ｜ネットメールでの他の受信者の ｜開示は、To:、cc: 及び bcc: ｜ヘッダを経由して行なう。 Whether a MIME body part is to be Content- RFC 1806, shown inline or is an attachment; Disposition: experimental can also indicate a suggested filename for use when saving an attachment to a file. ｜MIMEボディパートがインラインで ｜表されるか、添付であるか；更に ｜添付されたファイルがセーブされ ｜る際に使用するためのファイル名 ｜の提案も含む。 3.4 Sender and recipient indication ｜送信者及び受信者表示 Authors or persons taking From: RFC 822: 4.4.1, responsibility for the message. RFC 1123: 5.2.15- 16, 5.3.7, Note difference from the "From " RFC 1036 2.1.1 header (not followed by ":") below. ｜筆者又はメッセージの応答を ｜取得する人。 ｜次の"From "(後に":"が続かない) ｜ヘッダとの差に注意。 (1) This header should never From not standardized appear in e-mail being sent, and for use in e-mail should thus not appear in this memo. It is however included, since people often ask about it. ｜このヘッダはｅメールが送信 ｜される時に現われることはなく、 ｜ゆえに、このメモに示すべきでは ｜ない。にもかかわらず含んでいる ｜のは、人々がこれについて、よく ｜尋ねるからである。 This header is used in the so- called Unix mailbox format, also known as Berkely mailbox format or the MBOX format. This is a format for storing a set of messages in a file. A line beginning with "From " is used to separate successive messages in such files. ｜このヘッダは UNIXメールボックス ｜フォーマットと呼ばれ、Barkely ｜メールボックスフォーマット又は ｜MBOXフォーマットとしても知られる ｜ものの中で使用される。これは１つの ｜ファイルにメッセージの集まりを ｜格納するためのフォーマットである。 ｜"From "ではじまる行は、このような ｜ファイルで連続するメッセージを ｜分割するために使用される。 This header will thus appear when you use a text editor to look at a file in the Unix mailbox format. Some mailers also use this format when printing messages on paper. ｜ゆえに、Unixメールボックス ｜フォーマットのファイルを ｜テキストエディタを使って ｜見れば、このヘッダが現われる。 ｜いくつかのメーラもまた、 ｜メッセージを紙に打ち出す際に ｜このフォーマットを印刷する。 The information in this header should NOT be used to find an address to which replies to a message are to be sent. ｜このヘッダのこの情報を、返信 ｜メッセージを送信するための ｜アドレスを見つけるために ｜使うべきではない。 (2) Used in Usenet News mail From RFC 976: 2.4 for transport, to indicate the path or use in Usenet News through which an article has gone >From when transferred to a new host. ｜新しいホストに転送する際に記事 ｜が通ったパスを示すために、ユーズ ｜ネットニュースメール転送で使用 ｜される。 Sometimes called "From_" header. ｜しばしば"From_"ヘッダと呼ばれる。 Name of the moderator of the Approved: RFC 1036: 2.2.11, newsgroup to which this article not standardized is sent; necessary on an article for use in e-mail. sent to a moderated newsgroup to allow its distribution to the newsgroup members. Also used on certain control messages, which are only performed if they are marked as Approved. ｜この記事を送信するニュース ｜グループの承認者の名称； ｜承認が必要な（／モデレートな） ｜ニュースグループで、ニュース ｜グループのメンバへの記事の配信を ｜許可してもらうために必要。また、 ｜もしそれらが Approved と示されて ｜いるならば、実行するだけの、 ｜単なるコントロールメッセージで ｜でも使用される。 The person or agent submitting Sender: RFC 822: 4.4.2, the message to the network, if RFC 1123: 5.2.15- other than shown by the From: 16, 5.3.7. header. ｜From: ヘッダによって示された ｜以外の場合で、ネットワークに ｜メッセージを送信する人、又は ｜代理人。 Primary recipients. To: RFC 822: 4.5.1, ｜主な受信者。 RFC 1123: 5.2.15- 16, 5.3.7. Secondary, informational cc: RFC 822: 4.5.2, recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- ｜二次情報受信者。(cc = カーボン 16, 5.3.7. ｜コピー） Recipients not to be disclosed to bcc: RFC 822: 4.5.3, other recipients. (bcc = Blind RFC 1123: 5.2.15- Carbon Copy). 16, 5.3.7. ｜他の受信者に開示しない受信者。 ｜(bcc = ブラインドカーボンコピー） Primary recipients, who are For-Handling: Non-standard requested to handle the information in this message or its attachments. ｜このメッセージ又は添付情報 ｜を処理することを求める、 ｜二次情報受信者。 Primary recipients, who are For-Comment: Non-standard requested to comment on the information in this message or its attachments. ｜このメッセージ又は添付情報 ｜にコメントを求める、二次 ｜情報受信者。 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, this article was posted. not standardized Some systems provide this header and controversial also in e-mail although it is not for use in e-mail. standardized there. ｜ユーズネットニュースで： ｜この記事をポストするグループ。 ｜いくつかのシステムでは、この ｜ヘッダをｅメールにも提供して ｜いるが、これは標準化されて ｜いない。 Unfortunately, the header can appear in e-mail with two different and contradictory meanings: ｜不幸にも、ｅメールでは、この ｜ヘッダは２つの異なる矛盾した ｜意味で現われる。 (a) Indicating the newsgroup recipient of an article/message sent to both e-mail and Usenet News recipients. ｜ｅメールとユーズネットニュース ｜受信者の両方に送信する記事／ ｜メッセージのニュースグループ受信 ｜者を示す。 (b) In a personally addressed reply to an article in a news- group, indicating the newsgroup in which this discussion originated. ｜ニュースグループの中のある記事 ｜に対し、個人的なアドレスへ応答 ｜する際に、この議論が生じたニュース ｜グループを示す。 Inserted by Sendmail when there Apparently- Non-standard, is no "To:" recipient in the To: discouraged, original message, listing mentioned in recipients derived from the RFC 1211. envelope into the message heading. This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients. ｜元のメッセージに "To:"受信者が ｜ない場合に、配送者のリストを、 ｜Sendmailによって、エンベロープ ｜からメッセージヘッディングに挿入 ｜される。この振る舞いは全く適切 ｜ではなく、MTA はこれを変更すべき ｜ではなく（Receivedの挿入を除く）、 ｜時にこれは Bcc 受信者を誤って ｜公表してしまう原因となる。 Geographical or organizational Distribution: RFC 1036: 2.2.7, limitation on where this article not standardized can be distributed. for use in e-mail. ｜この記事を配送させてもよい ｜地理的又は組織的な場所の制限。 Fax number of the originator. Fax:, Non-standard. ｜作者のファックス番号 Telefax: Phone number of the originator. Phone: Non-standard. ｜作者の電話番号 Information about the client Mail-System- Non-standard. software of the originator. Version:, ｜作者のクライアントソフトウェア Mailer:, ｜に関する情報 Originating- Client:, X- Mailer, X- Newsreader 3.5 Response control ｜応答コントロール This header is meant to indicate Reply-To: RFC 822: 4.4.3, where the sender wants replies to RFC 1036: 2.2.1 go. Unfortunately, this is controversial. ambiguous, since there are different kinds of replies, which the sender may wish to go to different addresses. In particular, there are personal replies intended for only one person, and group replies, intended for the whole group of people who read the replied-to message (often a mailing list, anewsgroup name cannot appear here because of different syntax, see "Followup-To" below.). ｜このヘッダはどこに送信者が応答 ｜してほしいかを示している。残念 ｜ながら、送信者が異なるアドレスに ｜送ろうとした際に、その返信の種類 ｜がいくつか存在するため、これは ｜曖昧になっている。特に、単に、 ｜一人の人への返信を期待するのと、 ｜replied-to メッセージを読んだ ｜グループ全体へを期待する、 ｜グループへの返信とが、存在する。 ｜（これはメーリングリストで、しば ｜しば現われ、ニュースグループでは ｜異なった書式が使われるので遭遇 ｜しない。次の "Followup-To"をみよ。） Some mail systems use this header to indicate a better form of the e-mail address of the sender. Some mailing list expanders puts the name of the list in this header. These practices are controversial. The personal opinion of the author of this RFC is that this header should be avoided except in special cases, but this is a personal opinion not shared by all specialists in the area. ｜メールシステムによっては、この ｜ヘッダを、送信者のｅメールアドレス ｜の、よりよいフォームを示すものと ｜して使用する。メーリングリストを ｜配布するものによっては、このヘッダに ｜リストの名前を置く。この実行は ｜賛否両論である。このRFCの筆者の ｜個人的な意見は、このヘッダは ｜特別な場合を除いて無視するべきで ｜あるが、これはこの世界で全ての ｜専門家で共有されているわけではない。 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, that future discussions (=follow- not standardized up) on an article should go to a for use in e-mail. different set of newsgroups than the replied-to article. The most common usage is when an article is posted to several newsgroups, and further discussions is to take place in only one of them. ｜replied-to 記事よりも、異なった ｜ニュースグループに移って、先の ｜議論(=フォローアップ）を行なう ｜べきであることを示すために、 ｜ユーズネットニュースで使用される。 ｜最も一般的な使用は、ある記事が ｜複数のニュースグループに投稿 ｜され、後の議論はそれらのうちの ｜一つの場所で行なう場合である。 In e-mail, this header may occur in a message which is sent to both e-mail and Usenet News, to show where follow-up in Usenet news is wanted. The header does not say anything about where follow-up in e-mail is to be sent. ｜ｅメールでは、このヘッダは ｜ｅメールとユーズネットニュースの ｜両方に送られたメッセージで現われ ｜ユーズネットでフォローアップする ｜場所を示したい場合に使用される。 ｜このヘッダは、ｅメールで送信する ｜際にフォローアップをどこにする ｜かについては、何も述べていない。 Note that the value of this header must always be one or more newsgroup names, never e-mail addresses. ｜このヘッダは常に１つ以上のニュース ｜グループの名前をさし、決して ｜ｅメールのアドレスを指さないことに ｜注意。 Address to which notifications Errors-To:, Non-standard, are to be sent and a request to Return- discouraged. get delivery notifications. Receipt-To: Internet standards recommend, however, the use of RCPT TO and Return-Path, not Errors-To, for where delivery notifications are to be sent. ｜送信されたことの通知の送り先と、 ｜配送通知を取得する要求である。 ｜インターネット標準の推奨では、 ｜配送通知の送り先は RCPT TO と、 ｜Return-Path の使用で、Error-To ｜ではない。 Whether non-delivery report is Prevent- RFC 1327, not for wanted at delivery error. Default NonDelivery- general usage. is to want such a report. Report: ｜配送が失敗した場合、未配送通知を ｜要求するかどうか。デフォルトでは ｜このような通知は要求する。 Whether a delivery report is Generate- RFC 1327, not for wanted at successful delivery. Delivery- general usage. Default is not to generate such a Report: report. ｜配送が成功した時に、配送通知を ｜要求するかどうか。デフォルトでは ｜このような通知は要求しない。 Indicates whether the content of Content- RFC 1327, not for a message is to be returned with Return: general usage. non-delivery notifications. ｜未配送通知を送信する際に、 ｜メッセージ内容を表示するか ｜どうか。 Possible future change of name X400-Content- non-standard for "Content-Return:" Return: ｜"Content-Return:" に名前を ｜将来変更予定。 3.6 Message identification and referral headers ｜メッセージの識別と参照ヘッダ Unique ID of this message. Message-ID: RFC 822: 4.6.1 ｜このメッセージの一意的なＩＤ RFC 1036: 2.1.5. Unique ID of one body part of the Content-ID: RFC 1521: 6.1. content of a message. ｜メッセージの内容の一意的な ｜ＩＤ Base to be used for resolving Content-Base: Non-standard relative URIs within this content part. ｜この内容パート内部の関連するURIを ｜解読するのに使用させるためのベース URI with which the content of Content- Non-standard this content part might be Location: retrievable. ｜この内容パートの内容が回復できる ｜かもしれないURI Reference to message which this In-Reply-To: RFC 822: 4.6.2. message is a reply to. ｜このメッセージが応答している ｜メッセージへの参照。 In e-mail: reference to other References: RFC 822: 4.6.3 related messages, in Usenet News: RFC 1036: 2.1.5. reference to replied-to-articles. ｜ｅメールでは：他の関連した ｜メッセージの参照、ユーズネット ｜ニュースでは、応答した記事への ｜参照。 References to other related See-Also: Son-of-RFC1036 articles in Usenet News. [21], non-standard ｜ユーズネットニュースで ｜他の関連する記事への参照。 Reference to previous message Obsoletes: RFC 1327, not for being corrected and replaced. general usage. Compare to "Supersedes:" below. This field may in the future be replaced with "Supersedes:". ｜修正又は置換された以前の ｜メッセージへの参照。次の ｜"Supersedes:"と比較せよ。 ｜このフィールドは将来、 ｜"Supersedes:"に置き換えられる ｜であろう。 Commonly used in Usenet News in Supersedes: son-of-RFC1036 similar ways to the "Obsoletes" [21], non-standard header described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e- mail is implemented in the client and often does not remove the old version of the text. ｜ユーズネットニュースでは、上で ｜記述した "Obsoletes"と同じような ｜意味で共通に使用される。しかし ｜ながら、ユーズネットニュースでは ｜Supersedes は、サーバから置換された ｜記事を完全に削除するのに対し、ｅ ｜メールでのクライアントにおける ｜"Supersedes" と "Obsoletes" は、 ｜しばしば、古い版のテキストを ｜削除しない。 Only in Usenet News, similar to Article- son-of-RFC1036 "Supersedes:" but does not cause Updates: [21], non-standard the referenced article to be physically deleted. ｜ユーズネットニュースでだけ使用 ｜され、"Supersedes"と同じように、 ｜使用されるが、参照された記事を ｜物理的に削除させない。 Reference to specially important Article- son-of-RFC1036 articles for a particular Usenet Names: [21], non-standard Newsgroup. ｜個々のユーズネットニュースへの ｜特に重要な記事への参照。 3.7 Other textual headers ｜その他のテキストヘッダ Search keys for data base Keywords: RFC 822: 4.7.1 retrieval. RFC 1036: 2.2.9. ｜データベース検索のための ｜検索キー。 Title, heading, subject. Often Subject: RFC 822: 4.7.1 used as thread indicator for RFC 1036: 2.1.4. messages replying to or commenting on other messages. ｜タイトル、ヘッディング、 ｜サブジェクト。メッセージ返信 ｜や、他のメッセージのコメントに ｜スレッド表示するために使用 ｜される。 Comments on a message. Comments: RFC 822: 4.7.2. ｜メッセージのコメント。 Description of a particular body Content- RFC 1521: 6.2. part of a message. Description: ｜メッセージの個々のボディパート ｜の説明。 Organization to which the sender Organization: RFC 1036: 2.2.8, of this article belongs. not standardized ｜この記事の送信者の属する組織。 for use in e-mail. See Organization above. Organisation: Non-standard. ｜上の Organization を見よ。 Short text describing a longer Summary: RFC 1036: 2.2.10, article. Warning: Some mail not standardized systems will not display this for use in e-mail, text to the recipient. Because of discouraged. this, do not use this header for text which you want to ensure that the recipient gets. ｜長い記事を説明する短いテキスト。 ｜警告：幾つかのメールシステムでは ｜このテキストは受信者に表示されない。 ｜このため、受信者で取得されることを ｜保証されたいテキスト用に、このヘッダ ｜を使ってはならない。 A text string which identifies Content- RFC 1327, not for the content of a message. Identifier: general usage. ｜メッセージの内容を識別する ｜テキスト文字列。 3.8 Headers containing dates and times ｜日付と時刻を含むヘッダ The time when a message was Delivery- RFC 1327, not for delivered to its recipient. Date: general usage. ｜その受信者にメッセージが ｜配送された時刻。 In Internet, the date when a Date: RFC 822: 5.1, message was written, in X.400, RFC 1123: 5.2.14 the time a message was submitted. RFC 1036: 2.1.2. Some Internet mail systems also use the date when the message was submitted. ｜インターネットでは、メッセージ ｜が書かれた時刻で、X.400では ｜送信した時間。インターネット ｜メールシステムのいくつかもまた、 ｜メッセージが送信された時刻に ｜使用している。 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, be used both to limit the time of not standardized an article which is not for use in e-mail. meaningful after a certain date, and to extend the storage of important articles. ｜期限切れとなる日付の提案。 ｜特定の日付以降は意味をもたない ｜記事の制限時間に使用すると共に ｜重要な記事が保存されることを ｜期待する。 Time at which a message loses its Expiry-Date: RFC 1327, not for validity. This field may in the general usage. future be replaced by "Expires:". ｜メッセージが効力を失う時刻。 ｜このフィールドは今後、"Expires:" ｜フィールドに入れられる。 Latest time at which a reply is Reply-By: RFC 1327, not for requested (not demanded). general usage. ｜応答が要求された（必須ではない） ｜最新の時刻。 3.9 Quality information ｜品質情報 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for urgent" and can influence general usage. transmission speed and delivery. ｜"normal"、"urgent"、"no-urgent"の ｜値をとることができ、転送速度と ｜配送に影響させることができる。 Sometimes used as a priority Precedence: Non-standard, value which can influence controversial, transmission speed and delivery. discouraged. Common values are "bulk" and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops. ｜転送速度と配送を影響させる ｜優先度の値として、時に使用 ｜される。共通的な値は、"bulk" ｜と "first-class" である。 ｜他には、自動応答を制御したり、 ｜内容の返答を制御したり、 ｜メーリングリストのループを ｜停止させたりするのに使用 ｜される。 A hint from the originator to the Importance: RFC 1327 and recipients about how important a RFC 1911, message is. Values: High, normal experimental or low. Not used to control transmission speed. ｜作者から受信者へ、メッセージが ｜どの程度重要かのヒントを与える。 ｜値：high, normal, low。 ｜転送速度を制御するためには使用 ｜されない。 How sensitive it is to disclose Sensitivity: RFC 1327 and this message to other people than RFC 1911, the specified recipients. Values: experimental Personal, private, company confidential. The absence of this header in messages gatewayed from X.400 indicates that the message is not sensitive. ｜指定した受信者以外の他の受信者 ｜にこのメッセージを開示する際の ｜慎重度。値：personal, private, ｜company confidential。 ｜X.400 から橋渡しされたメッセージ ｜の中に、このヘッダがない場合は、 ｜メッセージを慎重に扱う必要が ｜ないことを示している。 Body parts are missing. Incomplete- RFC 1327, not for ｜ボディパートが欠落している。 Copy: general usage. 3.10 Language information ｜言語情報 Can include a code for the Language: RFC 1327, not for natural language used in a general usage. message, e.g. "en" for English. ｜例えば、英語のために"en"と ｜いった、メッセージの中で ｜使用される自然言語使用の ｜コードを入れることができる。 Can include a code for the Content- RFC 1766, proposed natural language used in a Language: standard. message, e.g. "en" for English. ｜例えば、英語のために"en"と ｜いった、メッセージの中で ｜使用される自然言語使用の ｜コードを入れることができる。 3.11 Size information ｜サイズ情報 Inserted by certain mailers to Content- Non-standard, indicate the size in bytes of the Length: discouraged. message text. This is part of a format some mailers use when showing a message to its users, and this header should not be used when sending a message through the net. The use of this header in transmission of a message can cause several robustness and interoperability problems. ｜メッセージテキストのバイトサイズ ｜を示すために、一部のメーラによって ｜挿入される。そのユーザにメッセージ ｜を表示するのに、いくつかのメーラは ｜このパートを使用し、ネットを通して ｜メッセージを送信する時には、この ｜ヘッダは使用しない。メッセージ転送 ｜時のこのヘッダの使用は、いくつかの ｜堅牢性と互換操作性の問題を引き起こす。 Size of the message. Lines: RFC 1036: 2.2.12, ｜メッセージのサイズ not standardized for use in e-mail. 3.12 Conversion control ｜変換コントロール The body of this message may not Conversion: RFC 1327, not for be converted from one character general usage. set to another. Values: Prohibited and allowed. ｜このメッセージのボディを、ある ｜キャラクタセットから他に変換 ｜すべきでない。値：Prohibited と ｜allowed。 Non-standard variant of Content- Non-standard. Conversion: with the same values. Conversion: ｜Conversion: の非標準変形；同じ値。 The body of this message may not Conversion- RFC 1327, not for be converted from one character With-Loss: general usage. set to another if information will be lost. Values: Prohibited and allowed. ｜もし情報が失われる可能性がある ｜ならば、キャラクタセットから他に ｜変換すべきでない。値：Prohibited と ｜allowed。 3.13 Encoding information ｜エンコード情報 Format of content (character set Content-Type: RFC 1049, etc.) Note that the values for RFC 1123: 5.2.13, this header are defined in RFC 1521: 4. different ways in RFC 1049 and in RFC 1766: 4.1 MIME (RFC 1521), look for the "MIME-version" header to understand if Content-Type is to be interpreted according to RFC 1049 or according to MIME. The MIME definition should be used in generating mail. ｜内容のフォーマット（キャラクタセット ｜など）。このヘッダの値は、RFC1049と ｜MIME (RFC1521)で異なった方法で定義 ｜されていて、Content-Type が RFC1049 ｜に従うか、MIMEに従うかを判断する ｜ために、"MIME-version"ヘッダを探さ ｜なければならない。MIME定義は、一般 ｜的なメールで使用される。 RFC 1766 defines a parameter "difference" to this header. ｜RFC1766 は このヘッダに ｜パラメータ "difference"を ｜定義する。 Information from the SGML entity Content-SGML- non-standard declaration corresponding to the Entity: entity contained in the body of the body part. ｜ボディパートのボディに含まれる ｜要素に一致する SGMLエンティテイ ｜宣言からの情報。 Coding method used in a MIME Content- RFC 1521: 5. message body. Transfer- ｜MIMEメッセージボディで使用 Encoding: ｜されたコード化手法。 Only used with the value Message-Type: RFC 1327, not for "Delivery Report" to indicates general usage. that this is a delivery report gatewayed from X.400. ｜X.400から橋渡しされた配送 ｜レポートを示す値、 ｜"Delivery Report" だけが ｜使われる。 Used in several different ways by Encoding: RFC 1154, different mail systems. Some use RFC 1505, it for a kind of content-type experimental. information, some for encoding and length information, some for a kind of boundary information, some in other ways. ｜異なったメールシステムによって ｜いくつかの異なった方法で使用 ｜されている。このうちのいくつかは ｜content-type の種類に、いくつか ｜は長さ情報のエンコーディングに、 ｜いくつかは境界情報の種別に、 ｜そしていくつかは、他の用途に ｜使われている。 3.14 Resent-headers ｜Resent-ヘッダ When manually forwarding a Resent-Reply- RFC 822: C.3.3. message, headers referring to the To:, forwarding, not to the original Resent-From:, message. Note: MIME specifies Resent- another way of resending Sender:, messages, using the "Message" Resent-From:, Content-Type. Resent-Date:, ｜メッセージを手動で転送する Resent-To:, ｜際に、オリジナルメッセージ Resent-cc:, ｜ではなく、転送時に作成され Resent-bcc:, ｜るヘッダ。MIMEの仕様では、 Resent- ｜再送には他の方法、 Message-ID: ｜"Message Content-Type"を ｜使用する。 3.15 Security and reliability ｜セキュリティと信頼性 Checksum of content to ensure Content-MD5: RFC 1864, proposed that it has not been modified. standard. ｜修正されていないことを保証する ｜ための、内容のチェックサム。 Used in Usenet News to store Xref: RFC 1036: 2.2.13, information to avoid showing a only in Usenet reader the same article twice if News, not in e- it was sent to more than one mail. newsgroup. Only for local usage within one Usenet News server, should not be sent between servers. ｜ユーズネットニュースで使用され ｜複数のニュースグループに送信さ ｜れたさいに、２回、同じ記事を ｜リーダーで表示されるのを回避 ｜するための情報を保存する。 3.16 Miscellaneous ｜その他 Name of file in which a copy of Fcc: Non-standard. this message is stored. ｜コピーする時に、このメッセージが ｜保存されるファイルの名前。 Has been automatically forwarded. Auto- RFC 1327, not for ｜自動転送された。 Forwarded: general usage. Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 IPM extensions X400-IPMS- general usage. which could not be mapped to Extensions: Internet mail format. ｜インターネットメールにマッピング ｜することが不可能な、X.400 IPM ｜拡張表示のために、インターネット ｜メールで使用される。 Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 MTS extensions X400-MTS- general usage. which could not be mapped to Extensions: Internet mail format. ｜インターネットメールにマッピング ｜することが不可能な、X.400 MTS ｜拡張表示のために、インターネット ｜メールで使用される。 This field is used by some mail Status: Non-standard, delivery systems to indicate the should never status of delivery for this appear in mail in message when stored. Common transit. values of this field are: ｜このフィールドは、保存時に、 ｜このメッセージの配送状態を ｜示すために、幾つかのメール ｜配信システムによって使用され： U message is not downloaded and not deleted. ｜メッセージはダウンロードされて ｜いなく、削除もされていない。 R message is read or downloaded. ｜メッセージは読まれ又はダウンロード ｜された。 O message is old but not deleted. ｜メッセージは古いが削除されていない。 D to be deleted. ｜削除された。 N new (a new message also sometimes is distinguished by not having any "Status:" header. ｜新しい（新しいメッセージは ｜また、時に、他の"Status:" ｜ヘッダを持たないことによって ｜識別される。） Combinations of these characters can occur, such as "Status: OR" to indicate that a message is downloaded but not deleted. ｜これらの文字は、例えば メッセージ ｜がダウンロードされたが削除されて ｜いないことを示すときに、"Status: OR" ｜といったように、組み合わせて発生する。 4. Acknowledgments ｜謝辞 Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick Smith and several other people have helped me with compiling this list. I especially thank Ned Freed and Olle Jdrnefors for their thorough review and many helpful suggestions for improvements. I alone take responsibility for any errors which may still be in the list. ｜Harald Tveit Alvestrand、Ned Freed、Olle Jdrnefors、Keith Moore、 ｜Nick Smith 更に多くの人が、このリストの編集にあたって、私を助けて ｜くれた。特に、レビューと多くの助けになる提案と改善を行なってくれた、 ｜Ned Freed と Olle Jdrnefors に感謝する。リストにまだ残っているで ｜あろういくつかのエラーには、自分で対応すること。 An earlier version of this list has been published as part of [13]. ｜このリストの初期の版は、[13]の一部で公開されている。 5. References ｜参照 Ref. Author, title IETF status (July 1996) ----- --------------------------------------------- ----------- [1] J. Postel: "Simple Mail Transfer Protocol", Standard, STD 10, RFC 821, August 1982. Recommended [2] D. Crocker: "Standard for the format of ARPA Standard, Internet text messages." STD 11, RFC 822, Recommended August 1982. [3] M.R. Horton, R. Adams: "Standard for Not an offi- interchange of USENET messages", RFC 1036, cial IETF December 1987. standard, but in reality a de- facto standard for Usenet News [4] M. Sirbu: "A Content-Type header header for Standard, internet messages", RFC 1049, March 1988. Recommended, but can in the future be expected to be replaced by MIME [5] R. Braden (editor): "Requirements for Standard, Internet Hosts -- Application and Support", Required STD-3, RFC 1123, October 1989. [6] D. Robinson, R. Ullman: "Encoding Header Non-standard Header for Internet Messages", RFC 1154, April 1990. [7] S. Hardcastle-Kille: "Mapping between Proposed X.400(1988) / ISO 10021 and RFC 822", RFC standard, 1327 May 1992. elective [8] H. Alvestrand & J. Romaguera: "Rules for Proposed Downgrading Messages from X.400/88 to standard, X.400/84 When MIME Content-Types are Present elective in the Messages", RFC 1496, August 1993. [9] A. Costanzo: "Encoding Header Header for Non-standard Internet Messages", RFC 1154, April 1990. [10] A. Costanzo, D. Robinson: "Encoding Header Experimental Header for Internet Messages", RFC 1505, August 1993. [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft Internet Mail Extensions) Part One: Standard, Mechanisms for Specifying and Describing the elective Format of Internet Message Bodies", RFC 1521, Sept 1993. [12] H. Alvestrand: "Tags for the Identification Proposed of Languages", RFC 1766, February 1995. standard, elective [13] J. Palme: "Electronic Mail", Artech House Non-standard publishers, London-Boston January 1995. [14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed Protocol: "A Proposed Standard for the Stream- standard Based Transmission of News", RFC 977, January 1986. [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed S. Murphy, "MIME Object Security Services", standard RFC 1848, March 1995. [17] J. Myers, M. Rose: The Content-MD5 Header Draft Header, RFC 1864, October 1995. standard [18] M. Horton, UUCP mail interchange format Not an offi- standard, RFC 976, Januari 1986. cial IETF standard, but in reality a de- facto standard for Usenet News [19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official Hypertext Transfer Protocol -- HTTP/1.0, IETF standard, RFC 1945, May 1996. but the defacto standard until the next version is published [20] G. Vaudreuil: Voice Profile for Internet Experimental Mail, RFC 1911, February 1996. [21] H. Spencer: News Article Format and Not even an Transmission, June 1994, RFC, but FTP://zoo.toronto.edu/pub/news.ps still widely FTP://zoo.toronto.edu/pub/news.txt.Z used and partly This document is often referenced under the almost a de- name "son-of-RFC1036". facto standard for Usenet News 6. Author's Address ｜筆者のアドレス Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden Appendix A: ｜付録Ａ： Headers sorted by Internet RFC document in which they appear. RFC 822 ------- bcc cc Comments Date From In-Reply-To Keywords Message-ID Received References Reply-To Resent- Resent-bcc Resent-cc Resent-Date Resent-From Resent-From Resent-Message-ID Resent-Reply-To Resent-To Return-Path Sender Sender Subject To RFC 976 ------- "From " (followed by space, not colon (:") RFC 1036 -------- Approved Control Distribution Expires Followup-To Lines Newsgroups Organization Path Summary Xref RFC 1049 -------- Content-Type RFC 1327 -------- Alternate-recipient Auto-Forwarded Autoforwarded Content-Identifier Content-Return Conversion Conversion-With-Loss Delivery-Date Discarded-X400-IPMS-Extensions Discarded-X400-MTS-Extensions Disclose-Recipients DL-Expansion-History Expiry-Date Generate-Delivery-Report Importance Incomplete-Copy Language Message-Type Delivery Obsoletes Original-Encoded-Information-Types Prevent-NonDelivery-Report Priority Reply-By Report Sensitivity RFC 1505 -------- Encoding RFC 1521 -------- Content-Description Content-ID Content-Transfer-Encoding Content-Type MIME-Version RFC 1806 -------- Content-Disposition RFC 1864 -------- Content-MD5 RFC 1911 -------- Importance Sensitivity son-of-RFC1036 [21] ------------------- Also-Control Article-Names Article-Updates See-Also Supersedes Not Internet standard --------------------- Apparently-to Content-Base Content-Length Content-Location Content-SGML-Entity Encoding Errors-To Return-Receipt-To Fax "From " (not followed by ":") Telefax Fcc For-Comment For-Handling Mail-System-Version Mailer Organisation Originating-Client Phone Status Supersedes X400-Content-Return X-Mailer X-Newsreader Appendix B: 付録Ｂ： Alphabetical index Section Heading-header ------- -------------- 3.3 Also-Control 3.3 Alternate-Recipient 3.4 Apparently-To 3.4 Approved 3.6 Article-Names 3.6 Article-Updates 3.16 Auto-Forwarded 3.4 bcc 3.4 cc Client, see Originating-Client 3.7 Comments 3.6 Content-Base 3.12 Content-Conversion 3.7 Content-Description 3.3 Content-Disposition 3.6 Content-ID 3.7 Content-Identifier 3.10 Content-Language see also Language 3.11 Content-Length 3.6 Content-Location 3.15 Content-MD5 3.4 Content-Return 3.13 Content-SGML-Entity 3.13 Content-Transfer-Encoding 3.13 Content-Type 3.3 Control 3.12 Conversion 3.12 Conversion-With-Loss 3.8 Date 3.8 Delivery-Date Delivery-Report, see Generate-Delivery-Report, Prevent- Delivery-Report, Non-Delivery-Report, Content-Type Description, see Content-Description 3.16 Discarded-X400-IPMS-Extensions 3.16 Discarded-X400-MTS-Extensions 3.3 Disclose-Recipients Disposition, see Content-Disposition 3.4 Distribution 3.2 DL-Expansion-History-Indication 3.13 Encoding see also Content-Transfer-Encoding 3.4 Errors-To 3.8 Expires Extension see Discarded-X400-IPMS-Extensions, Discarded- X400-MTS-Extensions 3.4 Fax 3.16 Fcc 3.4 Followup-To Forwarded, see Auto-Forwarded 3.4 For-Comment 3.4 For-Handling 3.4 From 3.4 Generate-Delivery-Report History, see DL-Expansion-History-Indication ID, see Content-ID and Message-ID Identifier, see Content-ID and Message-ID 3.9 Importance 3.6 In-Reply-To 3.9 Incomplete-Copy 3.7 Keywords 3.10 Language see also Content-Language Length see Content-Length 3.11 Lines 3.4 Mail-System-Version see also X-mailer 3.4 Mailer MD5 see Content-MD5 3.6 Message-ID 3.13 Message-Type 3.3 MIME-Version 3.4 Newsgroups Newsreader, see X-Newsreader 3.6 Obsoletes 3.7 Organisation 3.7 Organization 3.3 Original-Encoded-Information-Types 3.4 Originating-Client 3.2 Path 3.4 Phone 3.9 Precedence 3.4 Prevent-NonDelivery-Report 3.9 Priority 3.2 Received Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- Recipient 3.6 References 3.8 Reply-By 3.4 Reply-To, see also In-Reply-To, References 3.14 Resent- Return see also Content-Return 3.2 Return-Path 3.5 Return-Receipt-To 3.6 See-Also 3.4 Sender 3.9 Sensitivity 3.16 Status 3.7 Subject 3.7 Summary 3.6 Supersedes 3.4 Telefax 3.4 To Transfer-Encoding see Content-Transfer-Encoding Type see Content-Type, Message-Type, Original-Encoded- Information-Types Version, see MIME-Version, X-Mailer 3.4 X400-Content-Return 3.4 X-Mailer see also Mail-System-Version 3.4 X-Newsreader 3.15 Xref -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。