[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
に送らないように心がけるべきだというのは確かです。
MUA も ML 経由の MDN 要求は受け付けないようにするといいかもしれません。
(例えば List-Post
付きで
Disposition-Notification-To
の宛先の鯖が List-Post
と違っていた時は ML 経由と判断する、とか。)
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 は "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 を挿入できます。注釈内 では MIME の encoded-word が使えます。
address-type と MTA-name-type は、 message/delivery-status媒体型 で定義されているものと同じです。
要するに(謎)、多くの領域の定義で *text が使われてますが、 これを 2822.unstructured に読み替えてもいいですか? 読み替えたいなあ。読み返させてください。ってことです。
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 の値は大文字・小文字を区別しない。
manual-action | 自動動作じゃなくて、利用者の明示的操作です。 |
automatic-action | 利用者の動作じゃなくて、自動動作です。 |
MDN-sent-manually | この MDN 送信を利用者は明示的に許可しました。 |
MDN-sent-automatically | MUA の設定で自動的に送信されました。 |
上の2つ、下の2つはそれぞれ排他的です。
displayed | MUA は誰かにメッセージを見せました。読んで理解したかは知りません。 |
dispatched | メッセージを何か (印刷・FAX・転送など) しました。それ以前・以後に読まれたかはしりません。 |
processed | 読まれる前に何か処理 (規則に従ってどーとか) しました。後から読まれるかは知りません。そもそも人間受信者がいるメイル箱じゃないかも。 |
deleted | メッセージは削除されました。読んだかどうかは知りません。後で拾って読まれる可能性もあるにはあります。 |
denied | 受信者は送信者への通知を拒否しました。まあこの場合、 MDN 自体送られないかもね。 |
failed | 適当な MDN を生成出来ませんでした。詳しいことは Failure: 領域にあるかも。(MDN 生成要求の解釈を除く) メッセージ処理の失敗にこれを使っては駄目。 ("processed" を使う。) |
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 format | Disposition-Notification-Options で指定された書式に対応していません。 |
Failure: unsupported MIC-algorithms | Disposition-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 でおもしろくない。
"error" disposition-modifier の追加情報。
"failure" disposition-type ("failed" のことか?) の追加情報。
非 Internet メイル系統の MDN (相当)を、この MDN 形式に 変換した MTA の名前を書きます。
そういう書き換え関門 MTA は、必ずこの領域をかかなければなりません。 そうでない MTA は、書いてはいけません。
そのまま。元メッセージに Message-ID:領域がある場合は必須。
MDN に書かれてる disposition をした UA の名前を書きます。 Internet メイルの UA の場合は、次の例1の如く、 MDN 生成ホストの DNS 名と UA 名を書くのが 推奨されています。
RFC 2298 の定義では、 ua-name と ua-product を後から分離できません。 Internet DNS の名前 に ";" は登場しないはずですから、実際には大丈夫かも しれませんが。次のように実装することを提案します。
product-token は usefor-article で定義されたもの User-Agent:領域参照で、但し UTF8-xtra を使わない、 とします。
この再定義はもとの定義を厳格にするものであって、もとの定義には 反しません。
例:
例によって、実験目的に。 See also message/delivery-status媒体型 の同じ領域
標準化過程 or 実験 RFC で定義して、 IANA に登録。 See also message/delivery-status媒体型 の同じ領域
欄名 | 説明 | 状態 | 出典 |
Received-content-MIC: | MIC | IETF 提案標準 | [IANAREG], RFC 3335 |
[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