RFC2076 日本語訳
2076 Common Internet Message Headers. J. Palme. February 1997. (Format: TXT=47639 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Palme Request for Comments: 2076 Stockholm University/KTH Category: Informational February 1997
コメントを求めるワーキンググループJ.パルメの要求をネットワークでつないでください: 2076年のストックホルム大学/KTHカテゴリ: 情報の1997年2月
Common Internet Message Headers
一般的なインターネットメッセージヘッダー
Status of this Memo
この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.
このメモはメールメッセージに関する見出しに一般的に起こっているヘッダーのテーブルを保管しています。 ドキュメントはRFC822や、RFC1036や、RFC1123や、RFC1327や、RFC1496や、RFC1521や、RFC1766や、RFC1806や、RFC1864やRFC1911などの他のRFCsからの情報をコンパイルします。 また、RFCsで定義されないいくつかの一般的に起こっているヘッダーが含まれています。 各ヘッダーに関しては、メモはヘッダーが定義される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
目次1。 序論… 2 2. gatewayingヘッダーの使用… 3 3. ヘッダーのテーブル… 3 テーブルで使用される3.1の句… 3 3.2 情報をたどってください… 5 3.3 情報をフォーマットして、制御してください… 5 3.4 送付者と受取人指示… 6 3.5 応答コントロール… 9 3.6 メッセージ識別と紹介ヘッダー… 11 他の3.7個の原文のヘッダー… 12 日付と回を含む3.8個のヘッダー… 13 3.9 上質の情報… 13 3.10 言語情報… 14 3.11 サイズ情報… 14 3.12 変換コントロール… 15 3.13 情報をコード化します… 15 3.14 ヘッダーに憤慨します… 16 3.15のセキュリティと信頼性… 16 3.16その他… 16 4. 承認… 18
Palme Informational [Page 1] RFC 2076 Internet Message Headers February 1997
[1ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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
5. 参照… 18 6. 作者のアドレス… 20 付録A: 彼らが現れるRFCが記録するインターネットによって割り当てられたヘッダー。 21 付録B: アルファベット順インデックス… 25
1. Introduction
1. 序論
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.
多くの異なったインターネット標準とRFCsはインターネットのメールMessagesとUsenet News Articlesに起こるかもしれないヘッダーを定義します。 このドキュメントの意志はインターネットメール規格にメッセージシステムを開発するか、または興味を持っている人々への援助のような1通のドキュメントのすべてのヘッダーを記載することです。
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]、RFC 1864[17]、およびRFC 1911[20]。 見出し属性がPEMで(RFC1421-1424)とモスを定義したことに特に注意してください。(含まれていなかったRFC1848[16])。 PEMと唯一のモスヘッダーは、メッセージのボディーの中に現れて、その結果、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.
ここに与えられたヘッダー名はそれらが実際に使用される時として同じ道とつづられます。 これは通常アメリカの、しかし、時々イギリスのスペルです。 「機構/組織」という特にあるヘッダーがメールヘッダーに時々アメリカのスペルがあるイギリスの、そして、他の回で起こります。
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
空白行によって終わらされたメッセージの先端の見出しFormattedテキスト
header = heading One field in the heading, beginning with a field field name, colon, and followed by the field value(s)
分野値が分野フィールド名、コロンで始まって、見出しにOne分野の上に立って、あとに続いたヘッダー=(s)
Palme Informational [Page 2] RFC 2076 Internet Message Headers February 1997
[2ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf.
それは公表の後にRFCとしてこのドキュメントをアップデートし続けているという私の意志です。 最新版であり、どれが、より多くの上から日付であるかもしれないか(以下は完全にまたチェックアウトされた)がURL http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf からダウンロードするのに利用可能に守られるでしょう。
Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted headers which should be included in this memo but are not.
私にメールしてください、(ヤコブ Palme <jpalme@dsv.su.se 、gt;、)、あなたがこのメモに含まれるべきであるヘッダーに注意しましたが、いないなら。
2. Use of gatewaying headers
2. gatewayingヘッダーの使用
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とインターネット・メールの間のメッセージをgatewayingすることにおける使用のために推薦されるのを示しますが、ヘッダーがメッセージのためにインターネット・メールの中で完全に推薦されることを意味しません。 これらの何人かのヘッダーが結局、インターネット・メールで広範囲の実現と使用を見るかもしれませんが、彼らは、この書くこと(1996)時点で、広く実行もされませんし、使用もされません。
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.
Usenet Newsにおける使用のためにRFC1036だけで定義されたヘッダーはメール・メッセージに時々現れます、メッセージがUsenet Newsからメールまでgatewayedされたか、またはメッセージが同じクライアントでメールとUsenet Newsの両方を支持している結合したクライアントに書かれたので。 これらのヘッダーは、インターネット電子メールにおける使用のために標準化されないで、メールエージェントによって慎重に扱われるべきです。
3. Table of headers
3. ヘッダーのテーブル
3.1 Phrases used in the tables
3.1 テーブルで使用される句
"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ゲートウェイへのメッセージにおける使用のための「RFC用法で定義されるヘッダーをマークする一般的なUsedでない」1327。 これらのヘッダーはインターネットメールに基づいているシステムの間のメッセージの交換における一般的な用法のために標準化されていません。
Palme Informational [Page 3] RFC 2076 Internet Message Headers February 1997
[3ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
"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.
Usenet Newsにおける使用のために「メールにおける使用のためにRFC1036だけで定義されたマークヘッダーにUsedを標準化しませんでした」。 メールに現れるとき、これらのヘッダーには、どんな標準の意味もなくて、彼らの何人かが異なったソフトウェアによって異なった方法で使用さえされるかもしれません。 メールに現れるとき、それらは慎重に扱われるべきです。 Usenet Newsのデファクト規格として一般に使用されますが、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.
「標準的でない」Thisヘッダーはインターネットプロトコルを定義する参照をつけられたRFCsのいずれでも指定されません、インターネットStandards、草稿規格または提案された標準を含んでいて。 ヘッダーは、電子メールかUsenet Newsにしばしば現れるので、ここに現れます。 一般に、これらのヘッダーの使用法は推薦されません。 進行中の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.
「妨げている」Thisヘッダー(標準的でない)は、問題を生じさせるのが知られて、発生するべきではありません。 十分な注意で入って来るメールにおけるそのようなヘッダーの取り扱いをするべきです。
"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.
「実験的な」Thisヘッダーは新たに定義されたヘッダーに使用されます。(ヘッダーはIETF標準化過程に入る前に、十分に試されることになっています)。 ともに交信しているパーティーが、彼らを使用するのに同意する場合にだけ、これらは使用されるべきです。 実際には、それらをIETF規格にする前にいくつかの実験プロトコルがデファクトスタンダードになります。
Palme Informational [Page 4] RFC 2076 Internet Message Headers February 1997
[4ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
3.2 Trace information
3.2 トレース情報
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.
情報Return-経路を伝えるのにおいて中古: MAIL FROM封筒RFC1123からのRFC821: 5.2.13. 最終的な配送、いつのメッセージがSMTP環境を残す属性、どれ、「メール、」 使用されるか。
Trace of MTAs which a message has Received: RFC 822: 4.3.2, passed. RFC 1123: 5.2.8.
それのaメッセージにはReceivedがあるMTAsの跡: RFC822: 4.3.2、通ります。 RFC1123: 5.2.8.
List of MTAs passed. Path: RFC 1036: 2.1.6,
only in Usenet
News, not in e-
mail.
MTAsのリストは通りました。 経路: RFC1036: 2.1.6、Usenet Newsだけのどんな電子メールでも、そうしません。
Trace of distribution lists DL-Expansion- RFC 1327, not for
passed. History- general usage.
Indication:
発送先リストDL-拡大RFC1327の跡、通ります。 歴史の一般的な用法。 指示:
3.3 Format and control information
3.3 形式と制御情報
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バージョンであるというインディケータ: RFC1521: 3. MIME規格、およびMIMEのどのバージョンが利用されているかのしるしに従って、フォーマットされています。
Special Usenet News actions only. Control: RFC 1036: 2.1.6,
only in Usenet
News, not in e-
mail.
特別なUsenet News動き専用。 コントロール: RFC1036: 2.1.6、Usenet Newsだけのどんな電子メールでも、そうしません。
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
特別なUsenet News動きとAlso-コントロール: 同時にのRFC1036の息子の正常な記事。 メールではなく、Usenet Newsだけの非規格の[21]
Which body part types occur in Original- RFC 1327, not for
this message. Encoded- general usage.
Information-
Types:
Original- RFC1327では、このメッセージに起こるのではなく、起こります身体の部分が、タイプする。 一般的な用法をコード化しました。 情報は以下をタイプします。
Palme Informational [Page 5] RFC 2076 Internet Message Headers February 1997
[5ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
このメッセージがそうするかもしれないかどうかを制御する、Alternate- RFC1327、進めて、Recipientを交替してください: 一般的な用法意図している受取人には、郵便局長などの受取人は配送であるなら可能ではありません。 デフォルト: 許容にされる。
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.
Recipientsの他の受取人のいずれの名前のためにもDisclose- RFC1327を受取人に言ってはいけないか否かに関係なく: 一般的な用法同じメッセージ。 これは主として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身体の部分がことであるContent- RFCであるか否かに関係なく、1806は、インラインを示しているか、付属です。 気質: また、ファイルへの付属を救うとき、実験用缶は使用のために提案されたファイル名を示します。
3.4 Sender and recipient indication
3.4 送付者と受取人指示
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:を取る作者か人々 RFC822: 4.4.1、メッセージへの責任。 RFC1123: 違い..ヘッダー..続く..以下に
(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.
(1) このヘッダーは現れるべきです。標準化されなかったFromはメールで送りながら現れて、その結果、このメモにメールにおける使用に関して決して現れるはずがありません。 人々がしばしばそれに関して尋ねるので、しかしながら、それは含まれています。
Palme Informational [Page 6] RFC 2076 Internet Message Headers February 1997
[6ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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メールボックス形式に使用されて、また、Berkelyメールボックス形式かMBOX形式として知られています。 これは、ファイルに1セットのメッセージを格納するための形式です。 Aが始めを裏打ちする、「」 そのようなファイルの連続したメッセージを切り離すために、使用されます。
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.
(2)はUsenet NewsメールFrom RFC976で使用しました: 輸送のための2.4、記事が続いたUsenet Newsにおける経路か使用を示す、>From、新しいホストに移すと。
Sometimes called "From_" header.
時々「_」ヘッダーと呼ばれます。
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の議長の名前: RFC1036: 2.2.11、標準化されなかったこの記事が送られるニュースグループ。 中で使用のための記事では、メールしてください。必要性. ニュースグループのメンバーに分配を許すのを加減されたニュースグループに発信させました。 また、あるコントロールメッセージでは、使用されています。(それらが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.
Senderを提出する人かエージェント: RFC822: 4.4.2、ネットワークへのメッセージRFC1123であるなら 5.2、.15、-、From:で、示されます。 16、5.3.7ヘッダー。
Primary recipients. To: RFC 822: 4.5.1,
RFC 1123: 5.2.15-
16, 5.3.7.
第一の受取人。 To: RFC822: 4.5.1、RFC1123: 5.2.15- 16, 5.3.7.
Palme Informational [Page 7] RFC 2076 Internet Message Headers February 1997
[7ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
Secondary, informational cc: RFC 822: 4.5.2,
recipients. (cc = Carbon Copy) RFC 1123. 5.2.15-
16, 5.3.7.
二次の、そして、情報のcc: RFC822: 4.5.2、受取人。 (cc=カーボンコピー) RFC1123。 5.2.15- 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:に明らかにされるべきでない受取人 RFC822: 4.5.3、他の受取人。 (= 盲目のRFC1123: 5.2に、.15カーボンコピーをbccします。) 16, 5.3.7.
Primary recipients, who are For-Handling: Non-standard requested to handle the information in this message or its attachments.
第一の受取人。(その受取人は以下をFor扱っています)。 標準的でなさ、このメッセージかその付属で情報を扱うよう要求されています。
Primary recipients, who are For-Comment: Non-standard requested to comment on the information in this message or its attachments.
予備選挙受取人:(その受取人は、For-コメントです)。 標準的でなさ、このメッセージかその付属で情報を批評するよう要求されています。
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.
Usenetニュースで: (s)をどのニュースグループに分類してくださいか: RFC1036: 2.1.3 この記事は掲示されました。それはそこで標準化されたメールにおける使用のためのものではありませんが、どんな標準化されたSomeシステムにもメールにもこのヘッダーで論議を呼んだ状態で提供されません。
Unfortunately, the header can appear in e-mail with two different and contradictory meanings:
残念ながら、ヘッダーは2つの異なって相容れない意味と共にメールに現れることができます:
(a) Indicating the newsgroup recipient of an article/message sent to both e-mail and Usenet News recipients.
(a) 記事/メッセージのニュースグループの受取人を示すのはメールとUsenet News受取人の両方に発信しました。
(b) In a personally addressed reply to an article in a news- group, indicating the newsgroup in which this discussion originated.
(b) ニュースの記事に関する個人的に記述された回答では分類してください、この議論が由来したニュースグループを示して。
Palme Informational [Page 8] RFC 2076 Internet Message Headers February 1997
[8ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
そこであるのに、センドメールによって挿入される、Apparently標準的でなくて、いいえは「To:」です。 To:の受取人 妨げていて、オリジナルのメッセージ、RFC1211封筒からメッセージ見出しに得られた受取人で参照されたリスト。 この振舞いは全く適切であるというわけではありません、そして、MTAsは見出し(Received線を挿入するのを除いた)を変更するはずがありません、そして、いくつかの場合、それで、誤って非Bcc受取人に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.
地理的であるか組織的なDistribution: RFC1036: この記事が缶を標準化しなかったところでは、分配されてください。2.2.7、制限、オンである、使用には、中でメールしてください。
Fax number of the originator. Fax:, Non-standard.
Telefax:
ファックスで、創始者の数を送ってください。 Fax:で、標準的でないです。 テレファックス:
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
クライアントに関してメールシステム標準的でない情報、創始者のソフトウェア。 バージョン:、メイラー:、由来しているクライアント:、Xメイラー、Xニュースキャスター
3.5 Response control
3.5 応答制御
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.).
このヘッダーはReply-Toを示すことになっています。 RFC822: 4.4.3 送付者がどこで欲しいかがRFC1036に答えます: 2.2.1 行ってください。 残念ながら、これは論議を呼んでいます。あいまいです、以来、異種の回答があります。(送付者は異なったアドレスに回答を行かせたがっているかもしれません)。 1人の人、およびグループ回答だけのために意図していて、答えているメッセージを読む人々の全体のグループのために意図している個人的な回答があります。(しばしばメーリングリスト、anewsgroup名が異なった構文のためにここに現れることができない、見る、「追跡、-、」 )以下に。
Palme Informational [Page 9] RFC 2076 Internet Message Headers February 1997
[9ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
いくつかのメールシステムが、送付者のEメールアドレスの、より良い作法を示すのにこのヘッダーを使用します。 いくつかのメーリングリストエキスパンダがこのヘッダーにリストの名前を入れます。 これらの習慣は論議を呼んでいます。 この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.
Usenet Newsでは、Followup-To:を示すために、使用されます。 RFC1036: 2.2.3、その今後の議論、(= 続いてください、-、標準化されない、上) 記事では、メール異なったセットのニュースグループは答えている記事より中に使用のためのaに行っているべきです。 最も一般的な用法は記事がいくつかのニュースグループに掲示される時です、そして、さらなる議論は1だけでそれらを行われさせることになっています。
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.
メールでは、このヘッダーは、Usenetニュースにおけるフォローアップがどこで欲しいかを示すためにともにメールするために送られるメッセージとUsenet Newsに起こるかもしれません。 ヘッダーは、メールを追跡しているところに関する何も送られることになっていると言いません。
Note that the value of this header must always be one or more newsgroup names, never e-mail addresses.
このヘッダーの値が1つ以上のニュースグループ名、いつも決してEメールアドレスでなければならないというわけではないことに注意してください。
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.
Errors-To:、Non-規格がどの通知に送るかことであり、要求をがっかりするReturnに記述してください。配送通知を得てください。 領収書To: しかしながら、インターネット標準がRCPT TOとReturn-経路の使用を推薦する、Errors、-、送られる配送通知がことであるところに。
Palme Informational [Page 10] RFC 2076 Internet Message Headers February 1997
[10ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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:
非配送レポートがPrevent- RFC1327であるかどうか、配送誤りで、欲しいです。 デフォルトNonDelivery一般的な用法そのようなレポートが欲しいことになっています。 以下を報告してください。
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.
配送レポートがGenerate- RFC1327であるかどうか、うまくいっている配送では、欲しいです。 配送の一般的な用法。 デフォルトはそのようなReportは発生させないことです: 報告してください。
Indicates whether the content of Content- RFC 1327, not for a message is to be returned with Return: general usage. non-delivery notifications.
Returnと共に返すためにメッセージではなく、Content- RFC1327の内容がそうであるかどうかを示します: 一般的な用法非配送通知。
Possible future change of name X400-Content- non-standard for "Content-Return:" Return:
可能な未来が名義のX400-内容標準的でないのを変える、「満足しているリターン:」 リターン:
3.6 Message identification and referral headers
3.6 メッセージ識別と紹介ヘッダー
Unique ID of this message. Message-ID: RFC 822: 4.6.1
RFC 1036: 2.1.5.
このメッセージのユニークなID。 Message ID: RFC822: 4.6.1 RFC1036: 2.1.5.
Unique ID of one body part of the Content-ID: RFC 1521: 6.1. content of a message.
コンテントIDの1つの身体の部分のユニークなID: RFC1521: 6.1. メッセージの内容。
Base to be used for resolving Content-Base: Non-standard relative URIs within this content part.
Content-基地を分解するのに使用されるべき基地: この内容の中の標準的でない相対的なURIは離れています。
URI with which the content of Content- Non-standard this content part might be Location: retrievable.
Content標準的でないこれほど満足している部分の内容がLocationであるかもしれないURI: 回収可能。
Reference to message which this In-Reply-To: RFC 822: 4.6.2. message is a reply to.
どれを通信させるかために参照をつける、このIn-Reply-To RFC822: 4.6.2. メッセージはそうです。aは答えます。
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の参照: RFC822: 4.6.3 Usenet Newsの関連するメッセージ: RFC1036: 2.1.5. 記事に答えることの参照。
References to other related See-Also: Son-of-RFC1036 articles in Usenet News. [21], non-standard
他の参照はSeeも関係づけました: Usenet NewsのRFC1036の息子記事。 [21]で、標準的でないです。
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:".
前のメッセージObsoletesの参照: 修正されて、取り替えられないためのRFC1327、一般的な用法。 「Supersedes:」と比較してください。 以下に 将来、この野原を「Supersedes:」に取り替えるかもしれません。
Palme Informational [Page 11] RFC 2076 Internet Message Headers February 1997
[11ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
Supersedes:のUsenet Newsで一般的に使用されます。 「時代遅れに[21]」、上で説明された標準的でないヘッダーへのRFC1036の息子の同様の道。 しかしながら、Usenet Newsでは、Supersedesはサーバにおける、取り替えられた記事の完全な削除を引き起こします、電子メールによる「時代遅れに「取って代わること」と」は、クライアントで実行されて、しばしばテキストの古いバージョンを取り除くというわけではありませんが。
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.
Article RFC1036の息子「Supersedes:」と同様のUsenet Newsだけで しかし、どんな原因Updatesもしません: [21]で、標準的でない、物理的に削除されるべき参照をつけられた記事。
Reference to specially important Article- son-of-RFC1036 articles for a particular Usenet Names: [21], non-standard Newsgroup.
特に重要なArticle RFC1036の息子記事の特定のUsenet Namesの参照: [21]、標準的でないニュースグループ。
3.7 Other textual headers
3.7 他の原文のヘッダー
Search keys for data base Keywords: RFC 822: 4.7.1 retrieval. RFC 1036: 2.2.9.
データベースKeywordsとしてキーを捜してください: RFC822: 4.7.1 検索。 RFC1036: 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.
向かっていて、受けることがあるタイトル。 しばしばSubject: RFC822: 4.7.1 RFC1036のための糸のインディケータとして中古: 2.1.4. 他のメッセージを答えるか、または批評するメッセージ。
Comments on a message. Comments: RFC 822: 4.7.2.
メッセージのコメント。 コメント: RFC822: 4.7.2.
Description of a particular body Content- RFC 1521: 6.2. part of a message. Description:
特定のボディーContent- RFC1521の記述: 6.2. メッセージの一部。 記述:
Organization to which the sender Organization: RFC 1036: 2.2.8,
of this article belongs. not standardized
for use in e-mail.
組織、どれ、送付者Organization: RFC1036: 2.2.8 これでは、記事は属します。使用のために中で標準化されないで、メールしてください。
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.
より長いSummaryについて説明する短いテキスト: RFC1036: 2.2.10、記事。 警告: 標準化されたシステムではなく、郵便配達人がメールにおける使用、受取人へのテキストのためにこれを表示しないでしょう。 . これをがっかりさせて、あなたが確実にしたいテキストのための受取人が手に入れるこのヘッダーを使用しません。
Palme Informational [Page 12] RFC 2076 Internet Message Headers February 1997
[12ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
A text string which identifies Content- RFC 1327, not for the content of a message. Identifier: general usage.
メッセージの内容でないためにContent- RFC1327を特定するテキスト文字列。 識別子: 一般的な用法。
3.8 Headers containing dates and times
3.8 日付と回を含むヘッダー
The time when a message was Delivery- RFC 1327, not for delivered to its recipient. Date: general usage.
メッセージがDelivery- RFC1327であった時、受取人に配送しました。 日付: 一般的な用法。
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.
インターネット、日付:であることの日付で RFC822: 5.1 メッセージはX.400、RFC1123に書かれました: 5.2.14メッセージが提出された時。 RFC1036: 2.1.2. また、いくつかのインターネット・メールシステムがメッセージが提出された日付を使用します。
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.
提案された有効期限。 缶は期限が切れます: RFC1036: 2.2.4 使用されて、ともに標準化されないことでは、メール重要な後aで確かな使用のためのものでない記事がデートする時を制限して、重要な記事の格納を広げてください。
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:".
メッセージがExpiry-日付:を失う時 正当性でないRFC1327。 取り替えてください。この分野が一般的な用法でそうするかもしれない、将来、「以下を吐き出します」。
Latest time at which a reply is Reply-By: RFC 1327, not for requested (not demanded). general usage.
回答が近くReplyである最も遅い時間: RFC1327. 一般的な用法を要求しました(要求されません)。
3.9 Quality information
3.9 品質情報
Can be "normal", "urgent" or "non- Priority: RFC 1327, not for urgent" and can influence general usage. transmission speed and delivery.
または、「正常で」、「緊急であることができる」、「非優先権:」 「RFC1327、緊急である、」 一般的な用法伝送速度と配送に影響を及ぼすことができます。
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.
優先権Precedenceとして時々使用される: 標準的でなくて、どれに論議を呼んだ状態で影響を及ぼすことができるか、そして、伝送速度と配送を評価してください。. がっかりしています。 共通の価値観は、「大量で」「ファーストクラスです」。 他の用途は、自動返信を制御して、内容の復帰施設を制御して、メーリングリスト輪を止めることです。
Palme Informational [Page 13] RFC 2076 Internet Message Headers February 1997
[13ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
創始者からImportanceまでのヒント: RFC1911、メッセージがどれくらい重要であるかに関するRFC1327と受取人。 値: 高いか、標準実験的であるかまたは低いです。 以前はよくトランスミッション速度を制御していませんでした。
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.
Sensitivityを明らかにするのがどれくらい敏感であるか、: RFC1911以外の人々、指定された受取人へのRFC1327とこのメッセージ。 値: 個人的で、会社の秘密の実験用パーソナル。 X.400からgatewayedされたメッセージが、このヘッダーの不在は、メッセージが機密でないことを示します。
Body parts are missing. Incomplete- RFC 1327, not for
Copy: general usage.
身体の部分はなくなっています。 コピーでない不完全なRFC1327: 一般的な用法。
3.10 Language information
3.10 言語情報
Can include a code for the Language: RFC 1327, not for natural language used in a general usage. message, e.g. "en" for English.
Languageのためのコードを含むことができます: 自然言語が一般的な用法で. メッセージ、例えば、英語のための「アン」を使用しなかったのでRFC1327。
Can include a code for the Content- RFC 1766, proposed natural language used in a Language: standard. message, e.g. "en" for English.
Content- RFC1766のためのコード、Languageで使用される提案された自然言語は含むことができます: 規格メッセージ、例えば、英語のための「アン。」
3.11 Size information
3.11 サイズ情報
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.
Contentに標準的でない確信している郵送者によって挿入されて、Lengthのバイトで表現されるサイズを示してください: . メッセージ・テキストに水をさしていました。 メッセージをユーザに示しているとき、これは何人かの郵送者が使用する形式の一部です、そして、ネットを通してメッセージを送るとき、このヘッダーを使用するべきではありません。 メッセージの伝達におけるこのヘッダーの使用はいくつかの丈夫さと相互運用性問題を引き起こす場合があります。
Size of the message. Lines: RFC 1036: 2.2.12,
not standardized
for use in e-mail.
メッセージのサイズ。 線: RFC1036: 2.2.12 使用のために中で標準化されないで、メールしてください。
Palme Informational [Page 14] RFC 2076 Internet Message Headers February 1997
[14ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
3.12 Conversion control
3.12 変換コントロール
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.
このメッセージのボディーがそうしないかもしれない、Conversion: 1つのキャラクタの一般的な用法から変換されてください。RFC1327、別のものにセットしてください。 値: 禁止されていて、許容されています。
Non-standard variant of Content- Non-standard. Conversion: with the same values. Conversion:
Content標準的でないことの標準的でない異形。 変換: 同じ値で。 変換:
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.
このメッセージのボディーがそうしないかもしれない、Conversion- RFC1327、1回のキャラクタのWith-損失から、変換されてください: 一般的な用法情報が失われるなら、別のものにセットしてください。 値: 禁止されていて、許容されています。
3.13 Encoding information
3.13 情報をコード化すること。
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など)の形式 それに注意してください、RFC1123のための値: 5.2.13 このヘッダーはRFC1521で定義されます: 4. RFC1049とRFC1766の異なった道: 4.1 MIME(RFC1521)(「MIMEバージョン」ヘッダーがコンテントタイプがRFC1049かMIMEによると、解釈されるかどうかことであることを理解する外観)。 MIME定義はメールを作る際に使用されるべきです。
RFC 1766 defines a parameter "difference" to this header.
RFC1766は「違い」というパラメタをこのヘッダーと定義します。
Information from the SGML entity Content-SGML- non-standard declaration corresponding to the Entity: entity contained in the body of the body part.
Entityに対応するSGML実体Content-SGML標準的でない宣言からの情報: 身体の部分のボディーに含まれた実体。
Coding method used in a MIME Content- RFC 1521: 5.
message body. Transfer-
Encoding:
コード化方法はMIMEにContent- RFC1521を使用しました: 5. メッセージ本体。 転送コード化します:
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.
値のMessage-タイプで中古だけ: どんな「配送レポート」のためのRFC1327でない、も表示、一般的な用法これが配送レポートであることはX.400からgatewayedされました。
Palme Informational [Page 15] RFC 2076 Internet Message Headers February 1997
[15ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.
いくつかの異なった方法でEncodingで使用される: aに関して、ちょっと実験的に内容でタイプしてください。RFC1154、異なったメールシステム或るものはRFC1505を使用します、それ. 情報、コード化と長さの情報のためのいくつか、一種の境界情報(他の方法でいくつか)のためのいくつか。
3.14 Resent-headers
3.14、ヘッダーに憤慨します。
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:,
Resent-
Message-ID:
手動でResent-回答RFC822を進めるとき: C.3.3メッセージ、いずれのオリジナルのResent-From:にもメッセージを転送しないで、To:について言及するヘッダー。 以下に注意してください。 MIMEはSenderを再送するResent別の方法を指定します: 通信して、「メッセージ」Resent-From:を使用することでのコンテントタイプ。 日付:に憤慨して、To:に憤慨して、cc:に憤慨して、bcc:に憤慨して、Message IDに憤慨してください:
3.15 Security and reliability
3.15 セキュリティと信頼性
Checksum of content to ensure Content-MD5: RFC 1864, proposed that it has not been modified. standard.
Content-MD5を確実にする内容のチェックサム: RFC、1864 それが変更されていないよう提案した、規格。
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.
店XrefにUsenet Newsで中古: RFC1036: 2.2.13 二度Usenet読者だけのaに同じ記事を示すのを避ける情報はNewsである、電子それでないところで1つ以上のメールニュースグループに送られませんでした。 1つのUsenet Newsサーバの中のローカルの用法のためだけに、サーバの間に送るべきではありません。
3.16 Miscellaneous
3.16 その他
Name of file in which a copy of Fcc: Non-standard. this message is stored.
ファイルについてFccのどのaコピーとコネを命名してくださいか: 標準的でなさ. このメッセージは格納されます。
Has been automatically forwarded. Auto- RFC 1327, not for
Forwarded: general usage.
自動的に、進めました。 自動RFC1327、進められる: 一般的な用法。
Palme Informational [Page 16] RFC 2076 Internet Message Headers February 1997
[16ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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拡大X400-IPMS一般的な用法を示してください。Discarded- RFC1327へのインターネット・メールで使用できる、どれはExtensionsに写像できなかったか: インターネットメール書式。
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拡大X400-MTS一般的な用法を示してください。Discarded- RFC1327へのインターネット・メールで使用できる、どれはExtensionsに写像できなかったか: インターネットメール書式。
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:
この分野はいくつかのメールStatusによって使用されます: 示す標準的でない配送システム、格納されて、決してこれのための配送の何か状態がメールに中に現れないなら、通信してください。 一般的なトランジットこの分野の値は以下の通りです。
U message is not downloaded
and not deleted.
Uメッセージは、ダウンロードされないで、また削除されません。
R message is read or
downloaded.
Rメッセージを読むか、またはダウンロードします。
O message is old but not
deleted.
○ メッセージは、古いのですが、削除されていません。
D to be deleted.
削除されるべきD。
N new (a new message also
sometimes is distinguished
by not having any "Status:"
header.
いずれも持たないことで時々新しいメッセージによっても区別されます。N新しい、(「状態:」 ヘッダー。
Combinations of these characters can occur, such as "Status: OR" to indicate that a message is downloaded but not deleted.
これらのキャラクタの組み合わせが起こることができる、「状態:」 メッセージをダウンロードしますが、削除しないのを示す「OR。」
Palme Informational [Page 17] RFC 2076 Internet Message Headers February 1997
[17ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
4. Acknowledgments
4. 承認
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.
ハラルドTveit Alvestrand、ネッド・フリード、オッレJdrnefors、キース・ムーア、ニック・スミス、および数人の他の人々がこのリストをコンパイルするのに私を助けました。 私は改良のための彼らの徹底的なレビューと多くの役立つ提案についてネッド・フリードとオッレJdrneforsに特に感謝します。 私だけがリストにまだあるどんな誤りへの責任も取ります。
An earlier version of this list has been published as part of [13].
このリストの以前のバージョンは[13]の一部として発行されました。
5. References
5. 参照
Ref. Author, title IETF status
(July 1996)
----- --------------------------------------------- -----------
[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
STD 10, RFC 821, August 1982. Recommended
審判。 作者、タイトルIETF状態(1996年7月)----- --------------------------------------------- ----------- [1] J.ポステル: 「簡単なメール転送プロトコル」、規格、STD10、RFC821、1982年8月。 推薦されます。
[2] D. Crocker: "Standard for the format of ARPA Standard,
Internet text messages." STD 11, RFC 822, Recommended
August 1982.
[2] D.クロッカー: 「ARPA Standardの形式、インターネット・テキスト・メッセージにおいて、標準です」。 STD11(RFC822)は1982年8月を推薦しました。
[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
[3] M.R.ホートン、R.アダムス: しかし、「offiが交換するUSENETメッセージのNotの規格」、RFC1036、cial IETF12月1987日の規格、ほんとうはUsenet Newsの反-facto規格
[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
[4] M.シルブ: 「Standardのためのコンテントタイプヘッダーヘッダー、インターネットメッセージ」、RFC1049、3月1988日 推薦されますが、将来、MIMEに取り替えられると予想できます。
[5] R. Braden (editor): "Requirements for Standard,
Internet Hosts -- Application and Support", Required
STD-3, RFC 1123, October 1989.
[5] R.ブレーデン(エディタ): 「標準のインターネットホストのための要件--、アプリケーションとサポート、」、必要なSTD-3、RFC1123、10月1989日
[6] D. Robinson, R. Ullman: "Encoding Header Non-standard
Header for Internet Messages", RFC 1154,
April 1990.
[6] D.ロビンソン、R.ウルマン: 「インターネットメッセージのためにヘッダーの標準的でないヘッダーをコード化します」、RFC1154、1990年4月。
Palme Informational [Page 18] RFC 2076 Internet Message Headers February 1997
[18ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
[7] S. Hardcastle-Kille: "Mapping between Proposed
X.400(1988) / ISO 10021 and RFC 822", RFC standard,
1327 May 1992. elective
[7] S.Hardcastle-Kille: 「Proposed X.400(1988)/ISO10021とRFC822インチ、RFC規格、1327年の5月の間で1992年の選択科目を写像すること。
[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.
[8] H.AlvestrandとJ.Romaguera: 「X.400/88から規格までのProposed Downgrading Messagesのための規則、X.400/84 When MIMEコンテントタイプはMessagesのPresent選択科目です」、RFC1496、1993年8月。
[9] A. Costanzo: "Encoding Header Header for Non-standard
Internet Messages", RFC 1154, April 1990.
[9] A.コスタンゾ: 「標準的でないインターネットメッセージのためにヘッダーヘッダーをコード化します」、RFC1154、1990年4月。
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
Header for Internet Messages", RFC 1505,
August 1993.
[10] A.コスタンゾ、D.ロビンソン: 「インターネットメッセージのためにヘッダーの実験的なヘッダーをコード化します」、RFC1505、1993年8月。
[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.
[11]N.Borensteinと解放されたN.: 「パート1をまねてください(多目的の草稿インターネットメール拡大)」 「規格、インターネットMessage BodiesのSpecifyingとDescribingの選挙のFormatのためのMechanisms」、RFC1521、9月1993日
[12] H. Alvestrand: "Tags for the Identification Proposed
of Languages", RFC 1766, February 1995. standard,
elective
[12] H.Alvestrand: 「LanguagesのIdentification Proposedのためのタグ」、RFC1766、標準の、そして、選挙の1995年2月
[13] J. Palme: "Electronic Mail", Artech House Non-standard
publishers, London-Boston January 1995.
[13] J.パルメ: 「電子メール」、Artechの下院のNon標準の出版社、ロンドン-ボストン1995年1月。
[14] R. Troost, S. Dorner: "Communicating Experimental
Presentation Information in Internet
Messages: The Content-Disposition Header",
RFC 1806, June 1995.
[14] R.Troost、S.デルナー: 「インターネットメッセージの実験プレゼンテーション情報を伝えます:」 「満足している気質ヘッダー」、RFC1806、1995年6月。
[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.
[15] B.カンター、P.ラプスリー、「ネットニュース転送はプロトコルを提案しました」。 「NewsのStreamの標準のBased TransmissionのためのProposed Standard」、RFC977、1986年1月。
[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed
S. Murphy, "MIME Object Security Services", standard
RFC 1848, March 1995.
[16]1848PS S.クロッカー、N.フリード、J.ガルビン、Proposed S.マーフィーは「物のセキュリティー・サービスをまねます」、標準のRFC1848、1995年3月。
[17] J. Myers, M. Rose: The Content-MD5 Header Draft
Header, RFC 1864, October 1995. standard
[17] J.マイアーズ、M.は上昇しました: Content-MD5 Header Draft Header、RFC1864、10月1995日の規格
Palme Informational [Page 19] RFC 2076 Internet Message Headers February 1997
[19ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
[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
しかし、ほんとうは、[18] M.ホートン、UUCPメール置き換え形式Notはoffi規格、RFC976、Januari1986cial IETF規格、Usenet Newsの反-facto規格です。
[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
[19] T.バーナーズ・リー、R.Headering、H.Frystyk: 公式のハイパーテキストTransferプロトコルでない--HTTP/1.0にもかかわらず、IETF規格にもかかわらず、RFC1945(1996年5月)にもかかわらず、事実上の次のバージョンまでの規格は発行されます。
[20] G. Vaudreuil: Voice Profile for Internet Experimental
Mail, RFC 1911, February 1996.
[20] G.ボードルイ: 1996年2月にインターネットの実験メール、RFC1911のためにプロフィールを声に出してください。
[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
[21] H.スペンサー: ニュースArticle FormatとNot、Transmissionさえ、1994年6月、RFC、FTP://zoo.toronto.edu/パブ/news.psだけがほとんどUsenet Newsにおける、factoに標準のa反-名の「RFC1036の息子」の下でまだ広くしばしば参照をつけられていますzoo.toronto.edu/パブ/news.txt.Zが使用したFTP://と一部Thisが、ドキュメントである。
6. Author's Address
6. 作者のアドレス
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
ヤコブパルメPhone: +46-8-16 16 67ストックホルム大学/KTH Fax: +46-8-783 08 29琥珀金230メール: Kista、 jpalme@dsv.su.se S-164 40スウェーデン
Palme Informational [Page 20] RFC 2076 Internet Message Headers February 1997
[20ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
Appendix A: Headers sorted by Internet RFC document in which they appear.
付録A: 彼らが現れるRFCが記録するインターネットによって割り当てられたヘッダー。
RFC 822 -------
RFC822-------
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
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 -------
RFC976-------
"From " (followed by space, not colon (:")
「」、(コロンではなく、スペースがあとに続いています。(:")
Palme Informational [Page 21] RFC 2076 Internet Message Headers February 1997
[21ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
RFC 1036 --------
RFC1036--------
Approved Control Distribution Expires Followup-To Lines Newsgroups Organization Path Summary Xref
承認されたコントロール分配が期限が切れる、追跡、-、ニュースグループ組織経路概要Xrefを裏打ちします。
RFC 1049 --------
RFC1049--------
Content-Type
コンテントタイプ
RFC 1327 --------
RFC1327--------
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
配送レポートを作っている自動進められた受取人を明らかにしている交互の受取人の重要性不完全なコピー言語メッセージタイプAutoforwarded満足している識別子満足しているリターン変換損失との変換納品日の捨てられたX400-IPMS拡張子捨てられたX400-MTS拡張子dl拡大歴史有効期限日の配送は不着損害レポートを防いでいる元のコード化された情報タイプ優先権うわさによれば回答感度を時代遅れにします。
Palme Informational [Page 22] RFC 2076 Internet Message Headers February 1997
[22ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
RFC 1505 --------
RFC1505--------
Encoding
コード化
RFC 1521 --------
RFC1521--------
Content-Description Content-ID Content-Transfer-Encoding Content-Type MIME-Version
満足している記述コンテントID満足している転送コード化コンテントタイプMIMEバージョン
RFC 1806 --------
RFC1806--------
Content-Disposition
満足している気質
RFC 1864 --------
RFC1864--------
Content-MD5
内容-MD5
RFC 1911 --------
RFC1911--------
Importance Sensitivity
重要性感度
son-of-RFC1036 [21] -------------------
RFC1036の息子[21]-------------------
Also-Control Article-Names Article-Updates See-Also Supersedes
-また、見ている記事最新版が取って代わる規制も記事名
Palme Informational [Page 23] RFC 2076 Internet Message Headers February 1997
[23ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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
「明らかである、-、Content-基地のContent-長さのContent-位置のContent SGML実体、Encoding Errors、-、Returnが領収書を出す、ファックス、「」、(続かない、」、:、」、)、コメントのためのテレファックスFcc取り扱いのためのメールシステムバージョン郵送者機構由来しているクライアント電話状態はX400の満足しているリターン未知のメーラーX-ニュースキャスターに取って代わります。
Palme Informational [Page 24] RFC 2076 Internet Message Headers February 1997
[24ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
Appendix B: Alphabetical index
付録B: アルファベット順索引
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.3が3.3Alternate-受取人3.4を制御する、Apparently、-、3.16が、3.4のbccの3.4ccのClientをAuto送って、また、コンテントID3.7Content-識別子3.10Content-言語が見るのをOriginating-クライアント3.7Comments3.6Content-基地の3.12Content-変換3.7Content-記述3.3Content-気質3.6に見る3.4Approved3.6のArticle-名前の3.6のArticle-アップデートLanguage3.11Content-長さの3.6Content-位置の3.15Content-MD5 3.4Content-リターン3.13Content SGML実体3.13Content転送コード化3; 3.8Delivery-日付がDelivery報告する13コンテントタイプ3.3Control3.12Conversion3.12損失を伴うConversion3.8Date、配送レポート、Non配送レポート、コンテントタイプ記述がContent-記述3.16Discarded-X400-IPMS-拡大3.16Discarded-X400-MTS-拡大3.3に見るPrevent Disclose-受取人Disposition、Generate配送レポートを見てくださいといって、また、Content-気質3.4Distribution3.2DL拡大歴史指示3.13EncodingがContent転送コード化3.4を見るのを見てください、Errors、-
Palme Informational [Page 25] RFC 2076 Internet Message Headers February 1997
[25ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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.8が期限が切れる、ExtensionはDiscarded-X400-IPMS-拡大を見ます、Discarded- X400-MTS-拡大3.4ファックス3.16Fcc3.4、Followup、-、Forwarded、Autoによって進められた3.4For-コメント3.4For-取り扱い3.4From3を見てください; 配送レポートを作っている4歴史、DL拡大歴史Indication IDを見てください、とコンテントIDとMessage-ID Identifierは見ます、とコンテントIDとMessage-ID3.9Importance3.6が見る、Inが答える、3.9 Incomplete-コピー3.7に、Keywords3.10Languageは見て、また、Content-言語Lengthは、また、Content-長さの3.11の線3.4メールシステムバージョンがX-郵送者3を見るのを見ます; 4郵送者MD5はContent-MD5 3.6Message-ID3.13Message-タイプ3.3MIMEバージョン3.4にニュースグループNewsreaderを見て、Originalが情報タイプをコード化しているX-ニュースキャスター3.6Obsoletes3.7Organisation3.7Organization3.3 3.4Originating-クライアント3.2Path3.4電話3.9Precedence3.4Prevent-NonDelivery-レポート3.9にPriority3.2Received Recipientを見てください、とToは見ます、cc、bcc、近くDisclose受取人3.6References3.8Reply、Alternate-受取人、3.4、Reply、-、また、見てください、Inが答える、Resentが返すReferences3.14は見ます。 Content-リターン3.2Return-経路も
Palme Informational [Page 26] RFC 2076 Internet Message Headers February 1997
[26ページ]RFC2076インターネットメッセージヘッダー1997年2月の情報のパルメ
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
3.5、領収書を返す、3.6Seeも3.4Sender3.9Sensitivity3.16Status3.7Subject3.7Summary3.6Supersedes3.4Telefax、3.4がTo Transferコード化される、メールシステムバージョン3.4X-ニュースキャスター3.15Xrefは、Content転送コード化Typeが、コンテントタイプ、Message-タイプ、情報タイプがOriginalによってコード化されたバージョンが、また、MIMEバージョン、X400がリターンを満足させている未知のメーラー3.4 3.4未知のメーラーが見るのを見るのを見るのを見ます。
Palme Informational [Page 27]
パルメInformationalです。[27ページ]
一覧
スポンサーリンク
