STD 85

MDN (インターネットメール)

[3] MDN (Message Disposition Notification) は誤解を恐れずに一言で言ってしまうなら、開封通知のことです。 実際 M$OE なんかだと開封通知として実装されてます。 (ちょっとアレゲなところもありますが。)

RFC 2298 urn:ietf:rfc:2298 で定義されています。

[4] MDN のメッセージの媒体型には、 multipart/report を使います。その report-type パラメーターの値は disposition-notification となります。

multipart/report の第一部分は人間可読報告文, 第二部分が message/disposition-notification による機械可読報告です。第三部分が元メッセージの複製ですが、 MDN の性質的に、省略するのが普通でしょう。

詳しくは multipart/report を参照してください。

[5] DSN (message/delivery-status) と似たようなものではありますが、 そっちは MTA からの報告であるのに対して、こちらは MUA からの報告となります。

[6] MDN の宛先は、元メッセージの Disposition-Notification-To: 欄に指定されたものです。これが元メッセージの Return-Path: 欄に一致しない場合などには、 送信時に特に注意が必要です。 (事故や悪意により予期せぬ宛先に MDN が送られたり、循環したりするのを防ぐためです。) 詳しくは RFC 2298 を参照して下さい。

MDN の From: 欄は、 必ず元メッセージの宛先になります。封筒送信元 (envelope-from) は空 (<>) にしておかなければなりません

MDN は MDN を要求してはいけません

一つの MDN は元メッセージの一人の受信者に対応します。

仕様書

[7] RFC 3798 が6月に出て RFC 2298 は obsolete になりました。 (名無しさん 2004-07-12 08:33:27 +00:00)

[8] ML 宛のメッセージで MDN を要求するのはマナーに反するなどと主張する人がいます。 RFC によれば ML 宛に Disposition-Notification-To 付きメッセージを送った場合に反応するべきなのは ML 展開器 (駆動器) です。 ML 展開器が各参加者に転送する時に Disposition-Notification-To を落とすのが普通は正しい方法で、メッセージの元の送信者が悪いというのはお門違いです。

ただそういう機能を ML 展開器が実装していないことはよくある (MDN 仕様の欠陥だよね、ちゃんと RFC に書いてあるけど) ので、 送信者は自衛として MDN 要求付きで ML に送らないように心がけるべきだというのは確かです。 MUAML 経由の MDN 要求は受け付けないようにするといいかもしれません。 (例えば List-Post 付きで Disposition-Notification-To の宛先のList-Post と違っていた時は ML 経由と判断する、とか。)

[22] RFC 5337 では、 UTF-8 に対応した拡張された MDN が定義されています。

定義

[23]

   Disposition Report  |Feedback information to an originator User
                       |Agent by a recipient User Agent about
   Message Disposition |handling of an original message.  This may
      Notification     |include notification that the message was or
                       |was not read, was deleted unread, etc.

CTE

CTE は "7bit" で十分で、よって他のものはだめとされてます。

メッセージ構造

     disposition-notification-content = [ reporting-ua-field CRLF ]
          [ mdn-gateway-field CRLF ]
          [ original-recipient-field CRLF ]
          final-recipient-field CRLF
          [ original-message-id-field CRLF ]
          disposition-field CRLF
          *( failure-field CRLF )
          *( error-field CRLF )
          *( warning-field CRLF )
          *( extension-field CRLF )

RFC 822 メッセージ頭と同じと説明されています。 各頭領域は FWS で折畳み可能です。領域名は大文字・小文字を 区別しません。要素間に注釈 comment を挿入できます。注釈内 では MIMEencoded-word が使えます。

*-type

address-type と MTA-name-type は、 message/delivery-status媒体型 で定義されているものと同じです。

折畳み

くそー、折角書いた文章が IE のせいでおじゃんだよ。

要するに(謎)、多くの領域の定義で *text が使われてますが、 これを 2822.unstructured に読み替えてもいいですか? 読み替えたいなあ。読み返させてください。ってことです。

領域

Disposition: 領域 (必須)

     disposition-field = "Disposition" ":" disposition-mode ";"
                         disposition-type
                         [ '/' disposition-modifier
                           *( "," dispostion-modifier ) ]
     disposition-mode = action-mode "/" sending-mode
     action-mode = "manual-action" / "automatic-action"
     sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
     disposition-type = "displayed"
                      / "dispatched"
                      / "processed"
                      / "deleted"
                      / "denied"
                      / "failed"
     disposition-modifier = ( "error" / "warning" )
                          / ( "superseded" / "expired" /
                              "mailbox-terminated" )
                          / disposition-modifier-extension
     disposition-modifier-extension = atom

報告 MUA の利用者が何したか。 disposition-type, disposition-mode, disposition-modifier の値は大文字・小文字を区別しない。

disposition-mode

manual-action自動動作じゃなくて、利用者の明示的操作です。
automatic-action利用者の動作じゃなくて、自動動作です。
MDN-sent-manuallyこの MDN 送信を利用者は明示的に許可しました。
MDN-sent-automaticallyMUA の設定で自動的に送信されました。

上の2つ、下の2つはそれぞれ排他的です。

disposition-type

displayedMUA は誰かにメッセージを見せました。読んで理解したかは知りません。
dispatchedメッセージを何か (印刷・FAX・転送など) しました。それ以前・以後に読まれたかはしりません。
processed読まれる前に何か処理 (規則に従ってどーとか) しました。後から読まれるかは知りません。そもそも人間受信者がいるメイル箱じゃないかも。
deletedメッセージは削除されました。読んだかどうかは知りません。後で拾って読まれる可能性もあるにはあります。
denied受信者は送信者への通知を拒否しました。まあこの場合、 MDN 自体送られないかもね。
failed適当な MDN を生成出来ませんでした。詳しいことは Failure: 領域にあるかも。(MDN 生成要求の解釈を除く) メッセージ処理の失敗にこれを使っては駄目。 ("processed" を使う。)

disposition-modifier

errorメッセージ処理中になんかエラー。 Error: 領域参照。
warning処理中になんか警告。 Warning: 領域参照。
superseded他のメッセージにより自動的に更新された。とはいえ受信者はまだ参照可能かも。
expired期限切れで自動的に棄てられた。
mailbox-terminatedメイル箱ごと逝った。
disposition-modifier-extension標準化過程 or 実験 RFC で規定 + IANA に登録されたもの。
X-

"obsoleted" (まて、そんなのないぞ。 "superseded" のことか?), "expired", "terminated" (まて、(以下同じ)?) は、 "delete" disposition-type および "autoaction" ・ "autosent" disposition-modifier (まて、(以下同じ)?) と一緒に使う。

[9] RFC 3335 (インターネットEDI (SMTP), IETF 提案標準) は MDN を使っていますが、 disposition-modifier 以降の部分で RFC 2298 と違った構文を規定しています。 RFC 4130 (インターネットEDI (HTTP); AS2, IETF}) ではそれが明確にされています。]]

[3] RFC 3335 (インターネットEDI, IETF 提案標準) 5.3.2.2

Failure: unsupported formatDisposition-Notification-Options で指定された書式に対応していません。
Failure: unsupported MIC-algorithmsDisposition-Notification-Options で指定された MIC 算法に対応していません。

[10] RFC 3335 (インターネットEDI, IETF 提案標準) 5.3.2.3

Error: decryption-failed受信者メッセージ内容解読できませんでした。
Error: authentication-failed受信者送信者認証できませんでした。
Error: integrity-check-failed整合性を確認できませんでした。
Error: unexpected-processing-errorその他の処理誤りが発生しました。

[12] RFC 3335 (インターネットEDI, IETF 提案標準) 5.3.2.3

Warning: authentication-failed, processing continued

[11] 元の構文も EDI の構文も、 ad hoc でおもしろくない。

[14] IANA 登録簿より:

  • Alternative-preferred [RFC3297]
  • Original-lost [RFC3297]
  • warning [RFC4130]

Error: 領域

  1. error-field = "Error" ":" *text

"error" disposition-modifier の追加情報。

Failure: 領域

  1. failure-field = "Failure" ":" *text

"failure" disposition-type ("failed" のことか?) の追加情報。

Final-Recipient: 領域 (必須)

See message/delivery-status媒体型

MDN-Gateway: 領域 (場合により必須)

  1. mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
  2. mta-name = *text

非 Internet メイル系統の MDN (相当)を、この MDN 形式に 変換した MTA の名前を書きます。

そういう書き換え関門 MTA は、必ずこの領域をかかなければなりません。 そうでない MTA は、書いてはいけません

Original-Message-ID: 領域

  1. original-message-id-field = "Original-Message-ID" ":" msg-id

そのまま。元メッセージに Message-ID:領域がある場合は必須。

Original-Recipient: 領域 (省略可)

See Original-Recipient:領域

Reporting-UA: 領域 (省略可; 推奨)

  1. reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
  2. ua-name = *text
  3. ua-product = *text

MDN に書かれてる disposition をした UA の名前を書きます。 Internet メイルの UA の場合は、次の例1の如く、 MDN 生成ホストの DNS 名と UA 名を書くのが 推奨されています。

RFC 2298 の定義では、 ua-name と ua-product を後から分離できません。 Internet DNS の名前 に ";" は登場しないはずですから、実際には大丈夫かも しれませんが。次のように実装することを提案します。

  1. reporting-ua-field = "Reporting-UA:" FWS ua-name [ ";" [CFWS] ua-product ] [CFWS]
  2. ua-name = *ptext / quoted-string
  3. ua-product = product-token
  4. ptext = %x00-3A / %x3C-7F ;; text except ";"

product-token は usefor-article で定義されたもの User-Agent:領域参照で、但し UTF8-xtra を使わない、 とします。

この再定義はもとの定義を厳格にするものであって、もとの定義には 反しません。

例:

  1. Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
  2. Reporting-UA: "foo-name-including-a-;-example"; Foomail/97.2

Warning: 欄

Warning

X-*: 領域

例によって、実験目的に。 See also message/delivery-status媒体型 の同じ領域

その他の領域

標準化過程 or 実験 RFC で定義して、 IANA に登録。 See also message/delivery-status媒体型 の同じ領域

欄名説明状態出典
Received-content-MIC:MICIETF 提案標準[IANAREG], RFC 3335

関連

[18] AS2

歴史

[17] RFC 3503 - Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP), , https://tools.ietf.org/html/rfc3503

[25] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) http://tools.ietf.org/html/rfc3801#section-4.7

[26] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ( ( 版)) http://tools.ietf.org/html/rfc4130

[16] RFC 8098 - Message Disposition Notification () https://tools.ietf.org/html/rfc8098

[19] RFC 4249: Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components, https://www.rfc-editor.org/rfc/rfc4249.html#section-3.1.2.2.4