5. Security Considerations
セキュリティに関する考察
Care needs to be taken when displaying messages on a terminal or terminal emulator. Powerful terminals may act on escape sequences and other combinations of ASCII control characters with a variety of consequences. They can remap the keyboard or permit other modifications to the terminal which could lead to denial of service or even damaged data. They can trigger (sometimes programmable) answerback messages which can allow a message to cause commands to be issued on the recipient's behalf. They can also effect the operation of terminal attached devices such as printers. Message viewers may wish to strip potentially dangerous terminal escape sequences from the message prior to display. However, other escape sequences appear in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, ISO2022]) and therefore should not be stripped indiscriminately.
注意は端末またはターミナルエミュレータの上のメッセージを表示する時に、払われる必要があります。強力な端末はさまざまな結果によってエスケープシーケンスとASCII制御文字の他のコンビネーションに作用するかもしれません。それらはすることができて 郡区画改正 キーボード か、または役立つ拒否を引き起こしているかもしれないか、またはデータを損いさえした端末に他の修正を許します。彼らは、コマンドを起こすメッセージが受領者のために発行されることを可能にすることができるアンサバックメッセージを引き起こす(時々プログラマブルです)ことができます。それらはプリンタなどの端末の付着したデバイスを動作させることもできます。メッセージビュアーは、ディスプレイに先がけて潜在的に危険な端末のエスケープシーケンスをメッセージからはぐことを望むかもしれません。しかし、他のエスケープシーケンスは有益な目的(cfのためにメッセージの中で出現します。 [RFC2045、RFC2046、RFC2047、RFC2048、RFC2049、ISO2022])および無差別に取り除かれるべきではありません。
Transmission of non-text objects in messages raises additional security issues. These issues are discussed in [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049].
メッセージの中の非テキストオブジェクトのトランスミッションは追加のセキュリティ問題を上げます。これらの問題は[RFC2045、RFC2046、RFC2047、RFC2048、RFC2049]において議論されます。
Many implementations use the "Bcc:" (blind carbon copy) field described in section 3.6.3 to facilitate sending messages to recipients without revealing the addresses of one or more of the addressees to the other recipients. Mishandling this use of "Bcc:" has implications for confidential information that might be revealed, which could eventually lead to security problems through knowledge of even the existence of a particular mail address. For example, if using the first method described in section 3.6.3, where the "Bcc:" line is removed from the message, blind recipients have no explicit indication that they have been sent a blind copy, except insofar as their address does not appear in the message header. Because of this, one of the blind addressees could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. When the second method from section 3.6.3 is used, the blind recipient's address appears in the "Bcc:" field of a separate copy of the message. If the "Bcc:" field sent contains all of the blind addressees, all of the "Bcc:" recipients will be seen by each "Bcc:" recipient. Even if a separate message is sent to each "Bcc:" recipient with only the individual's address, implementations still need to be careful to process replies to the message as per section 3.6.3 so as not to accidentally reveal the blind recipient to other recipients.
多くの実装は、他の受領者に受信者の1人以上のアドレスを明らかにせずにメッセージを受領者に送信して、容易にするセクション3.6.3中で説明された「Bcc:」(盲目の写し)フィールドを使います。明らかにされるかもしれず、結局特定のメール・アドレスの存在さえに関する知識を通してセキュリティ問題をもたらすことができた機密情報のために、「Bcc:」のこの使用を誤って取り扱うことは含意を持っています。例えば、セクション3.6.3(そこで、「Bcc:」ラインはメッセージから削除されます)中で説明された最初の方法を使うならば、目が不自由な受領者は、彼らのアドレスがメッセージヘッダの中で出現しないことへのを除いて、彼らがブラインドコピーを送信されているという明示的な徴候を全然持っていません。これのため、目が不自由な受信者の1人は、潜在的に返答を示された受領者のすべてに送信し、偶然、メッセージが目が不自由な受領者に行ったと明らかにすることができました。セクション3.6.3からの2番目の方法が使われる時に、目が不自由な受領者のアドレスはメッセージの別個のコピーの「Bcc:」フィールドに出ます。 送られた「Bcc:」フィールドが目が不自由な受信者のすべてを含んでいるならば、「Bcc:」受領者のすべては各「Bcc:」受領者によって見られるでしょう。別個のメッセージが個人のアドレスだけによって各「Bcc:」受領者に送信されても、他の受領者に偶然目が不自由な受領者を明らかにしないためのセクション3.6.3に従って、実装はまだ、メッセージに返答を処理するように注意している必要があります。
6. Bibliography
文献目録
- [ASCII] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986.
- [ISO2022] International Organization for Standardization (ISO), Information processing - ISO 7-bit and 8-bit coded character sets - Code extension techniques, Third edition - 1986-05-01, ISO 2022, 1986.
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
- [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
- [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Format of Internet Message Bodies", RFC 2048, November 1996.
- [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, March 2001.
- [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC 1123, October 1989.
- [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, September 1989.
- [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and RFC 1035, November 1987.
- [STD14] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.
7. Editor's Address
奥付
- Peter W. Resnick
- QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
USA
Phone: +1 858 651 4478
Fax: +1 858 651 1102
EMail: presnick@qualcomm.com
8. Acknowledgements
承認
Many people contributed to this document. They included folks who participated in the Detailed Revision and Update of Messaging Standards (DRUMS) Working Group of the Internet Engineering Task Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and people who simply sent their comments in via e-mail. The editor is deeply indebted to them all and thanks them sincerely. The below list includes everyone who sent e-mail concerning this document. Hopefully, everyone who contributed is named here:
多くの人々はこの文書に寄与していました。それらは、インターネット技術特別調査委員会(IETF)のメッセージで送る標準(DRUMS)作業グループ(DRUMS、IETFのエリアディレクター、および単に、Eメール経由で彼らのコメントを提出した人々の椅子)の詳細なリビジョンとアップデートに参加した人々を含みました。エディタはそれらすべてに深く恩を受けていて、心からそれらに感謝します。リストの下のTheは、この文書について電子メールを送った誰でも含みます。希望的に、寄与していた誰もがここと名付けられます:
Matti Aarnio Barry Finkel Larry Masinter Tanaka Akira Erik Forsberg Denis McKeon Russ Allbery Chuck Foster William P McQuillan Eric Allman Paul Fox Alexey Melnikov Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger Ran Atkinson Ned Freed Steven Miller Jos Backus Jochen Friedrich Keith Moore Bruce Balden Randall C. Gellens John Gardiner Myers Dave Barr Sukvinder Singh Gill Chris Newman Alan Barrett Tim Goodwin John W. Noerenberg John Beck Philip Guenther Eric Norman J. Robert von Behren Tony Hansen Mike O'Dell Jos den Bekker John Hawkinson Larry Osterman D. J. Bernstein Philip Hazel Paul Overell James Berriman Kai Henningsen Jacob Palme Norbert Bollow Robert Herriot Michael A. Patton Raj Bose Paul Hethmon Uzi Paz Antony Bowesman Jim Hill Michael A. Quinlan Scott Bradner Paul E. Hoffman Eric S. Raymond Randy Bush Steve Hole Sam Roberts Tom Byrer Kari Hurtta Hugh Sasse Bruce Campbell Marco S. Hyman Bart Schaefer Larry Campbell Ofer Inbar Tom Scola W. J. Carpenter Olle Jarnefors Wolfgang Segmuller Michael Chapman Kevin Johnson Nick Shelness Richard Clayton Sudish Joseph John Stanley Maurizio Codogno Maynard Kang Einar Stefferud Jim Conklin Prabhat Keni Jeff Stephenson R. Kelley Cook John C. Klensin Bernard Stern Steve Coya Graham Klyne Peter Sylvester Mark Crispin Brad Knowles Mark Symons Dave Crocker Shuhei Kobayashi Eric Thomas Matt Curtin Peter Koch Lee Thompson Michael D'Errico Dan Kohn Karel De Vriendt Cyrus Daboo Christian Kuhtz Matthew Wall Jutta Degener Anand Kumria Rolf Weber Mark Delany Steen Larsen Brent B. Welch Steve Dorner Eliot Lear Dan Wing Harold A. Driscoll Barry Leiba Jack De Winter Michael Elkins Jay Levitt Gregory J. Woodhouse Robert Elz Lars-Johan Liman Greg A. Woods Johnny Eriksson Charles Lindsey Kazu Yamamoto Erik E. Fair Pete Loshin Alain Zahm Roger Fajman Simon Lyall Jamie Zawinski Patrik Faltstrom Bill Manning Timothy S. Zurcher Claus Andre Farber John Martin
Appendix A. Example messages
付録A メッセージの例
This section presents a selection of messages. These are intended to assist in the implementation of this standard, but should not be taken as normative; that is to say, although the examples in this section were carefully reviewed, if there happens to be a conflict between these examples and the syntax described in sections 3 and 4 of this document, the syntax in those sections is to be taken as correct.
このセクションはメッセージの選択を示します。これらは、この標準の実装を補助することを意図しているけれども、基準を立てているように、とられるべきでありません; すなわち このセクションの例が慎重にレビューされた 偶然そこでこれらの例の間の競合である およびこの文書のセクション3と4で説明された全規則、それらのセクションの全規則は、正しいので、取られる必要があります。
Messages are delimited in this section between lines of "----". The "----" lines are not part of the message itself.
メッセージはそれのラインの間のこのセクションにおいて区切られます「----」。「----」ラインはメッセージ自身の一部ではありません。
A.1. Addressing examples
アドレス書きの例
The following are examples of messages that might be sent between two individuals.
以下は、2人の個人の間に送信されるかもしれないメッセージの例です。
A.1.1. A message from one person to another with simple addressing
ある人から別の人への、単純なアドレス書きのメッセージ
This could be called a canonical message. It has a single author, John Doe, a single recipient, Mary Smith, a subject, the date, a message identifier, and a textual message in the body.
これは正規のメッセージと呼ばれることができました。それはボディの中で1人の著者、姓名不詳男性、1人の受領者、メアリー・スミス、主体、デート、メッセージ識別子、および原文のメッセージをします。
---- From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
If John's secretary Michael actually sent the message, though John was the author and replies to this message should go back to him, the sender field would be used:
ジョンがその著者であり、このメッセージへの返答が彼に帰るべきであるけれども、ジョンの秘書マイケルが実際メッセージを送ったならば、送信側フィールドは使われるでしょう:
---- From: John Doe <jdoe@machine.example> Sender: Michael Jones <mjones@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
A.1.2. Different types of mailboxes
異なる種類のメールボックス
This message includes multiple addresses in the destination fields and also uses several different forms of addresses.
このメッセージは複数アドレスを宛先フィールドに含めていて、また、いくつかの違う敬称を使います。
---- From: "Joe Q. Public" <john.q.public@example.com> To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test> Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net> Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone. ----
Note that the display names for Joe Q. Public and Giant; "Big" Box needed to be enclosed in double-quotes because the former contains the period and the latter contains both semicolon and double-quote characters (the double-quote characters appearing as quoted-pair construct). Conversely, the display name for Who? could appear without them because the question mark is legal in an atom. Notice also that jdoe@example.org and boss@nil.test have no display names associated with them at all, and jdoe@example.org uses the simpler address form without the angle brackets.
ディスプレイがジョーQ.Publicと巨人のために名付けることに注意してください; 前者がピリオドを含んでいて、後者がセミコロンとダブルクォートキャラクタ(引用されるペアのコンストラクトとして表れているダブルクォートキャラクタ)両方を含んでいるので、「大きな」ボックスは、ダブルクォートに同封される必要がありました。逆に、疑問符が最小識別単位の中で正当なので、Who?のためのディスプレイ名はそれらなしで出現することができました。jdoe@example.orgとboss@nil.testが全くそれらと関連づけられたディスプレイ名を全然持っていなく、jdoe@example.orgが角ブラケットなしでより簡単なアドレス形式を使うことにまた気づいてください。
A.1.3. Group addresses
グループアドレス
---- From: Pete <pete@silly.example> To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>; Cc: Undisclosed recipients:; Date: Thu, 13 Feb 1969 23:32:54 -0330 Message-ID: <testabcd.1234@silly.example> Testing. ----
In this message, the "To:" field has a single group recipient named A Group which contains 3 addresses, and a "Cc:" field with an empty group recipient named Undisclosed recipients.
このメッセージの中に、「To:」フィールドは、3つのアドレスを含んでいるAグループと名付けられた1人のグループ受領者を持っていて、空のグループ受領者との「Cc:」フィールドは未公開の受領者を名付けました。
A.2. Reply messages
返信メッセージ
The following is a series of three messages that make up a conversation thread between John and Mary. John firsts sends a message to Mary, Mary then replies to John's message, and then John replies to Mary's reply message.
以下は、ジョンとメアリーの間で会話スレッドを作る一連の3つのメッセージです。1番目のジョンはメッセージをメアリーに送信し、メアリーはその時ジョンのメッセージに答えて、それから、ジョンはメアリーの返答メッセージに答えます。
Note especially the "Message-ID:", "References:", and "In-Reply-To:" fields in each message.
各メッセージの中で特に「Message-ID:」、「Refernces:」、および「In-Reply-To:」フィールドに言及してください。
---- From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
When sending replies, the Subject field is often retained, though prepended with "Re: " as described in section 3.6.5.
返答を送る時に、セクション3.6.5中で説明されるように「Re:」が先行して現れるけれども、サブジェクトフィールドはしばしば保持されています。
---- From: Mary Smith <mary@example.net> To: John Doe <jdoe@machine.example> Reply-To: "Mary Smith: Personal Account" <smith@home.example> Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 10:01:10 -0600 Message-ID: <3456@example.net> In-Reply-To: <1234@local.machine.example> References: <1234@local.machine.example> This is a reply to your hello. ----
Note the "Reply-To:" field in the above message. When John replies to Mary's message above, the reply should go to the address in the "Reply-To:" field instead of the address in the "From:" field.
「次をする返答:」フィールドに上記のメッセージの中で注目してください。ジョンが上でメアリーのメッセージに答える時に、返答は、「次をする返答:」フィールドのアドレスを「送信者:」フィールドのアドレスの代わりに訪ねるべきです。
---- To: "Mary Smith: Personal Account" <smith@home.example> From: John Doe <jdoe@machine.example> Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 11:00:00 -0600 Message-ID: <abcd.1234@local.machine.tld> In-Reply-To: <3456@example.net> References: <1234@local.machine.example> <3456@example.net> This is a reply to your reply. ----
A.3. Resent messages
再送メッセージ
Start with the message that has been used as an example several times:
例として何度か使用されたメッセージから始めます。
---- From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
Say that Mary, upon receiving this message, wishes to send a copy of the message to Jane such that (a) the message would appear to have come straight from John; (b) if Jane replies to the message, the reply should go back to John; and (c) all of the original information, like the date the message was originally sent to Mary, the message identifier, and the original addressee, is preserved. In this case, resent fields are prepended to the message:
メッセージが、ジョンからまっすぐに来たようであろうように、メアリーが、このメッセージを受け取るとすぐに、メッセージのコピーをジェーンに送信することを望むと言ってください; ジェーンが、メッセージに、返答がジョンに帰るべきであると答えるならば(b); そして(c)、メッセージが元来メアリー、メッセージ識別子、およびオリジナルの受信者に送信された日付のようなオリジナルの情報のすべては保存されます。このケースにおいて、再送フィールドがメッセージに先行します:
---- Resent-From: Mary Smith <mary@example.net> Resent-To: Jane Brown <j-brown@other.example> Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 Resent-Message-ID: <78910@example.net> From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
If Jane, in turn, wished to resend this message to another person, she would prepend her own set of resent header fields to the above and send that.
ジェーンが今度は、別の人へのこのメッセージを再送付するために、彼女がするだろうことを望んだか彼女自身の再送付されたヘッダーのセットが上記に守備につけるprependそして、それを送って下さい。
A.4. Messages with trace fields
トレースフィールドつきメッセージ
As messages are sent through the transport system as described in [RFC2821], trace fields are prepended to the message. The following is an example of what those trace fields might look like. Note that there is some folding white space in the first one since these lines can be long.
[RFC2821]において説明されるように、メッセージが輸送システムを通して送られる時に、トレースフィールドはメッセージの先頭に付与されます。以下は、それらのトレースフィールドが見えるかもしれないものの例です。これらの行が長いかもしれないので、最初のものにおいてある折りたためる空白類があることに注意してください。
---- Received: from x.y.test by example.net via TCP with ESMTP id ABC12345 for <mary@example.net>; 21 Nov 1997 10:05:43 -0600 Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600 From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
A.5. White space, comments, and other oddities
ホワイトスペース、コメント、その他のもの
White space, including folding white space, and comments can be inserted between many of the tokens of fields. Taking the example from A.1.3, white space and comments can be inserted into all of the fields.
空白類を折りたたむのを含む空白類とコメントはフィールドのトークンの多くの間で挿入されることができます。A.1.3、空白類、およびコメントから例をとることはフィールドのすべてに挿入されることができます。
---- From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)> To:A Group(Some people) :Chris Jones <c@(Chris's host.)public.example>, joe@example.org, John <jdoe@one.test> (my dear friend); (the end of the group) Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; Date: Thu, 13 Feb 1969 23:32 -0330 (Newfoundland Time) Message-ID: <testabcd.1234@silly.test> Testing. ----
The above example is aesthetically displeasing, but perfectly legal. Note particularly (1) the comments in the "From:" field (including one that has a ")" character appearing as part of a quoted-pair); (2) the white space absent after the ":" in the "To:" field as well as the comment and folding white space after the group name, the special character (".") in the comment in Chris Jones's address, and the folding white space before and after "joe@example.org,"; (3) the multiple and nested comments in the "Cc:" field as well as the comment immediately following the ":" after "Cc"; (4) the folding white space (but no comments except at the end) and the missing seconds in the time of the date field; and (5) the white space before (but not within) the identifier in the "Message-ID:" field.
上記の例は美的に不快であるけれども、完全に正当です。特に言及してください。 (1) 引用されました-ペア)の一部として表れている「送信者:」、フィールド (「aを持っている含む人」)インチのキャラクタの中のコメント; (2) コメントと同様に「To:」フィールドの「:」後で休んでいて、「joe@example.org」前と後にグループ名、クリス ジョーンズのアドレスの中のコメントの中の特殊文字(".")、および折りたためる空白類の後で空白類を折りたたんでいる空白類; (3)「Cc」後の「:」に続いて、「Cc:」における複数で、入れ子にされたコメントは直ちにコメントと同様に守備につきます; (4) 日付フィールドの時の折りたためる空白類(しかし終わりのを除いた無コメント)と行方不明のセカンド; そして (5)「Message-ID:」フィールドの識別子の前(しかし中でない)空白類。
A.6. Obsoleted forms
廃れたフォーム
The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document.
以下は、この文書のセクション4中で説明された、廃れた(すなわち、「生成してはなりません」)構文要素の例です。
A.6.1. Obsolete addressing
廃れたアドレス書き
Note in the below example the lack of quotes around Joe Q. Public, the route that appears in the address for Mary Smith, the two commas that appear in the "To:" field, and the spaces that appear around the "." in the jdoe address.
下例 ジョーQ.大衆のまわりの引用文不足する、メアリースミスのためのアドレスに出現するルート、「します:」フィールドに出る2つのカンマ、jdoeアドレスの「.」のまわりに出現するスペース において言及してください。
---- From: Joe Q. Public <john.q.public@example.com> To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone. ----
A.6.2. Obsolete dates
廃れた日時
The following message uses an obsolete date format, including a non-numeric time zone and a two digit year. Note that although the day-of-week is missing, that is not specific to the obsolete syntax; it is optional in the current syntax as well.
数値でないタイムゾーンと2桁の年を含めて、以下のメッセージは廃れた日付の形式を使います。週の日が行方不明であるけれども、それが廃れた全規則に特定でないことに注意してください; それはその上現在の全規則の中でオプションです。
---- From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: 21 Nov 97 09:55:06 GMT Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ----
A.6.3. Obsolete white space and comments
廃れたホワイトスペースとコメント
White space and comments can appear between many more elements than in the current syntax. Also, folding lines that are made up entirely of white space are legal.
空白類とコメントは現在の全規則の中より多くのエレメントの間で出現することができます。また、完全に空白類からなる折りたためるラインは正当です。
---- From : John Doe <jdoe@machine(comment). example> To : Mary Smith __ <mary@example.net> Subject : Saying Hello Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 Message-ID : <1234 @ local(blah) .machine .example> This is a message just to say hello. So, "Hello". ----
Note especially the second line of the "To:" field. It starts with two space characters. (Note that "__" represent blank spaces.) Therefore, it is considered part of the folding as described in section 4.2. Also, the comments and white space throughout addresses, dates, and message identifiers are all part of the obsolete syntax.
「To:」フィールドの特に2番目のラインに注目してください。それは2つの間隔文字によって起動します。(「__」が空白を表していることに注意してください。) 従って、セクション4.2中で説明されるように、それは折りたための一部と考えられます。また、アドレス、日付、およびメッセージ識別子にわたるコメントと空白類はすべて廃れた全規則の一部です。
Appendix B. Differences from earlier standards
付録B 古い標準からの変更点
This appendix contains a list of changes that have been made in the Internet Message Format from earlier standards, specifically [RFC822] and [STD3]. Items marked with an asterisk (*) below are items which appear in section 4 of this document and therefore can no longer be generated.
この付録は、より早い標準、特に[RFC822]、および[STD3]からインターネットメッセージフォーマットの中で起こされている変化のリストを含んでいます。下でアスタリスク(*)をつけられたアイテムは、この文書のセクション4に出て、従ってもう、生成されることができないアイテムです。
-
Period allowed in obsolete form of phrase.
ピリオドはフレーズの廃れた形式において許しました。
-
ABNF moved out of document to [RFC2234].
ABNFは[RFC2234]に移動しました。
-
Four or more digits allowed for year.
4桁以上の年を考慮しました。
-
Header field ordering (and lack thereof) made explicit.
明示的にされたヘッダーフィールドオーダリング(そしてそれの不足)。
-
Encrypted header field removed.
削除された暗号化されたヘッダーフィールド。
-
Received syntax loosened to allow any token/value pair.
どのようなトークン/値でもペアになると認めるために、受け取られた全規則は緩んでいました。
-
Specifically allow and give meaning to "-0000" time zone.
特に、「-0000」タイムゾーンに意味を許し、与えてください。
-
Folding white space is not allowed between every token.
折りたためる空白類はすべてのトークンの間で許されるわけではありません。
-
Requirement for destinations removed.
削除された宛先のための要件。
-
Forwarding and resending redefined.
転送と再送は再定義しました。
-
Extension header fields no longer specifically called out.
拡張ヘッダーフィールドはもう特に大声で呼び掛けませんでした。
-
ASCII 0 (null) removed.*
ASCII0(空白)を削除しました。 *
-
Folding continuation lines cannot contain only white space.*
折りたためる継続行は空白類だけを含むことができません。*
-
Free insertion of comments not allowed in date.*
日付中、コメントを自由に挿入することが許されません *
-
Non-numeric time zones not allowed.*
許容されなかった非数値の時間帯。 *
-
Two digit years not allowed.*
2桁の年が許されません *
-
Three digit years interpreted, but not allowed for generation.
3桁の年は通訳したけれども、世代を見込まれませんでした。 *
-
Routes in addresses not allowed.*
アドレス中、経路は許されない *
-
CFWS within local-parts and domains not allowed.*
ローカルパートとドメインの中のCFWSは許容されなかった。 *
-
Empty members of address lists not allowed.*
メンバーからリストが許容しなかったアドレスを取り出してください。 *
-
Folding white space between field name and colon not allowed.*
許容されなかったフィールド名とコロンの間の余白を折り重ねます。 *
-
Comments between field name and colon not allowed.
許容されなかったフィールド名とコロンの間のコメント。 *
-
Tightened syntax of in-reply-to and references.*
in-reply-toとreferencesの構文が厳しくなった *
-
CFWS within msg-id not allowed.*
msg-id中、CFWSは許可されません
-
Tightened semantics of resent fields as informational only.
再送フィールドの意義が、情報のみと厳しくなりました。
-
Resent-Reply-To not allowed.*
Resent-Reply-Toは許可されません。 *
-
No multiple occurrences of fields (except resent and received).*
(resent と receivedを除き)フィールドは複数回出現してはいけません。 *
-
Free CR and LF not allowed.*
単独のCRやLFは許可されません。 *
-
Routes in return path not allowed.*
返信パスに経路が許可されません。 *
-
Line length limits specified.
行の長さの制限を規定しました。
-
Bcc more clearly specified.
Bcc をより明確に規定しました。
Appendix C. Notices
通知
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
どのような知的所有権またはこの文書またはそのような権利の下のどのようなライセンスでも使用可能であるはずがないか、かもしれないエクステントの中で説明された技術の実装または使用に付随すると主張されるかもしれない他の権利の妥当性または範囲についても、IETFはポジションを全然とりません; それはまた、それが、そのような権利を識別するどのような努力でもしたことを説明しません。標準トラックと標準に関連したドキュメンテーションの権利についてのIETFの手続についての情報はBCP-11において発見されることができます。出版のために使用可能にされた権利の主張と使用可能にされるライセンスのすべての保証またはこの仕様の作成者またはユーザによるそのような所有権の使用のために一般のライセンスまたは許可を得るようにされた試みの結果のコピーはIETF事務局から得られることができます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それのこの文書と翻訳は、コピーされて、コメントするか、違った形で、それを説明する他と微分の作品に供給されるかもしれないか、上記の著作権表示とこの段落がすべてのそのようなコピーと微分の作品の上に含まれるならば、その実装の中のアシストはあらゆる種類の制限なしで全体においてまたは部分で準備されて、コピーされて、出版されて、分配されるかもしれません。発展するために必要であるように、ケースの中で、インターネット標準の中で定義された著作権のための手続が処理するインターネット標準に続いていなければならない以外またはそれを英語以外の言語に翻訳することを要求されるように、しかしこの文書自身は、インターネットソサエティまたは他のインターネット組織への著作権表示またはリファレンスを削除することによるなどどのような点でも修正されないかもしれません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に与えられた制限された許可は永久で、インターネットソサエティまたはその後継者または譲り請け人によって撤回されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、「による、ありか」ベースとインターネット社会の上で提供されて、インターネットエンジニアリングタスクフォースはすべての保証、急行を否認するか、暗示されていて、情報の使用がここに犯さないであろうどのような保証でも含めて、どのような権利または何でも特定の目的のための市販能力またはフィットネスの保証を暗示していました。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。