Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below.

オプションであるけれども、すべてのメッセージは「メッセージID：」フィールドを持つべきです。さらに、メッセージが下で説明されるのと同じくらい適切な「次への返答において：」と「リファレンス：」フィールドを持つべきであると答えてください。

The "Message-ID:" field contains a single unique message identifier. The "References:" and "In-Reply-To:" field each contain one or more unique message identifiers, optionally separated by CFWS.

「Message-ID:」フィールドは1つの唯一のメッセージ識別子を含んでいます。「References:」「In-Reply-To:」とフィールドはCFWSによってオプションで分離された1つ以上の唯一のメッセージ識別子をそれぞれ含んでいます。

The message identifier (msg-id) is similar in syntax to an angle-addr construct without the internal CFWS.

メッセージ識別子(msg-id)は構文において鍵括弧、「<」、および「>」で閉じられたaddr-specから空白群を除いたものと同様です。

The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it (see below). This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers.

「Message-ID:」フィールドは、特定のメッセージの特定のバージョンを参照する唯一のメッセージ識別子を提供します。メッセージ識別子の独自性は、それ(下で見てください)を生成するホストによって保証されています。このメッセージ識別子は、必ずしも人に有意味であることではなく機械可読であることを意図しています。メッセージ識別子は特定のメッセージのちょうど1回の例示に付随しています； メッセージへのその後のリビジョンは新しいメッセージ識別子をそれぞれ受け取ります。

The "In-Reply-To:" and "References:" fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages (for example, in the case of a reply to a message which was itself a reply). The "In-Reply-To:" field may be used to identify the message (or messages) to which the new message is a reply, while the "References:" field may be used to identify a "thread" of conversation.

「In-Reply-To:」や「References:」フィールドはメッセージへの返答を作成する時に使われます。彼らは、オリジナルのメッセージのメッセージ識別子と他のメッセージ(例えば、自身、返答であったメッセージへの返答の場合)のメッセージ識別子を保持します。「In-Reply-To:」フィールドは、「References:」フィールドが、会話の「スレッド」を識別するために使われるかもしれない間、新しいメッセージが返答であるメッセージ(またはメッセージ)を識別するために使われるかもしれません。

When creating a reply to a message, the "In-Reply-To:" and "References:" fields of the resultant message are constructed as follows:

メッセージへの返答を作成する時に、その結果生じるメッセージの「In-Reply-To:」と「References:」フィールドは次の通り構成されます：

The "In-Reply-To:" field will contain the contents of the "Message-ID:" field of the message to which this one is a reply (the "parent message"). If there is more than one parent message, then the "In-Reply-To:" field will contain the contents of all of the parents' "Message-ID:" fields. If there is no "Message-ID:" field in any of the parent messages, then the new message will have no "In-Reply-To:" field.

「In-Reply-To:」フィールドは、これが返答(「親メッセージ」)であるメッセージの「Message-ID:」フィールドの内容を含むでしょう。複数の親メッセージがあるならば、「In-Reply-To:」フィールドは親の「Message-ID:」フィールドのすべての内容を含むでしょう。親メッセージのいくつかの中に「Message-ID:」フィールドが全然ないならば、新しいメッセージは「In-Reply-To:」フィールドを全然持たないでしょう。

The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). If the parent message does not contain a "References:" field but does have an "In-Reply-To:" field containing a single message identifier, then the "References:" field will contain the contents of the parent's "In-Reply-To:" field followed by the contents of the parent's "Message-ID:" field (if any). If the parent has none of the "References:", "In-Reply-To:", or "Message-ID:" fields, then the new message will have no "References:" field.

「Refernces:」フィールドは親の「Message-ID:」フィールド(もしあれば)の内容が後に続く親の「Refernces:」フィールド(もしあれば)の内容を含むでしょう。親メッセージが「Refernces:」フィールドを含んでいないけれども1つのメッセージ識別子を含んでいる「In-Reply-To:」フィールドを持っているならば、「Refernces:」フィールドは親の「Message-ID:」フィールド(もしあれば)の内容が後に続く親の「In-Reply-To:」フィールドの内容を含むでしょう。親が「Refernces:」、「In-Reply-To:」、または「Message-ID:」フィールドを拒否するならば、新しいメッセージは「Refernces:」フィールドを全然持たないでしょう。

The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this. Since the msg-id has a similar syntax to angle-addr (identical except that comments and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right hand side of the "@", and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left hand side. Using a date on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts use the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain.

メッセージ識別子(msg-id)自身はメッセージのためのグローバルに一意の名前であるにちがいありません。メッセージ識別子のジェネレータは、msg-idが唯一であると保証しなければなりません。これを遂行するために使われることができるいくつかのアルゴリズムがあります。角度addr(コメントと折りたためる空白類が許されない以外同一です)に、msg-idが同様な全規則を持つので、よい方法は、メッセージ識別子が「@」の右手側で作成されたホストのドメインネーム(またはドメインリテラルIPアドレス)を置き、左手側の上のシステム(例えばプロセスID番号)上で使用可能な他の現在唯一の(たぶん順次)識別子とともに現在の絶対の日付と時刻のコンビネーションを置くことです。左手側とドメインネームの上の日付または右手側の上のドメインリテラルを使うことは、どの2人のホストも同時に同じドメインネームまたはIPアドレスを使わないと独自性に以来保証することを可能にします。他のアルゴリズムが作業するであろうけれども、メッセージ識別子のジェネレータがそのドメインの範囲の中で左手側の独自性を保証することができるように、右手側がいくらかのドメイン識別子(ホスト自身のまたは違った形で)を含んでいることは勧められます。

Semantically, the angle bracket characters are not part of the msg-id; the msg-id is what is contained between the two angle bracket characters.

鍵括弧(<、>)は意味的に、msg-idの一部ではありません; msg-idは2つの角ブラケットキャラクタの間に含まれていることです。

The informational fields are all optional. The "Keywords:" field contains a comma-separated list of one or more words or quoted-strings. The "Subject:" and "Comments:" fields are unstructured fields as defined in section 2.2.1, and therefore may contain text or folding white space.

情報のフィールドはすべてオプションです。「Keywords:」フィールドは1語または引用符で囲まれるストリング以上のカンマで分離されたリストを含んでいます。 セクション2.2.1中で定義されるように、「Subject:」と「Comments:」フィールドは不統一のフィールドであり、従って、テキストまたは折りたためる空白類を含むかもしれません。

These three fields are intended to have only human-readable content with information about the message. The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences. The "Comments:" field contains any additional comments on the text of the body of the message. The "Keywords:" field contains a comma-separated list of important words and phrases that might be useful for the recipient.

これらの3つのフィールドは、メッセージについての情報によって人間に解読可能な内容だけを持つことを意図しています。「Subject:」フィールドは最も一般的で、メッセージのトピックを識別している短いストリングを含んでいます。返答において使われる時に、フィールドボディはストリング「Re:」によって起動するかもしれません。 オリジナルのメッセージのサブジェクト：フィールドボディ「の内容が続いていました)についての「ラテン語から)」物件。これがされるならば、リテラルストリング「Re:」のほんの1つの例 「他のストリングの使用以来使われるべきであるか、複数の例は望ましくない結果をもたらすことができます」。「Comments:」フィールドはメッセージのボディのテキストについてのどのような追加のコメントでも含んでいます。「Keywords:」フィールドは、受領者に便利であるかもしれない重要なワードとフレーズのカンマで分離されたリストを含んでいます。

Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system. A separate set of resent fields SHOULD be added each time this is done. All of the resent fields corresponding to a particular resending of the message SHOULD be together. Each new set of resent fields is prepended to the message; that is, the most recent set of resent fields appear earlier in the message. No other fields in the message are changed when resent fields are added.

再送フィールドは、輸送システムの中にユーザによって再導入されるどのようなメッセージにでも追加されるべきです。これがされるたびに、再送フィールドの別個のセットは追加されるべきです。メッセージの特定の再送と一致している再送フィールドのうちのすべては、一緒に、そうであるはずです。再送フィールドの個々の新しいセットは、メッセージにあらかじめ記述されます。すなわち、メッセージのより上にある再送フィールドは最も最近のセットが出現します。再送フィールドが追加される時には、メッセージの他のフィールドは全然変更されません。

Each of the resent fields corresponds to a particular field elsewhere in the syntax. For instance, the "Resent-Date:" field corresponds to the "Date:" field and the "Resent-To:" field corresponds to the "To:" field. In each case, the syntax for the field body is identical to the syntax given previously for the corresponding field.

再送フィールドのうちのそれぞれは全規則において他の場所に特定のフィールドと一致しています。例えば、「再送日付：」フィールドは「日付：」フィールドと一致していて、「Resent-To:」フィールドは「To:」フィールドと一致しています。各場合に、フィールドボディのための全規則は対応するフィールドのために以前に与えられた全規則に同一です。

When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be identical to "Resent-From:".

再送フィールドが使われる時には、「再送送信者：」、および「再送日付：」フィールドが送られなければなりません。「再送メッセージid：」フィールドは送られるべきです。「再送送信側：」が「再送送信者：」に同一ならば、「再送送信側：」は使われるべきでありません。

Resent fields are used to identify a message as having been reintroduced into the transport system by a user. The purpose of using resent fields is to have the message appear to the final recipient as if it were sent directly by the original sender, with all of the original fields remaining the same. Each set of resent fields correspond to a particular resending event. That is, if a message is resent multiple times, each set of resent fields gives identifying information for each individual time. Resent fields are strictly informational. They MUST NOT be used in the normal processing of replies or other such automatic actions on messages.

再送フィールドは、メッセージをユーザによって輸送システムに再導入されたことと認定するために使われます。まるでそれが 同じであり続けているオリジナルのフィールド それオリジナルの送信側により直接送られるかのように、再送フィールドを使っている目的は、メッセージを最終的な受領者に出現させることです。それぞれ、特定の再送イベントに再送フィールド一致で設定されます。もしすなわち、メッセージが再送複数の時であり、個々の個々の時間の間再送フィールドのそれぞれの時の設定が識別情報を与えるならば。再送フィールドは厳密な情報です。それらは返答またはメッセージの上の他のそのような自動的な行動の正常な処理に用いられてはなりません。

The resent originator fields indicate the mailbox of the person(s) or system(s) that resent the message. As with the regular originator fields, there are two forms: a simple "Resent-From:" form which contains the mailbox of the individual doing the resending, and the more complex form, when one individual (identified in the "Resent-Sender:" field) resends a message on behalf of one or more others (identified in the "Resent-From:" field).

再送発信者フィールドは、メッセージに再送する人(s)またはシステム(s)のメールボックスを示します。通常の発信者フィールドと同様に、2つの形式があります： 単純な「再送送信者：」は形を成し(それが再送をしている個人のメールボックスを含んでいます)、1つ以上の他(「再送送信者：」フィールドで識別されます)のために、一方の個人(「再送送信側：」フィールドで識別されます)がメッセージを再送する時に、より複雑なものは形を成します。

The "Resent-Date:" indicates the date and time at which the resent message is dispatched by the resender of the message. Like the "Date:" field, it is not the date and time that the message was actually transported.

「再送日付：」は、再送メッセージがメッセージの再送信側によりディスパッチされる日付と時刻を示します。「日付：」フィールドのように、メッセージが実際輸送されたことは日付と時刻ではありません。

The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function identically to the "To:", "Cc:", and "Bcc:" fields respectively, except that they indicate the recipients of the resent message, not the recipients of the original message.

「Resent-To:」、「Resent-Cc:」、および「Resent-Bcc：」フィールドは、それらがオリジナルのメッセージの受領者ではなく、再送メッセージの受領者を示す以外、「To：」、「Cc：」、および「Bcc：」フィールドにそれぞれ同一に機能します。

The "Resent-Message-ID:" field provides a unique identifier for the resent message.

「Resent-Message-ID:」フィールドは、再送メッセージのための一意の名前を提供します。

The trace fields are a group of header fields consisting of an optional "Return-Path:" field, and one or more "Received:" fields. The "Return-Path:" header field contains a pair of angle brackets that enclose an optional addr-spec. The "Received:" field contains a (possibly empty) list of name/value pairs followed by a semicolon and a date-time specification. The first item of the name/value pair is defined by item-name, and the second item is either an addr-spec, an atom, a domain, or a msg-id. Further restrictions may be applied to the syntax of the trace fields by standards that provide for their use, such as [RFC2821].

トレースフィールドは、オプションの「Received:」フィールドと1つ以上の、「受け取られます：」フィールドから成るヘッダーフィールドのグループです。「戻り経路：」ヘッダーフィールドは、オプションのaddr仕様を同封する1対の角ブラケットを含んでいます。「受け取られます：」フィールドは、セミコロンと日付時間仕様が後に続く名前/値ペアの、(ことによると、空になってください)リストを含んでいます。名前/値ペアの最初のアイテムはアイテム名によって定義されて、2番目のアイテムはaddrスペック、最小識別単位、ドメイン、またはmsg-idです。さらなる制限は、[RFC2821]などのそれらの使用に備える標準によってトレースフィールドの全規則に適用されるかもしれません。

A full discussion of the Internet mail use of trace fields is contained in [RFC2821]. For the purposes of this standard, the trace fields are strictly informational, and any formal interpretation of them is outside of the scope of this document.

トレースフィールドのインターネットメール使用の十分な議論は[RFC2821]において含まれています。この標準の目的にとって、トレースフィールドは厳密な情報であり、それらのどのような形式的な翻訳でもこの文書の範囲の外にあります。

Fields may appear in messages that are otherwise unspecified in this standard. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text which conforms to unstructured.

フィールドは、この標準の中で違った形で不特定のメッセージの中で出現するかもしれません。彼らはオプションのフィールドの全規則に対応しなければなりません。コロンが後に続き、に対応するどのようなテキストでも不統一に後に続くSPとコロンを除いて印刷可能なUS-ASCII文字から構成されていて、これはフィールド名です。

The field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard.

どのようなオプションのフィールドのフィールド名もこの標準の中で他の場所で指定されたどのようなフィールド名にも同一でてはなりません。

For the purposes of this standard, any optional field is uninterpreted.

この標準の目的にとって、どのようなオプションのフィールドでも解釈されていません。

Earlier versions of this standard allowed for different (usually more liberal) syntax than is allowed in this version. Also, there have been syntactic elements used in messages on the Internet whose interpretation have never been documented. Though some of these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver. This section documents many of these syntactic elements. Taking the grammar in section 3 and adding the definitions presented in this section will result in the grammar to use for interpretation of messages.

このバージョンの中で許されるより早いこの標準のバージョンは違う(通常多くの自由主義者)全規則を考慮しました。また、翻訳が一度も文書化されたことがないインターネットの上にメッセージの中で使われた構文要素がありました。これらの統語的な形式のいくつかがセクション3中の文法に従って生成されてはならないけれども、それらは全規則に準拠したレシーバによって受信されて、構文解析されなければなりません。このセクションはこれらの構文要素の多くを文書化します。セクション3中で文法をとり、このセクションの中で示された定義を追加することは、メッセージの翻訳のために使う文法を結果として生じるでしょう。

One important difference between the obsolete (interpreting) and the current (generating) syntax is that in structured header field bodies (i.e., between the colon and the CRLF of any structured header field), white space characters, including folding white space, and comments can be freely inserted between any syntactic tokens. This allows many complex forms that have proven difficult for some implementations to parse.

廃れた(解釈)ものと現在の(生成)全規則の1つの重要な違いは、構造化されたヘッダーフィールドボディ(すなわちどのような構造化されたヘッダーフィールドのコロンとCRLFの間)中ででも、空白類を折りたたむのを含む空白類キャラクタとコメントがどのような統語的なトークンの間ででも自由に挿入されることができることです。これは、いくつかの実装が構文解析しづらいと判明した多くの複雑な形式を許します。

Another key difference between the obsolete and the current syntax is that the rule in section 3.2.3 regarding lines composed entirely of white space in comments and folding white space does not apply. See the discussion of folding white space in section 4.2 below.

廃れたものと現在の全規則の別のキーの違いは、完全にコメントの中の空白類から構成されているラインを考慮に入れていて、空白類を折りたたんでいるセクション3.2.3中の規則があてはまるわけではないことです。下のセクション4.2中で空白類を包む議論を見てください。

Finally, certain characters that were formerly allowed in messages appear in this section. The NUL character (ASCII value 0) was once allowed, but is no longer for compatibility reasons. CR and LF were allowed to appear in messages other than as CRLF; this use is also shown here.

最終的に、メッセージの中で以前許されたある文字はこのセクションの中で表れます。NULキャラクタ(ASCII値0)は一度許されたけれども、もう、互換性理由のためではありません。CRとLFは、CRLFとしての以外メッセージの中で出現することを許されました； この使用はここでまた示されます。

Other differences in syntax and semantics are noted in the following sections.

構文と意味中の他の違いは以下のセクションの中で注目されます。

These syntactic elements are used elsewhere in the obsolete syntax or in the main syntax. The obs-char and obs-qp elements each add ASCII value 0. Bare CR and bare LF are added to obs-text and obs-utext. The period character is added to obs-phrase. The obs-phrase-list provides for "empty" elements in a comma-separated list of phrases.

これらの構文要素は廃れた全規則の中または主要な全規則の中で他の場所で使われます。obs雑用とobs-qpエレメントはそれぞれASCII値0を追加します。 裸のCRと裸のLFはobsテキストとobs-utextに追加されます。ピリオドキャラクタはobsフレーズに追加されます。 obsフレーズリストはフレーズのカンマで分離されたリストの中の「空の」エレメントに備えます。

Bare CR and bare LF appear in messages with two different meanings. In many cases, bare CR or bare LF are used improperly instead of CRLF to indicate line separators. In other cases, bare CR and bare LF are used simply as ASCII control characters with their traditional ASCII meanings.

裸のCRと裸のLFは2つの違う意味を持つメッセージの中で出現します。多くの場合に、裸のCRまたは裸のLFは、ラインセパレータを示すためにCRLFの代わりに不適切に使われます。他の場合に、裸のCRと裸のLFはそれらの伝統的なASCII意味によって単にASCII制御文字として使われます。

In the obsolete syntax, any amount of folding white space MAY be inserted where the obs-FWS rule is allowed. This creates the possibility of having two consecutive "folds" in a line, and therefore the possibility that a line which makes up a folded header field could be composed entirely of white space.

廃れた全規則の中で、obs-FWS規則が許される所で、どのような折りたためる空白類でも挿入されるかもしれません。これは、ラインの中に2つの連続的な「折りたたみ」を持つ可能性と折りたたまれたヘッダーフィールドを作るラインが完全に空白類から構成されることができたという可能性を作成します。

The syntax for the obsolete date format allows a 2 digit year in the date field and allows for a list of alphabetic time zone specifications that were used in earlier versions of this standard. It also permits comments and folding white space between many of the tokens.

廃れた日付の形式のための全規則は日付フィールドで2桁の年を許し、この標準のより早い翻訳に用いられた英字のタイムゾーン仕様のリストを考慮します。それはまたトークンの多くの間でコメントと折りたためる空白類を許します。

Where a two or three digit year occurs in a date, the year is to be interpreted as follows: If a two digit year is encountered whose value is between 00 and 49, the year is interpreted by adding 2000, ending up with a value between 2000 and 2049. If a two digit year is encountered with a value between 50 and 99, or any three digit year is encountered, the year is interpreted by adding 1900.

2または3桁の年が日付に起こる所で、その年は、次の通り解釈されることになっています： 2桁の年が遭遇される(値が00から49の間にあります)ならば、その年は、2000年と2049年の間で値によって終わって、2000年追加することによって解釈されます。2桁の年が50から99の間で値によって遭遇されるか、どのような3桁の年でも遭遇されるならば、その年は、1900年追加することによって解釈されます。

In the obsolete time zone, "UT" and "GMT" are indications of "Universal Time" and "Greenwich Mean Time" respectively and are both semantically identical to "+0000".

廃れたタイムゾーンにおいて、「UT」と「世界標準時」はそれぞれ「世界時間」と「グリニッチ標準時」のしるしであり、「+0000」に両方とも意味で同一です。

The remaining three character zones are the US time zones. The first letter, "E", "C", "M", or "P" stands for "Eastern", "Central", "Mountain" and "Pacific". The second letter is either "S" for "Standard" time, or "D" for "Daylight" (or summer) time. Their interpretations are as follows:

残存3文字のゾーンは米国タイムゾーンです。最初の文字、「E」、「C」、「M」、または「P」は「東」のために「中央です」、「山」、および「太平洋」に対抗します。2番目の文字は「標準」時間の間の「S」または「日光」(または夏)時間の間の「D」のどちらかです。それらの翻訳は次の通りです：

The 1 character military time zones were defined in a non-standard way in [RFC822] and are therefore unpredictable in their meaning. The original definitions of the military zones "A" through "I" are equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" are equivalent to "+1000", "+1100", and "+1200" respectively; "N" through "Y" are equivalent to "-0100" through "-1200" respectively; and "Z" is equivalent to "+0000". However, because of the error in [RFC822], they SHOULD all be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning.

1文字の軍隊のタイムゾーンは[RFC822]における非標準の方法で定義されて、従ってそれらの意味において予期不能です。「A」から「私」軍隊のゾーンのオリジナルの定義はそれぞれ「+0900」を通して「+0100」と等しい； 「K」、「L」、および「M」はそれぞれ「+1000」、「+1100」、および「+1200」と等しい； 「Y」を通して「N」はそれぞれ「-1200」を通して「-0100」と等しい； そして、「Z」は「+0000」と等しい。しかし、[RFC822]におけるエラーのため、それらの意味を確認している帯域の外の情報がない限り、それらはすべて「-0000」と等しいと考えられるべきです。

Other multi-character (usually between 3 and 5) alphabetic time zones have been used in Internet messages. Any such time zone whose meaning is not known SHOULD be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning.

他のマルチキャラクタ(3から5の通常間)英字のタイムゾーンはインターネットメッセージの中で使われています。それらの意味を確認している帯域の外の情報がない限り、意味が知られていないそのようなタイムゾーンは「-0000」と等しいと考えられるべきです。

There are three primary differences in addressing. First, mailbox addresses were allowed to have a route portion before the addr-spec when enclosed in "<" and ">". The route is simply a comma-separated list of domain names, each preceded by "@", and the list terminated by a colon. Second, CFWS were allowed between the period-separated elements of local-part and domain (i.e., dot-atom was not used). In addition, local-part is allowed to contain quoted-string in addition to just atom. Finally, mailbox-list and address-list were allowed to have "null" members. That is, there could be two or more commas in such a list with nothing in between them.

アドレス指定における3つの1次子の違いがあります。第一に、メールボックスアドレスは「<」と「>」に同封される時に、addrスペックの前にルート部分を持つことを許されました。ルートは「@」をそれぞれ付けられたドメインネームの単にカンマで分離されたリストとコロンによって終了させられたリストです。第二に、CFWSは、現地調達部品のピリオドで分離されたエレメントとドメインの(すなわちドット最小識別単位は使われませんでした)間で許されました。さらに、現地調達部品は、まさに最小識別単位に加えて引用符で囲まれるストリングを含むことを許されます。最終的に、メールボックスリストとアドレスリストは、「空文字の」メンバーを持つことを許されました。すなわち、2つ以上のカンマがそれらの間の何もないそのようなリストの中にあるかもしれません。

When interpreting addresses, the route portion SHOULD be ignored.

アドレスを解釈する時に、ルート部分は無視されるべきです。

Syntactically, the primary difference in the obsolete field syntax is that it allows multiple occurrences of any of the fields and they may occur in any order. Also, any amount of white space is allowed before the ":" at the end of the field name.

統語的に、廃れたフィールド全規則の中の1次子の違いは、それがフィールドのどれのでも複数の発生を許し、それらがどのような注文にでも存在するかもしれないことです。また、どのような空白類でもフィールド名の終わりに「：」前で許されます。

Except for destination address fields (described in section 4.5.3), the interpretation of multiple occurrences of fields is unspecified. Also, the interpretation of trace fields and resent fields which do not occur in blocks prepended to the message is unspecified as well. Unless otherwise noted in the following sections, interpretation of other fields is identical to the interpretation of their non-obsolete counterparts in section 3.

宛先アドレスフィールド(セクション4.5.3中で説明されます)を除いて、フィールドの複数の発生の翻訳は不特定です。また、メッセージにprependedされたブロックに存在しないトレースフィールドと再送フィールドの翻訳は、その上不特定です。以下のセクションの中で違った形で言及されない限り、他のフィールドの翻訳はセクション3中のそれらの時代遅れでない対応するものの翻訳に同一です。

When multiple occurrences of destination address fields occur in a message, they SHOULD be treated as if the address-list in the first occurrence of the field is combined with the address lists of the subsequent occurrences by adding a comma and concatenating.

宛先アドレスフィールドの複数の発生がメッセージに存在している時に、フィールドの最初の発生におけるアドレスリストが、カンマと連結を追加することによってその後の発生のアドレスリストと結合されるかのように、それらは扱われるべきです。

The obsolete "In-Reply-To:" and "References:" fields differ from the current syntax in that they allow phrase (words or quoted strings) to appear. The obsolete forms of the left and right sides of msg-id allow interspersed CFWS, making them syntactically identical to local-part and domain respectively.

それらが、フレーズ(ワードまたは引用符付きストリング)が出現することを可能にするという点で、廃れた「In-Reply-To:」と「Refernces:」フィールドは現在の全規則と異なります。それらをそれぞれ現地調達部品とドメインに統語的に同一にして、msg-idの左右の側の廃れた形式は散在したCFWSを許します。

For purposes of interpretation, the phrases in the "In-Reply-To:" and "References:" fields are ignored.

翻訳の目的のために、「In-Reply-To:」におけるフレーズと「Refernces:」フィールドは無視されます。

Semantically, none of the optional CFWS surrounding the local-part and the domain are part of the obs-id-left and obs-id-right respectively.

意味的に、現地調達部品とドメインを取り囲んでいるオプションのCFWSのどれもそれぞれobs-idの左とobs-idの右の一部ではありません。

The obsolete syntax adds a "Resent-Reply-To:" field, which consists of the field name, the optional comments and folding white space, the colon, and a comma separated list of addresses.

廃れた全規則は、フィールド名、オプションのコメント、および折りたためる空白類、コロンから成る「Resent-Reply-To:」フィールドを追加し、カンマはアドレスのリストを区切りました。

As with other resent fields, the "Resent-Reply-To:" field is to be treated as trace information only.

他と同様に、フィールド(フィールドが、トレース情報だけとして扱われることになっている「次をする再送返答：」)に再送してください。

The obs-return and obs-received are again given here as template definitions, just as return and received are in section 3. Their full syntax is given in [RFC2821].

obsリターンとobs受け取りはテンプレート定義として再びここに与えられて、ちょうどリターンとして、そして受け取られて、セクション3中にあります。それらの完全な全規則は[RFC2821]において与えられます。