3.1. The message/tracking-status content-type

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

message/tracking-status 内容型は次のように定義します。

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.

7bit 符号化が十分であり、非 MIME メイル読取り器で表示する時の可読性を維持するために 7bit を使わなければなりません。

Security considerations

discussed in section 4 of this memo.

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:

message/tracking-status の本体は RFC 3464 のものを基にしています。本体は RFC 2822 頭欄の ABNF fields に従って書式付けした一つ以上の欄から成ります。 まずはじめにメッセージ毎の欄が来て、空行が続きます。 その後に一つ以上の受信者毎の欄の群が来ます。受信者毎の欄群それぞれの前には空行が来ます。 なお、欄の最後に1つ CRLF が必要であり、 MIME 境界線の最初にも1つ必要ですから、 最後の受信者毎欄と MIME 境界線の間には空行が入ります。正式には message/tracking-status 内容の構文は次の通りです。

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

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.2. Per-Message MTSN Fields

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 に高々一度出現し得ます。 これらの欄は MTSN を元のメッセージ取引と関係付けるためと、 関門に有用かもしれない追加情報を提供するために使います。

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

3.3. Per-Recipient MTSN fields

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 は一人以上の受信者にメッセージを配送しようとした試行についての情報を含みます。 ある特定の受信者についての配送情報は続く受信者毎の欄の群に含まれます。 受信者毎の欄の群それぞれは空行が前に来ます。

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 )

3.4. Extension fields

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

将来拡張欄が RFC 3464 の2.4節で定義されているように定義されるかもしれません。

3.5. Interaction Between MTAs and LDAs

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 拡張に対応した LMTP を話す LDA に配送されたメッセージは、追跡要求を LDA に渡すべきです。 この場合、 MTA→LDA 交換の Action 欄は適合 MTA へ転送するのと同じようにします。 つまり、 transferred 追跡状態とします。

4.1. Forgery

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

悪意ある鯖がメッセージ追跡を妨害して虚偽の情報を返そうとするかもしれません。 その結果、結果の誤解・誤指示が起こるかもしれません。

4.2. Confidentiality

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.
• (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.

• メッセージが機密転送番地に転送された時に relayed 追跡状態で応答し、それ以上のメッセージ追跡要求は無効化する。
• メッセージが配送されたとして delivered 追跡状態とし、機密転送番地にメッセージを転送し、 それ以上のメッセージ追跡要求は無効化する。

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.

追跡の算法はメイリング・リスト展開をこえて追跡することを認めてはなりません。 メッセージがリストに配送された時に、転送要求は expanded 追跡状態で応答しなければなりませんし、 リストの内容を表示してはなりません。

7.1. Normative References

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

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

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

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

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

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

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

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

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

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

7.2. Informational References

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

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

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

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

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