RFC 3886 - An Extensible Message Format for Message Tracking Responses 日本語訳

URL : https://tools.ietf.org/html/rfc3886
タイトル : RFC 3886 - メッセージ追跡応答のための拡張可能なメッセージフォーマット
翻訳編集 : 自動生成

Network Working Group                                          E. Allman
Request for Comments: 3886                                Sendmail, Inc.
Updates: 3463                                             September 2004
Category: Standards Track

      An Extensible Message Format for Message Tracking Responses

Status of this Memo

このメモの位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。

Abstract

抽象

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

メッセージ追跡は、要求に応じて未配信のメールの状態を決定するために使用されることが期待されます。トラッキングは、配信状態通知（DSN）とメッセージ気質通知（MDN）と組み合わせて使用されます。一般的に、メッセージ追跡要求は、DSNまたはMDNが合理的なタイムアウト時間内に受信されなかった場合にのみ発行されます。

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo.

このメモはRFC 3464、「配送状態通知のための広げることができるメッセージフォーマット」と同じ精神で、ステータスを追跡するメッセージのMIMEコンテンツタイプを定義します。これは、「メッセージ追跡照会プロトコル」で説明したように、要求に応じて発行されます。このメモは、ステータス情報のフォーマットのみを定義します。 SMTPへの拡張は別個のメモで定義され、さらに、トラッキングリクエストトラッキングステータスメッセージを標識します。

1. Introduction

1. はじめに

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) [RFC-DSN-SMTP] and Message Disposition Notifications (MDN) [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

メッセージ追跡は、要求に応じて未配信のメールの状態を決定するために使用されることが期待されます。トラッキングは、配信状態通知（DSN）[RFC-DSN-SMTP]とメッセージ気質通知（MDN）[RFC-MDN]と組み合わせて使用されます。一般的に、メッセージ追跡要求は、DSNまたはMDNが合理的なタイムアウト時間内に受信されなかった場合にのみ発行されます。

This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications" [RFC-DSN-STAT]. It is to be issued upon a request as described in "Message Tracking Query Protocol" [RFC-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [RFC-MTRK-SMTPEXT].

このメモは、RFC 3464と同じ精神状態を追跡メッセージのMIME [RFC-MIME]コンテンツタイプを定義し、「配達状態通知のための拡張可能なメッセージフォーマット」[RFC-DSN-STAT]。これは、「メッセージ追跡照会プロトコル」[RFC-MTRK-MTQP]で説明したように、要求に応じて発行されます。このメモは、ステータス情報のフォーマットのみを定義します。 SMTP [RFC-ESMTP]への拡張はさらに、追跡のためにメッセージをラベル及びトラッキング状態が別のメモ[RFC-MTRK-SMTPEXT]で定義されている要求します。

2. Other Documents and Conformance

2.その他のドキュメントとの適合性

The model used for Message Tracking is described in [RFC-MTRK-MODEL].

メッセージ追跡のために使用されるモデルは、[RFC-MTRK-MODEL]に記載されています。

Message tracking is intended for use as a "last resort" mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if no response is received from either of these mechanisms would Message Tracking be used.

メッセージ追跡は「最後の手段」のメカニズムとして使用するためのものです。通常、配信状態通知（DSN）[RFC-DSN-SMTP]とメッセージ気質通知（開封通知）[RFC-MDNは、一次配信ステータスを提供するであろう。応答がこれらのメカニズムのいずれかから受信されない場合にのみ、メッセージ追跡が使用されます。

This document is based on [RFC-DSN-STAT]. Sections 1.3 (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2 ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 822) of [RFC-DSN-STAT] are included into this document by reference. Other sections are further incorporated as described herein.

この文書は、[RFC-DSN-STAT]に基づいています。セクション1.3（用語）、2.1.1（DSNフィールドのための一般的な規則）、2.1.2（ "*型" サブフィールド）、および[RFC-DSN-STAT]の2.1.3（RFC 822から輸入字句）されています参照によって本文書に含まれています。他のセクションは、本明細書にさらに記載されるように組み込まれています。

Syntax notation in this document conforms to [RFC-ABNF].

この文書の構文記法は、[RFC-ABNF]に従います。

The following lexical tokens, defined in [RFC-MSGFMT], are used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [RFC-HOSTREQ].

原子、CHAR、コメント、CR、CRLF、DIGIT、LF、線形空白、空白、テキスト：[RFC-MSGFMT]で定義された以下の字句は、MTSNsためABNF文法で使用されています。日時字句トークンは[RFC-HOSTREQ]で定義されています。

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 RFC 2119 [RFC-KEYWORDS].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC-KEYWORDS]に記載されているように解釈されます。

3. Format of a Message Tracking Status Notification

メッセージ追跡ステータス通知の3フォーマット

A Message Tracking Status Notification (MTSN) is intended to be returned as the body of a Message Tracking request [RFC-MTRK-MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] with type parameter of "message/tracking-status"; each subpart MUST be of type "message/tracking-status" as described herein. The multipart/related body can include multiple message/tracking-status parts if an MTQP server chains requests to the next server; see [RFC-MTRK-MODEL] and [RFC-MTRK-MTQP] for more information about chaining.

メッセージ追跡状態通知（MTSN）は、メッセージ追跡要求[RFC-MTRK-MTQP]のボディとして返されることを意図しています。実際の体「とは、メッセージ/トラッキング状態」の型パラメータを持つマルチパート/関連[RFC-RELATED]なければなりません。本明細書に記載されるように各サブパートは、タイプ「メッセージ/トラッキング状態」でなければなりません。 MTQPサーバチェーン要求した場合、マルチパート/関連体は、次のサーバに複数のメッセージ/トラッキングステータス部分を含むことができます。連鎖の詳細については、[RFC-MTRK-MODEL]と[RFC-MTRK-MTQP]を参照してください。

3.1. The message/tracking-status content-type

3.1. メッセージ/トラッキングステータスコンテンツタイプ

The message/tracking-status content-type is defined as follows:

次のようにメッセージ/トラッキングステータスコンテンツタイプが定義されます。

MIME type name: message MIME subtype name: tracking-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 4 of this memo.

MIMEタイプ名：メッセージMIMEサブタイプ名：トラッキングステータスオプションパラメータ：なしエンコードの考慮事項：「7ビット」の符号化は十分であり、非MIMEメール読者によって見たときに、読みやすさを維持するために使用されなければなりません。セキュリティの考慮事項：このメモのセクション4で議論しました。

The body of a message/tracking-status is modeled after [RFC-DSN-STAT]. That body consists of one or more "fields" formatted to according to the ABNF of RFC 2822 header "fields" (see [RFC-MSGFMT]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Note that there will be a blank line between the final per-recipient field and the MIME boundary, since one CRLF is necessary to terminate the field, and a second is necessary to introduce the MIME boundary. Formally, the syntax of the message/tracking-status content is as follows:

メッセージ/トラッキング状態の本体は、[RFC-DSN-STAT]の後にモデル化されます。その本体は、RFC 2822ヘッダー「フィールド」のABNFに応じにフォーマットされた1つまたは複数の「フィールド」から成る（参照[RFC-MSGFMT]）。メッセージごとのフィールドは、空白行に続いて、最初に表示されます。メッセージごとのフィールドに続いて、受信者ごとのフィールドの1つ以上のグループです。受信者ごとのフィールドの各グループは、空白行が先行しています。 1つのCRLFフィールドを終了する必要があり、第二は、MIME境界を導入する必要があるため、最終的な受信者ごとのフィールドとMIME境界の間に空行が存在するであろうことに留意されたいです。次のように形式的には、メッセージ/トラッキングステータスコンテンツの構文は次のとおりです。

tracking-status-content = per-message-fields 1*( CRLF per-recipient-fields )

トラッキングステータス内容=メッセージごとのフィールド1 *（CRLFごとの受信者フィールド）

The per-message fields are described in section 3.2. The per-recipient fields are described in section 3.3.

メッセージごとのフィールドは、セクション3.2に記載されています。受信者ごとのフィールドは、セクション3.3に記載されています。

3.1.1. General conventions for MTSN fields

3.1.1. MTSNフィールドの一般的な規則

Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definition of xtext is identical to that of that document.

セクション2.1.1 [RFC-DSN-STAT]の（DSNフィールドの一般的な規則）は、参照により本明細書に含まれます。特に、XTEXTの定義は、その文書のものと同じです。

3.1.2. *-type subfields

3.1.2. *型のサブフィールド

Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definitions of address-type, diagnostic-type, and MTA-name type are identical to that of RFC 3464.

[RFC-DSN-STAT]のセクション2.1.2（*型サブフィールド）を参照することにより本明細書に含まれます。なお、アドレスタイプ、診断タイプ、およびMTA名型の定義は、RFC 3464のものと同一です。

3.2. Per-Message MTSN Fields

3.2. メッセージごとのMTSNフィールズ

Some fields of an MTSN apply to all of the addresses in a single envelope. These fields may appear at most once in any MTSN. These fields are used to correlate the MTSN with the original message transaction and to provide additional information which may be useful to gateways.

MTSNの一部のフィールドは、単一の封筒にアドレスのすべてに適用されます。これらのフィールドは、任意のMTSNで、最高1回表示されることがあります。これらのフィールドは、元のメッセージトランザクションにMTSNを相関させるとゲートウェイに有用であり得る付加的な情報を提供するために使用されます。

per-message-fields = original-envelope-id-field CRLF reporting-mta-field CRLF arrival-date-field CRLF *( extension-field CRLF )

メッセージごとのフィールド=元のエンベロープ-IDフィールドCRLF報告-MTA-フィールドCRLF到着日付フィールドCRLF×（拡張フィールドCRLF）

3.2.1. The Original-Envelope-Id field

3.2.1. オリジナル・封筒-Idフィールド

The Original-Envelope-Id field is defined as in section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED.

オリジナルエンベロープ-IDフィールドは、[RFC-DSN-STAT]のセクション2.2.1で定義した通りです。この項目は必須です。

3.2.2. The Reporting-MTA field

3.2.2. 報告-MTAフィールド

The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN-STAT]. This field is REQUIRED.

レポート-MTAフィールドは、[RFC-DSN-STAT]のセクション2.2.2で定義した通りです。この項目は必須です。

3.2.3. The Arrival-Date field

3.2.3. 到着-Dateフィールド

The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN-STAT]. This field is REQUIRED.

到着日付フィールドは、[RFC-DSN-STAT]のセクション2.2.5で定義した通りです。この項目は必須です。

3.3. Per-Recipient MTSN fields

3.3. 受信者ごとのMTSNフィールド

An MTSN contains information about attempts to deliver a message to one or more recipients. The delivery information for any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line.

MTSNは、1つまたは複数の受信者にメッセージを配信しようとする試みに関する情報が含まれています。任意の特定の受信者の配信情報は、隣接ごとの受信者フィールドのグループに含まれています。受信者ごとのフィールドの各グループは、空白行が先行しています。

The syntax for the group of per-recipient fields is as follows:

次のように受信者ごとのフィールドのグループのための構文は次のとおりです。

per-recipient-fields = original-recipient-field CRLF final-recipient-field CRLF action-field CRLF status-field CRLF [ remote-mta-field CRLF ] [ last-attempt-date-field CRLF ] [ will-retry-until-field CRLF ] *( extension-field CRLF )

受信者ごとのフィールド=元・受信者フィールドCRLF最終受信者フィールドCRLFアクション・フィールドCRLFステータス・フィールドCRLF [リモートMTAフィールドCRLF] [最後の試み - 日付フィールドCRLF] [意志-リトライまで-field CRLF] *（拡張フィールドCRLF）

3.3.1. Original-Recipient field

3.3.1. オリジナル・受信者フィールド

The Original-Recipient field is defined as in section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED.

元の受信者フィールドは、[RFC-DSN-STAT]のセクション2.3.1で定義した通りです。この項目は必須です。

3.3.2. Final-Recipient field

3.3.2. 最終受信者フィールド

The required Final-Recipient field is defined as in section 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED.

必要な最終受信者フィールドは、[RFC-DSN-STAT]のセクション2.3.2で定義した通りです。この項目は必須です。

3.3.3. Action field

3.3.3. アクションフィールド

The required Action field indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient address. This field MUST be present for each recipient named in the MTSN. The syntax is as defined in RFC 3464. This field is REQUIRED.

必要なアクションフィールドは、この受信者アドレスにメッセージを配信する試みの結果として報告-MTAによって実行されるアクションを示します。このフィールドはMTSNに指定された各受信者のために存在しなければなりません。このフィールドは必須ですRFC 3464.で定義されている構文は次のとおりです。

Valid actions are:

有効なアクションは以下のとおりです。

failed The message could not be delivered. If DSNs have been enabled, a "failed" DSN should already have been returned.

メッセージを配信することができませんでしたが失敗しました。 DSNが有効になっている場合は、DSNが既に返されていなければならない「失敗しました」。

delayed The message is currently waiting in the MTA queue for future delivery. Essentially, this action means "the message is located, and it is here."

メッセージは、現在、将来の配信のためにMTAキュー内で待機状態になっている遅れます。基本的に、このアクションは、「メッセージが配置されて、それがここにある」を意味します。

delivered The message has been successfully delivered to the final recipient. This includes "delivery" to a mailing list exploder. It does not indicate that the message has been read. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.

配信されたメッセージが正常に最後の受信者に配信されました。これは、メーリングリストエクスプローダに「配信」を含みます。これは、メッセージが読まれたことを示すものではありません。これ以上の情報はありません。具体的には、追跡エージェントはさらに、「下流」の追跡要求を試みるべきではありません。

expanded The message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. However, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests.

拡張されたメッセージが正常に送信者によって指定された受信者のアドレスに配信され、複数の追加の受信者のアドレスにその宛先を超えて報告-MTAによって転送されてきました。しかし、これらの追加のアドレスは追跡可能ではない、と追跡エージェントはさらに、「下流」の追跡要求を試みるべきではありません。

relayed The message has been delivered into an environment that does not support message tracking. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.

中継されたメッセージは、メッセージ追跡をサポートしていない環境に配信されています。これ以上の情報はありません。具体的には、追跡エージェントはさらに、「下流」の追跡要求を試みるべきではありません。

transferred The message has been transferred to another MTRK-compliant MTA. The tracking agent SHOULD attempt further "downstream" tracking requests unless that information is already given in a chaining response.

メッセージは別のMTRK準拠のMTAに転送された転送。その情報はすでに連鎖反応に与えられている場合を除き、追跡エージェントはさらに、「下流」の追跡要求を試みるべきです。

opaque The message may or may not have been seen by this system. No further information is available or forthcoming.

不透明なメッセージがよく、または、このシステムによって見られていない可能性があります。それ以上の情報が利用可能か、今後のではありません。

There may be some confusion between when to use "expanded" versus "delivered". Whenever possible, "expanded" should be used when the MTA knows that the message will be sent to multiple addresses. However, in some cases the delivery occurs to a program which, unknown to the MTA, causes mailing list expansion; in the extreme case, the delivery may be to a real mailbox that has the side effect of list expansion. If the MTA cannot ensure that this delivery will cause list expansion, it should set the action to "delivered".

「配信」対「拡大」を使用するときの間にいくつかの混乱があるかもしれません。 MTAは、メッセージが複数のアドレスに送信されますことを知っているとき、可能な限り、「拡大」を使用する必要があります。しかし、いくつかのケースで配信は、メーリングリストの展開を引き起こしMTAに未知の、プログラムに発生します。極端な場合には、送達は、リストの展開の副作用を有している実際のメールボックスにしてもよいです。 MTAは、この配信は、リストの展開を引き起こすだろうことを保証することができない場合は、「配信」するアクションを設定する必要があります。

3.3.4. Status field

3.3.4. Statusフィールド

The Status field is defined as in RFC 3464. A new code is added to RFC 3463 [RFC-EMSSC], "Enhanced Mail System Status Codes",

Statusフィールドは、新しいコードはRFC 3463 [RFC-EMSSC]、「強化されたメールシステムステータスコード」に追加されたRFC 3464.のように定義され、

X.1.9 Message relayed to non-compliant mailer"

非対応のメーラーに中継X.1.9メッセージ」

The mailbox address specified was valid, but the message has been relayed to a system that does not speak this protocol; no further information can be provided.

指定されたメールボックスのアドレスが有効であったが、メッセージはこのプロトコルを話すことはありませんシステムに中継されています。これ以上の情報はありませんすることができます。

A 2.1.9 Status field MUST be used exclusively with a "relayed" Action field. This field is REQUIRED.

2.1.9 Statusフィールドは「中継された」Actionフィールドで独占的に使用しなければなりません。この項目は必須です。

3.3.5. Remote-MTA field

3.3.5. リモートMTAフィールド

The Remote-MTA field is defined as in section Reference 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if no delivery attempts have been made or if the Action field has value "opaque". If delivery to some agent other than an MTA (for example, a Local Delivery Agent) then this field MAY be included, giving the name of the host on which that agent was contacted.

リモートMTAフィールドは、[RFC-DSN-STAT]のセクション2.3.5参照のように定義されています。何の配達の試みが行われていない場合、このフィールドは含んではいけませんまたはアクション・フィールドは、「不透明な」値を持っている場合。 MTA以外のいくつかのエージェントへの配信は、（例えば、ローカル配信エージェント）は、このフィールドが含まれていてもよい場合は、そのエージェントが連絡されたホストの名前を与えます。

3.3.6. Last-Attempt-Date field

3.3.6. 最終試行-Dateフィールド

The Last-Attempt-Date field is defined as in section Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt has been made and the Action field does not have value "opaque", in which case it will specify when it last attempted to deliver this message to another MTA or other Delivery Agent. This field MUST NOT be included if no delivery attempts have been made.

最終試行-Dateフィールドは、[RFC-DSN-STAT]のセクションリファレンス2.3.7のように定義されます。すべての配送の試みがなされているとActionフィールドが最後に別のMTAや他の配信エージェントにこのメッセージを配信しようとしたとき、それが指定されます。その場合には「不透明」の値を、持っていない場合、このフィールドは必須です。何の配達の試みが行われていない場合、このフィールドは含んではいけません。

3.3.7. Will-Retry-Until field

3.3.7. - 再試行されます-までフィールド

The Will-Retry-Until field is defined as in section Reference 2.3.9 of [RFC-DSN-STAT]. If the message is not in the local queue or the Action field has the value "opaque" the Will-Retry-Until field MUST NOT be included; otherwise, this field SHOULD be included.

ウィル・リトライまでのフィールドは、[RFC-DSN-STAT]のセクションリファレンス2.3.9のように定義されます。メッセージはローカルキューにない場合、または[アクション]フィールドには「不透明」値を持っている場合はウィル・リトライまでのフィールドを含んではいけません。そうでない場合は、このフィールドは含まれるべきです。

3.4. Extension fields

3.4. 拡張フィールド

Future extension fields may be defined as defined in section 2.4 of [RFC-DSN-STAT].

[RFC-DSN-STAT]のセクション2.4で定義されるように、将来の拡張用のフィールドが定義されてもよいです。

3.5. Interaction Between MTAs and LDAs

3.5. MTAとのLDAの相互作用

A message that has been delivered to a Local Delivery Agent (LDA) that understands message tracking (in particular, an LDA speaking LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the tracking request to the LDA. In this case, the Action field for the MTA->LDA exchange will look the same as a transfer to a compliant MTA; that is, a "transferred" tracking status will be issued.

メッセージ追跡を理解するローカル配信エージェント（LDA）に配信されたメッセージ（特に、MTRK拡張をサポートLDA話すLMTP [RFC-LMTP]）はLDAに追跡要求を通過させなければなりません。この場合、MTA-> LDA交換のためのアクション・フィールドは、対応のMTAへの転送と同じになります。つまり、「転送」追跡ステータスが発行されます。

4. Security Considerations

4.セキュリティについての考慮事項

4.1. Forgery

4.1. 偽造

Malicious servers may attempt to subvert message tracking and return false information. This could result in misdirection or misinterpretation of results.

悪意のあるサーバーは、メッセージ追跡を破壊し、偽の情報を返すことを試みることができます。これはミスディレクションや結果の誤った解釈につながる可能性があります。

4.2. Confidentiality

4.2. 機密性

Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding messages but does not wish to divulge the address to which the messages are autoforwarded. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses.

セキュリティのもう一つの次元は機密性です。メッセージの受信者がメッセージを自動転送されますが、メッセージが自動転送されたアドレスを明かしたくないするケースがあるかもしれません。そのような機密性への欲求は、おそらくより広く自動転送アドレスとして使用されるようになって、ページャとして「ワイヤレスメールボックス」、と高めることになります。

MTA authors are encouraged to provide a mechanism which enables the end user to preserve the confidentiality of a forwarding address. Depending on the degree of confidentiality required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of:

MTA著者は、転送先アドレスの機密性を保持するために、エンドユーザーを可能にするメカニズムを提供することが奨励されています。必要な機密性の程度、およびメッセージが転送された先の環境の性質に応じて、これは、一つ以上によって達成されることがあります。

(a) respond with a "relayed" tracking status when a message is forwarded to a confidential forwarding address, and disabling further message tracking requests.

（a）は、メッセージが機密転送先アドレスに転送されたときの状態を追跡し、さらにメッセージ追跡要求を無効にする「中継」で応答します。

(b) declaring the message to be delivered, issuing a "delivered" tracking status, re-sending the message to the confidential forwarding address, and disabling further message tracking requests.

（b）は、メッセージが配信されるように宣言機密転送先アドレスにメッセージを再送信し、さらにメッセージ追跡要求を無効にする、状態を追跡「配信」を発行します。

The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list.

追跡アルゴリズムは、リストの展開を通じて追跡許してはなりません。メッセージがリストに配信されると、追跡要求は、「拡大」のトラッキング状態で応じなければなりませんし、リストの内容を表示してはなりません。

5. IANA Considerations

5. IANAの考慮事項

IANA has registered the SMTP extension defined in section 3.

IANAはセクション3で定義されたSMTP拡張を登録しました。

6. Acknowledgements

6.謝辞

Several individuals have commented on and enhanced this document, including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.

いくつかの個人はトニーハンセン、フィリップ・ヘイゼル、アレクセイ・メルニコフ、リンドンNerenberg、クリス・ニューマン、グレゴリー・ニールシャピロ、そしてダン・ウィングを含め、この文書をについてコメントし、強化しました。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004.

[RFC-MTRK-MODEL]ハンセン、T.、 "メッセージ追跡モデルと要件"、RFC 3888、2004年9月。

[RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC 3887, September 2004.

[RFC-MTRK-MTQP]ハンセン、T.、 "メッセージ追跡照会プロトコル"、RFC 3887、2004年9月。

[RFC-MTRK-SMTPEXT] Allman, E., "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[RFC-MTRK-SMTPEXT]オールマン、E.、 "メッセージ追跡のためのSMTPサービス拡張"、RFC 3885、2004年9月。

[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[RFC-ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。

[RFC-EMSSC] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[RFC-EMSSC]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。

[RFC-HOSTREQ] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

[RFC-HOSTREQ]ブレーデン、R.、エド、 "インターネットホストのための要件 - 、アプリケーションとサポート"。、STD 3、RFC 1123、1989年10月。

[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC-MIME]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.

[RFC-MSGFMT]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。

[RFC-RELATED] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[RFC-RELATED]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。

7.2. Informational References

7.2. 情報の参照

[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[RFC-DSN-SMTP]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。

[RFC-DSN-STAT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[RFC-DSN-STAT]ムーア、K.とG.ボードルイ、RFC 3464、2003年1月、 "配信状態通知のための広げることができるメッセージフォーマット"。

[RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin, J., and N. Freed, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.

[RFC-ESMTP]ローズ、M.、Stefferud、E.、クロッカー、D.、Klensin、J.、およびN.フリード、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。

[RFC-LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

[RFC-LMTP]マイヤーズ、J.、 "ローカルメール転送プロトコル"、RFC 2033、1996年10月。

[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.

[RFC-MDN]ハンセン、T.およびG.ボードルイ、編、 "メッセージ処分通知"、RFC 3798、2004年5月。

8. Author's Address

8.著者のアドレス

Eric Allman Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 U.S.A.

エリック・オールマンのSendmail社6425クリスティアベニュー、4階エメリービル、CA 94608 U.S.A.

Phone: +1 510 594 5501 Fax: +1 510 594 5429 EMail: eric@Sendmail.COM

電話：+1 510 594 5501ファックス：+1 510 594 5429 Eメール：eric@Sendmail.COM

9. Full Copyright Statement

9.完全な著作権声明

著作権（C）インターネット協会（2004）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。