550.txt

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

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

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

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

詳しくは [CODE(MIME)[[[multipart/report]]]] を参照してください。

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

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

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

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

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

* 仕様書

[REFS[
- [1] [[RFC 3503]]: Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
- [2] [[IANAREG]] ''Message Disposition Notifications (MDN) Parameters'' <http://www.iana.org/assignments/mdn/mdn.htm>
- [15] [[[IANAREG]]] ''MDN-Dispostion-modifier-names'' <http://www.iana.org/assignments/mdn/disp-mod/index.html>
- [13] [[[IANAREG]]] ''MDN-Extension-field-names'' <http://www.iana.org/assignments/mdn/ext-field-names/index.html>
]REFS]

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

*

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

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

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

* 定義

[23] 
>
[PRE[
   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.
]PRE]

;; [24] [CITE@en[RFC 4356 - Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail]] 
<http://tools.ietf.org/html/rfc4356#section-1.3>

* CTE

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


* メッセージ構造

[PRE[
     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 )
]PRE]

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


** *-type

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


** 折畳み

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

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


* 領域


** Disposition: 領域 (必須)

[PRE[
     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
]PRE]

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


*** disposition-mode

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

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


*** disposition-type

,displayed	,MUA は誰かにメッセージを見せました。読んで理解したかは知りません。
,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]] を使っていますが、
[CODE(MDN)@en[disposition-modifier]] 以降の部分で [[RFC 2298]]
と違った構文を規定しています。
[[RFC 4130]] ([[インターネットEDI]] ([[HTTP]]); [[AS2]],
[[IETF}] [[提案標準]]) ではそれが明確にされています。]]

[3] [[RFC 3335]] ([[インターネットEDI]], [[IETF]] [[提案標準]]) 5.3.2.2
,[CODE(MDN)@en[Failure: unsupported format]]	,[CODE(822)@en[[[Disposition-Notification-Options]]]] で指定された書式に対応していません。
,[CODE(MDN)@en[Failure: unsupported MIC-algorithms]]	,[CODE(822)@en[[[Disposition-Notification-Options]]]] で指定された [[MIC]] [[算法]]に対応していません。

[10] [[RFC 3335]] ([[インターネットEDI]], [[IETF]] [[提案標準]]) 5.3.2.3
,[CODE(MDN)@en[Error: decryption-failed]]	,[[受信者]]は[[メッセージ]][[内容]]を[[解読]]できませんでした。
,[CODE(MDN)@en[Error: authentication-failed]]	,[[受信者]]は[[送信者]]を[[認証]]できませんでした。
,[CODE(MDN)@en[Error: integrity-check-failed]]	,[[整合性]]を確認できませんでした。
,[CODE(MDN)@en[Error: unexpected-processing-error]]	,その他の処理誤りが発生しました。

[12] [[RFC 3335]] 
([[インターネットEDI]], [[IETF]] [[提案標準]]) 5.3.2.3 
,"[CODE(MDN)@en[Warning: authentication-failed, processing continued]]"

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

[14] [[IANA]] 登録簿より:
-Alternative-preferred	[RFC3297]
-Original-lost	[RFC3297]
-warning	[RFC4130]

** Error: 領域

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

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

[[#comment]]


** Failure: 領域

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

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

[[#comment]]


** Final-Recipient: 領域 (必須)

See [[message/delivery-status媒体型]]


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

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

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

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


** Original-Message-ID: 領域

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

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


** Original-Recipient: 領域 (省略可)

See [[Original-Recipient:領域]]


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

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

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

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

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

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

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

例:

= Reporting-UA:  rogers-mac.dcrt.nih.gov; Foomail 97.1
= 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媒体型]]
の同じ領域

,欄名	,説明	,状態	,出典
,[CODE(MDN)@en[[[Received-content-MIC]]:]]	,[[MIC]]	,[[IETF]] [[提案標準]]	,"[IANAREG], [[RFC 3335]]"

[[#comment]]


* 関連

- [[multipart/report媒体型]]
- [[message/delivery-status媒体型]]
- [[message/rfc822媒体型]]
-- [[Disposition-Notification-To:領域]]
-- [[Disposition-Notification-Options:領域]]
-- [[Original-Recipient:領域]]

* 歴史

[25] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]]
( ([TIME[2014-09-07 15:46:36 +09:00]] 版))
<http://tools.ietf.org/html/rfc3801#section-4.7>

[26] [CITE@en[RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)]]
( ([TIME[2014-09-21 21:13:43 +09:00]] 版))
<http://tools.ietf.org/html/rfc4130>