[要約] RFC 6729は、電子メールのトレースフィールドでのメール処理状態の表示に関するものであり、その目的は、メールの配信プロセスを追跡し、エラーや遅延などの問題を特定するための標準化を提供することです。
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 6729 Brandenburg InternetWorking
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 Cloudmark, Inc.
September 2012
Indicating Email Handling States in Trace Fields
トレースフィールドでの電子メール処理状態の表示
Abstract
概要
This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues.
このドキュメントは、ホスト間およびホスト内のメッセージ遷移の実行を含む、キューまたは処理状態間の処理の遷移を示すために使用するトレースフィールド句を登録します。これには、メッセージの検疫、メーリングリストのモデレート、時限配信、さらなる分析のためのキューイング、コンテンツの変換、またはその他の同様の原因が含まれ、オプションで通常の処理キューを識別することもできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6729.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6729で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Key Words .......................................................3
3. Trace Clause ....................................................3
4. Discussion ......................................................6
5. Granularity .....................................................6
6. IANA Considerations .............................................7
6.1. MAIL Parameters Additional-registered-clauses
Sub-Registry ...............................................7
6.2. MAIL Parameters Registered-states Sub-Registry .............7
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. Trace Field Examples .................................11
A.1. Typical Delivery without Obvious Extra Handling ...........11
A.2. Delivery with Moderation ..................................11
Appendix B. Acknowledgements .....................................12
[SMTP] defines the content of email message trace fields, commonly the "Received" header field. These are typically used to record an audit trail of the path a message follows from origin to destination, with one such field added each time a message moves from one host to the next.
[SMTP]は、電子メールメッセージトレースフィールドのコンテンツを定義します。通常は「Received」ヘッダーフィールドです。これらは通常、メッセージが起点から宛先へとたどるパスの監査証跡を記録するために使用され、メッセージが1つのホストから次のホストに移動するたびにそのようなフィールドが1つ追加されます。
Section 3.7.2 of that document mentions that "the most important use of Received: lines is for debugging mail faults [...]".
そのドキュメントのセクション3.7.2は、「Received：行の最も重要な使用法はメール障害のデバッグに使用される[...]」と述べています。
There are some cases where there may be large time gaps between trace fields. Though this might be caused by transient communication issues, they might also be caused by policy decisions or special processing regarding the content of the message, authorization of some identity on the message, or transitions between major software components. Common examples include message quarantines (filters that cause a message to be held pending further evaluation or delivery of a message pending manual operator action), pending content analysis, or mailing list servers that impose moderation rules (mailing list owner action required regarding mail from authors not subscribed to those lists).
トレースフィールド間に大きな時間ギャップがある場合があります。これは一時的な通信の問題が原因である可能性がありますが、メッセージの内容に関するポリシーの決定または特別な処理、メッセージの一部のIDの承認、または主要なソフトウェアコンポーネント間の移行によっても発生する可能性があります。一般的な例としては、メッセージの検疫（手動のオペレーターのアクションが保留されているメッセージのさらなる評価または配信が保留されるまでメッセージを保留するフィルター）、保留中のコンテンツ分析、またはモデレーションルールを課すメーリングリストサーバー（作成者からのメールに関してメーリングリストの所有者のアクションが必要）などがあります。それらのリストに登録されていません）。
This document registers a new optional clause that can be used in trace fields to indicate that a message entered such a special processing queue or state for some period. This allows inspection of the trace information to reveal that the cause for a time gap in trace fields was imposed by additional processing rather than one caused by transient technical difficulties.
このドキュメントでは、トレースフィールドで使用できる新しいオプションの句を登録し、メッセージがそのような特別な処理キューまたは状態に一定期間入ったことを示します。これにより、トレース情報を検査して、トレースフィールドの時間ギャップの原因が一時的な技術的な問題によるものではなく、追加の処理によるものであることが明らかになります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
This specification defines a clause, called "state", which MAY be used when creating a Received header field (see Section 4.4 of [SMTP]) to indicate the nature of additional handling imposed on the relaying of a message toward its recipient(s). It is followed by a single keyword that provides that detail. A Mail Transfer Agent (MTA) or other handling agent that determines a message has entered a state other than normal queuing of messages for relaying or delivery MAY generate a trace field including one of these clauses. That is, the presence of this clause on a trace field is an indication of the entry of the message into that state; a later trace field added would indicate its departure from that state.
この仕様は、「状態」と呼ばれる節を定義します。これは、受信ヘッダーフィールド（[SMTP]のセクション4.4を参照）を作成するときに使用して、受信者へのメッセージのリレーに課される追加の処理の性質を示すことができます。 。その後に、その詳細を提供する単一のキーワードが続きます。メッセージがリレーまたは配信のためのメッセージの通常のキューイング以外の状態になったと判断したメール転送エージェント（MTA）または他の処理エージェントは、これらの句のいずれかを含むトレースフィールドを生成する場合があります。つまり、トレースフィールドにこの句があることは、メッセージがその状態に入ったことを示します。後に追加されるトレースフィールドは、その状態からの逸脱を示します。
An MTA implementing this specification SHOULD add a Received field as described whenever:
この仕様を実装するMTAは、次の場合に説明するように、Receivedフィールドを追加する必要があります。
a. It determines that a special handling condition will occur and places it into that condition; or
a. 特別な処理条件が発生することを決定し、その条件に配置します。または
b. It determines that no special handling is required and prepares it for relay to the next handling agent.
b. 特別な処理は必要ないと判断し、次の処理エージェントへのリレーのために準備します。
An MTA need not add a Received field indicating preparation for normal handoff to the next handling agent if it has already added a Received field for some other reason. Trace data added by the next handling agent will imply the message's exit from the special handling condition.
MTAは、他の理由で既に受信フィールドを追加している場合、次の処理エージェントへの通常のハンドオフの準備を示す受信フィールドを追加する必要はありません。次の処理エージェントによって追加されたトレースデータは、特別な処理条件からのメッセージの終了を意味します。
If a single MTA processes a message through multiple special handling conditions, it MAY add a Received field for each distinct condition.
1つのMTAが複数の特別な処理条件を介してメッセージを処理する場合、個別の条件ごとに受信フィールドを追加する場合があります。
For example, presume a message will be injected into MTA-1, then travel to MTA-3 via MTA-2, and then MTA-3 will enact final delivery. At MTA-2, it is determined that some action will be taken that will cause the message to undergo some handling change that is outside of typical message flow. In this case:
たとえば、メッセージがMTA-1に挿入され、MTA-2を介してMTA-3に移動し、MTA-3が最終的な配信を実行するとします。 MTA-2では、通常のメッセージフローの範囲外の処理の変更がメッセージに加えられるようなアクションが実行されると判断されます。この場合：
1. MTA-1 adds a typical Received field and relays it to MTA-2.
1. MTA-1は一般的な受信フィールドを追加し、MTA-2に中継します。
2. MTA-2 determines that the atypical handling will occur and adds a Received field using the extension specified here.
2. MTA-2は、異常な処理が行われると判断し、ここで指定された拡張子を使用して受信フィールドを追加します。
3. On completion of the atypical handling, MTA-2 relays the message to MTA-3.
3. 異常な処理が完了すると、MTA-2はメッセージをMTA-3に中継します。
4. MTA-3 adds a typical Received field and enacts final delivery of the message.
4. MTA-3は、一般的な受信フィールドを追加し、メッセージの最終配信を実行します。
Appropriate use of this mechanism does not include associating meta-data with the message, such as categorizing the message (e.g., the notions of "is spam" or "was 8-bit, converted to 7-bit"). Processing agents also cannot reliably use this mechanism to determine anything about the message content, since there is no guarantee that all agents in the chain of handling made such annotations to allow correct conclusions. The sole purpose here is to allow one to determine the point(s) in the chain of custody of a message at which the message was subjected to handling outside of normal message routing and queuing.
このメカニズムの適切な使用には、メッセージの分類などのメタデータとメッセージの関連付けは含まれません（たとえば、「スパムである」または「8ビットだった、7ビットに変換された」という概念）。また、処理エージェントは、このメカニズムを使用してメッセージの内容について何かを確実に判断することはできません。これは、処理のチェーン内のすべてのエージェントが、正しい結論を可能にするためにそのような注釈を作成したという保証がないためです。ここでの唯一の目的は、通常のメッセージのルーティングとキューイング以外の処理をメッセージが受けたメッセージの保管チェーン内のポイントを特定できるようにすることです。
The following state keywords are defined in this document; extensions may define other registered keywords (see Section 6.2):
このドキュメントでは、次の状態キーワードが定義されています。拡張機能は他の登録済みキーワードを定義する場合があります（セクション6.2を参照）
auth: The message entered a queue pending authentication of some identifier in the message.
auth：メッセージは、メッセージ内のいくつかの識別子の認証待ちのキューに入りました。
content: The message entered a queue pending content analysis, such as scanning for spam or viruses.
content：メッセージは、スパムやウイルスのスキャンなどのコンテンツ分析待ちのキューに入りました。
convert: The message entered a queue pending content conversion.
変換：メッセージはコンテンツ変換待ちのキューに入りました。
moderation: The message entered a hold pending mailing list moderator action.
モデレーション：メッセージは保留中のメーリングリストのモデレーターアクションに入りました。
normal: The message is not in an administrative hold and is queued for or is being handed off to the next handling agent (which may be local delivery). This is the default interpretation when no "state" clause is present.
正常：メッセージは管理上の保留状態になく、キューに入れられているか、次の処理エージェント（ローカル配信である可能性があります）にハンドオフされています。これは、「state」句が存在しない場合のデフォルトの解釈です。
other: The message entered a hold or queue for reasons not covered by other keywords in this list and not for transient technology issues.
その他：メッセージは、このリストの他のキーワードではカバーされない理由や一時的なテクノロジーの問題ではない理由で保留またはキューに入りました。
outbound: The message entered a queue for outbound relaying. This is typically the last case added for a single host, and the next Received header field is expected to be added by some other host.
アウトバウンド：メッセージはアウトバウンドリレーのキューに入りました。これは通常、単一のホストに追加される最後のケースであり、次のReceivedヘッダーフィールドは他のホストによって追加されると予想されます。
quarantine: The message entered a hold in an isolation queue pending operator action for local policy reasons.
隔離：メッセージは、ローカルポリシーの理由により、隔離キューで保留になり、オペレーターのアクションが保留されました。
timed: The message entered a hold in order to meet a requested delivery window, such as is defined in [FUTURERELEASE].
時限：メッセージは、[FUTURERELEASE]で定義されているように、要求された配信ウィンドウを満たすために保留状態になりました。
In Section 6, the "state" clause is added to the Additional-Registered-Clauses IANA sub-registry. The ABNF for this clause is:
セクション6では、「state」句が追加登録されたClauses IANAサブレジストリに追加されています。この句のABNFは次のとおりです。
State = CFWS "state" FWS queue-state-keyword [ "/" value ]
状態= CFWS "状態" FWSキュー状態キーワード["/"値]
queue-state-keyword = ( reg-state-keyword / unreg-state-keyword )
reg-state-keyword = ( "auth" / "content" / "convert" /
"moderation" / "normal" / "other" /
"outbound" / "quarantine" / "timed" /
additional-state-keyword )
additional-state-keyword = token ; MUST be registered; see ; "IANA Considerations" below
追加の状態キーワード=トークン;登録する必要があります。見る ;以下の「IANAに関する考慮事項」
value = token
unreg-state-keyword = token
"FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME].
「FWS」と「CFWS」は[メール]で定義されています。 「トークン」は[MIME]で定義されています。
A transfer agent making use of this extension MAY also include header field comments to provide additional information.
この拡張機能を使用する転送エージェントは、追加情報を提供するためにヘッダーフィールドのコメントも含めることができます。
The "value" is available for providing additional labels as explanation for the state transition. Examples could include:
「値」は、状態遷移の説明として追加のラベルを提供するために使用できます。例には次のものがあります。
o convert/unicode2ascii
o convert / unicode2ascii
o moderation/not-subscribed
o モデレート/未購読
o quarantine/spam
o 検疫/スパム
Handling agents are not expected to implement or support all of these. Indeed, recording trace information for all of the states described above could make the header of a message inordinately large. Rather, an agent is encouraged to apply state annotations when a message enters a handling queue where a significant condition occurs or where significant additional processing or delay is possible, and especially when a handoff has occurred between two different, independent agents.
処理エージェントは、これらすべてを実装またはサポートすることは期待されていません。実際、上記のすべての状態のトレース情報を記録すると、メッセージのヘッダーが異常に大きくなる可能性があります。むしろ、重要な状態が発生したり、重要な追加処理や遅延が発生したりする可能性のある処理キューにメッセージが入った場合、特に2つの異なる独立したエージェント間でハンドオフが発生した場合は、エージェントに状態注釈を適用することをお勧めします。
For example, an MTA receiving a message, doing message authentication, scanning for viruses and spam, and then putting it in an outbound queue could add four Received header fields denoting each of these states. However, where they are all done as part of a single system process, in a single pass, doing so would be considered unusual (and extremely verbose). This method SHOULD NOT be applied except when doing detailed analysis of a single component to identify performance issues with those steps.
たとえば、MTAがメッセージを受信し、メッセージ認証を行い、ウイルスとスパムをスキャンしてから送信キューに入れると、これらの各状態を示す4つのReceivedヘッダーフィールドが追加されます。ただし、それらがすべて単一のシステムプロセスの一部として、単一のパスで行われる場合、そうすることは異常と見なされます（そして非常に冗長になります）。この方法は、これらの手順でパフォーマンスの問題を特定するために単一のコンポーネントの詳細な分析を行う場合を除いて、適用しないでください。
Rather, an agent that wishes to make a state annotation SHOULD add only a single Received header field including such annotation, thus indicating (a) the time of completion of its handling of the message via the date portion of the field and (b) the final disposition of that message relative to that agent. For example, an MTA receiving a message that performs various checks on the message before immediately handing it off to a Mailing List Manager (MLM) would only record a "normal" state, assuming it passes those checks. The MLM would then evaluate the message and record its own state once it decides what the next step will be for the handling of that message.
むしろ、状態注釈を作成したいエージェントは、そのような注釈を含む単一のReceivedヘッダーフィールドのみを追加する必要があります（SHOULD）。これにより、（a）フィールドの日付部分によるメッセージの処理の完了時刻と（b）そのエージェントに対するそのメッセージの最終処分。たとえば、MTAがメッセージのさまざまなチェックを実行するメッセージを受信した後、すぐにメーリングリストマネージャー（MLM）にメッセージを渡すと、それらのチェックに合格したと仮定して、「通常の」状態のみが記録されます。次に、MLMはメッセージを評価し、そのメッセージの処理のための次のステップを決定すると、それ自体の状態を記録します。
The degree of granularity -- and therefore the degree of verbosity -- recorded through the use of this additional trace clause is likely to vary depending on circumstances. It will typically be the case that use of this clause will be limited to "unusual" transitions, such as when a message requires additional scrutiny or other processing or needs to be quarantined.
この追加のtrace句を使用して記録される細分性の程度（つまり、冗長性の程度）は、状況によって異なります。通常、この句の使用が「異常な」遷移に限定される場合です。たとえば、メッセージに追加の精査やその他の処理が必要な場合や、メッセージを隔離する必要がある場合などです。
Somewhat greater granularity might also include transitions of administrative responsibility, such as between a Mail Transfer Agent (MTA) operator and a Mailing List Manager (MLM) operator. This could be further enhanced to note some transitions that are interesting only when other transitions have occurred, such as noting entry to the outbound queue only when the message is originating from an "interesting" source, like an MLM, since an MLM can introduce significant changes to the message or delivery delay and it could be useful to know when it completed its processing, as distinct from the subsequent processing by the originating MTA. In circumstances needing very fine-grained trace information, fields might be created to note all of these "significant" network architecture transitions.
やや細かい粒度には、メール転送エージェント（MTA）オペレーターとメーリングリストマネージャー（MLM）オペレーターの間などの管理責任の移行も含まれる場合があります。これは、メッセージがMLMのような「興味深い」ソースから発信されている場合にのみ送信キューへのエントリに注意するなど、他の遷移が発生した場合にのみ興味深い一部の遷移に注目するようにさらに拡張できます。メッセージまたは配信の遅延に対する変更。発信元のMTAによる後続の処理とは異なり、処理がいつ完了したかを知ることが役立つ場合があります。非常に細かいトレース情報が必要な状況では、これらの「重要な」ネットワークアーキテクチャの移行のすべてを記録するフィールドが作成される場合があります。
One should note, however, when choosing higher levels of granularity, that the Received header fields present on a message could be counted by MTAs when trying to decide whether or not a message routing loop is in effect. A message with an abundance of these might cause an incorrect determination that the message is in a delivery loop, causing it to be removed from the mail stream. See Section 6.3 of [SMTP] for further discussion.
ただし、より高いレベルの粒度を選択する場合、メッセージルーティングループが有効であるかどうかを判断しようとすると、メッセージに存在する受信ヘッダーフィールドがMTAによってカウントされる可能性があることに注意してください。これらが豊富なメッセージは、メッセージが配信ループにあると誤って判断し、メールストリームから削除される可能性があります。詳細については、[SMTP]のセクション6.3を参照してください。
This document adds the following entry to the "Additional-registered-clauses" sub-registry of the "MAIL Parameters" registry, created by [SMTP]:
このドキュメントは、[SMTP]によって作成された「MAIL Parameters」レジストリの「Additional-registered-clauses」サブレジストリに次のエントリを追加します。
Clause name: state
条項名：州
Description: Indicates entry into a special queue state
説明：特別なキュー状態へのエントリを示します
Syntax Summary: state <state-name>
Reference: [RFC6729]
参照：[RFC6729]
The "MAIL Parameters" registry at IANA has been updated by the creation of the "Registered-states" sub-registry to contain valid state keywords for use with this specification. Updates to this registry are governed by the First Come, First Served rules of [IANA] for new registrations. Changes to the status of existing entries are limited to the original registrant or IESG approval.
IANAの「MAIL Parameters」レジストリは、「Registered-states」サブレジストリの作成によって更新され、この仕様で使用するための有効な状態キーワードが含まれています。このレジストリの更新は、新規登録に関する[IANA]の先着順のルールに準拠しています。既存のエントリのステータスの変更は、元の登録者またはIESGの承認に限定されます。
Discussion of all registry updates is encouraged via one or more IETF mailing lists that typically cover email-related subjects prior to approval of the change, as a way of documenting the work. The ietf-smtp@ietf.org list is suggested.
すべてのレジストリの更新についての議論は、作業を文書化する方法として、変更の承認前に電子メール関連の主題を通常カバーする1つ以上のIETFメーリングリストを介して推奨されます。 ietf-smtp@ietf.orgリストが推奨されます。
Note that only registrations of queue state keywords are permitted. The registry is not to be used for specifying secondary information (i.e., the "value" part of the ABNF in Section 3).
キュー状態キーワードの登録のみが許可されていることに注意してください。レジストリは、2次情報（セクション3のABNFの「値」部分）を指定するために使用されません。
Registrations are to include the following entries:
登録には、次のエントリが含まれます。
Name: The name of the state keyword being defined or updated, which conforms to the ABNF shown in Section 3.
名前：定義または更新される状態キーワードの名前。セクション3に示すABNFに準拠しています。
Description: A brief description of the keyword's meaning.
説明：キーワードの意味の簡単な説明。
Specification: The specification document that defines the queue state being registered, or if no stable reference exists, a more detailed explanation of the queue state than is in the "Description", sufficient to allow interoperability.
仕様：登録されるキューの状態を定義する仕様文書。安定した参照が存在しない場合は、相互運用性を可能にするのに十分な、「説明」よりもキューの状態の詳細な説明。
Use: One of "current" (the state keyword is in current use), "deprecated" (the state keyword is in use but not recommended for new implementations), or "historic" (the state keyword is no longer in substantial current use).
使用： "current"（stateキーワードは現在使用中）、 "deprecated"（stateキーワードは使用中ですが、新しい実装には推奨されません）、または "historic"（stateキーワードは実質的に現在使用されていません）のいずれか）。
The initial registration set is as follows:
初期登録セットは次のとおりです。
+------------+------------------------+-----------------+---------+
| Name | Description | Specification | Use |
+------------+------------------------+-----------------+---------+
| auth | Held for message | [RFC6729] | current |
| | authentication | | |
+------------+------------------------+-----------------+---------+
| content | Held for message | [RFC6729] | current |
| | content analysis | | |
+------------+------------------------+-----------------+---------+
| convert | Held for message | [RFC6729] | current |
| | content conversion | | |
+------------+------------------------+-----------------+---------+
| moderation | Held for list | [RFC6729] | current |
| | moderation | | |
+------------+------------------------+-----------------+---------+
| normal | Message is not being | [RFC6729] | current |
| | held other than to | | |
| | accommodate typical | | |
| | relaying handling | | |
+------------+------------------------+-----------------+---------+
| other | Held for causes not | [RFC6729] | current |
| | covered by other | | |
| | registered state | | |
| | keywords | | |
+------------+------------------------+-----------------+---------+
| outbound | Message placed in | [RFC6729] | current |
| | outbound queue | | |
+------------+------------------------+-----------------+---------+
| quarantine | Held for operator | [RFC6729] | current |
| | action due to content | | |
| | analysis or local | | |
| | policy | | |
+------------+------------------------+-----------------+---------+
| timed | Held to accommodate a | [RFC6729] | current |
| | specific requested | | |
| | delivery window | | |
+------------+------------------------+-----------------+---------+
The use of this trace information can reveal hints as to local policy that was in effect at the time of message handling.
このトレース情報を使用すると、メッセージ処理時に有効だったローカルポリシーに関するヒントが明らかになります。
Further discussion about trace field security can be found in Section 7.6 of [SMTP].
トレースフィールドのセキュリティに関する詳細については、[SMTP]のセクション7.6を参照してください。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service Extension for Future Message Release", RFC 4865, May 2007.
[FUTURERELEASE] White、G.、G。Vaudreuil、「SMTP Submission Service Extension for Future Message Release」、RFC 4865、2007年5月。
This section includes a sample of the new trace field clause in use.
このセクションには、使用中の新しいトレースフィールド句のサンプルが含まれています。
Typical message delivery
典型的なメッセージ配信
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:22 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:08 -0800
Example 1: Typical message delivery with no appreciable extra handling; only Received header fields shown
例1：特別な処理を行わない一般的なメッセージ配信。表示された受信ヘッダーフィールドのみ
Message delivery after moderation
モデレート後のメッセージ配信
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 18:33:29 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <secret-list@example.com>
state moderation (sender not subscribed);
Fri, Feb 15 2002 17:19:08 -0800
Example 2: Message held for moderation; only Received header fields shown
例2：モデレートのために保留されたメッセージ。表示された受信ヘッダーフィールドのみ
The message passed from internal.example.com to newyork.example.com intended for a mailing list hosted at the latter. For list administrative reasons, the message is held there for moderation. It is finally released over an hour later and passed to the next host. A comment after the state expression indicates the actual cause for the administrative hold.
メッセージは、internal.example.comからnewyork.example.comに渡され、後者でホストされているメーリングリストを対象としています。リストの管理上の理由から、メッセージはモデレートのために保持されます。最終的に1時間後に解放され、次のホストに渡されます。状態式の後のコメントは、管理保留の実際の原因を示しています。
The authors wish to acknowledge the following for their reviews and constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl S. Gutenkunst, John Levine, Bill McQuillan, S. Moonesamy, Alexey Melnikov, Robert A. Rosenberg, Hector Santos, Rolf Sonneveld, and Mykyta Yevstifeyev.
著者は、この提案のレビューと建設的な批評のために、次のことを認めたいと考えています。 Sonneveld、およびMykyta Yevstifeyev。
Authors' Addresses
著者のアドレス
D. Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale 94086 USA
D.クロッカーブランデンブルクインターネットワーキング675スプルース博士サニーベール94086米国
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy Cloudmark、Inc.128 King St.、2nd Floor San Francisco、CA 94107 USA
EMail: superuser@gmail.com