[1] メッセージの配送状況 (エラーとか。) を返す時に使う 媒体型です。 multipart/report媒体型で使います。 DSN と略します。
[2] message/delivery-status 媒体型のデータは、 必ず 7bit になるので、それ以外の値をこれを含む実体の Content-Transfer-Encoding:欄に指定することは 出来ません。
| 引数名 | 引数値 | 既定値 | 説明 | 状態 | 出典 |
name | ファイル名 | 非標準 →Content-Disposition filename |
各 fields は、 RFC 822 の fields と同じ構文と定義されています。 折畳みできますし、注釈を挿入できます。注釈の中には MIME encoded-word がかけます。領域名は大文字・小文字を区別しません。
xtext では SP / TAB は無視されます。 (comment も無視されます。)
xtext では encoded-word は使えません。
xtext は、 DSN 領域の幾つかの領域本文で使うことになってますが、 どの領域でも使えません。 (どの領域の定義にも無い。)
| address-type | atom | メイル箱アドレス形式 |
| diagnostic-type | atom | 状態符号 status code 形式 |
| MTA-name-type | atom | MTA 名形式 |
この3つの *-type の値は、大文字・小文字を区別しません。 使える値は IANA 登録簿にあるものか、 "X-" で始まる実験用の 値です。
Internet メイルでは、 RFC 1891 で定義された次の値を使います。 (ちなみに、現時点でこの他の値は IANA 登録簿にありません。)
address-type には "unknown" という値も使えるようです。 (Original-Recipient: 領域)
RFC 1891 で定義されています。値は RFC 822 の <[route] addr-epec> になります。
RFC 1891 は、この値は US-ASCII の図形文字以外は使わないと しています。しかしこれは間違いです。quoted-string や domain-literal で、非 US-ASCII 図形文字を使うことが 出来ます。
実装は、必要な場合は値を xtext で符号化するのが良いかもしれません。 ただ、 RFC 822 メイル・アドレスでは "+" は(頻繁ではないとはいえ) よく使われる文字ではあります・・・。
RFC 1891 によると、このとき値は
<*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text> と定義されます。例:
見てわかるとおり、受信側が元の SMTP 応答に復元するのは 不可能です。
値は数値。 UUCP 転送かなんかだろーか?
値は Internet ドメイン名です。このとき、値は DNS に登録されていて、メイル・アドレス
<postmaster@{値}> が有効でないといけないそうです。値は sub-domain *("." sub-domain) または "[" IPv4-address "]" です。現代的には、 RFC 2821 を参考に IPv6-address を使ってもいいかもしれません。
こういう定義になっているのは、アドレスの書式がメイル系統により 異なるからですが、それならどーして xtext にしなかったんでしょ。
per-recipient-fields =
[ original-recipient-field CRLF ]
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ diagnostic-code-field CRLF ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )報告 MTA がとった行動を書き入れます。値の大文字・小文字は 区別しません。
| failed | 配送失敗で、これ以上の報告は期待しても無駄です。 |
| delayed | 配送または中継不能ですが、後でやり直します。更なる遅延・配送成功・配送失敗の連絡が後から来るかもしれません。 |
| delivered | 配送は成功しました。 |
| relayed | 報告 MTA が責任を持てない領域へ中継または関門通過しました。この通知は送信者が当該受信者について希望しない限り送るべきではありません。 |
| expanded | 送信者が指定した受取先まで到着し、そこから複数の配送先へ飛ばされました。 |
"expanded" は "delivered" とは、 "expanded" は終着点にまで 達していないという点で異なります。
「alias」の場合は "expanded" を、メイル・リストの場合は "delivered" を使います。
メッセージ毎に使う時は、メッセージが報告 MTA に届いた時間 を書き入れます。
受信者毎に使う時は、報告 MTA が DSN を書いた時間を書き入れます。
失敗 "failed" または遅延 "delayed" の時に、その詳しい状況を書きます。
Remote-MTA: 領域がある場合は相手 MTA が言ってきた理由が、 そうでない時は報告 MTA の主張する理由が書かれているとみなします。
Diagnostic-Code 以外に文字の説明があるときは、 comment にして書き入れても良いそうです。 (どこに? って気もするが。
*text だと comment はかけないでしょ。 diagnostic-type の部分に 書くのかな?)
例:
Diagnostic-Code: X-Postfix; host mail.example.com[192.168.0.2] said:
554 delivery error: dd Sorry, your message to name@example.net cannot
be delivered. This account is over quota. - mail.example.netDiagnostic-Code: X-PostfixPost; maildir delivery failed: error writing message:
Disc quota exceededDiagnostic-Code: X-Bezeq-International-SMTP-out-Mail-Server; Name service error
for name=example.net type=A: Host not foundDiagnostic-Code: X--Email-service-for-IOL-isp--apoioaocliente-iol-pt--; host
mx.iol.pt[172.16.4.224] said: 550 5.1.1 unknown or illegal alias:
6c0a576ba9ea.6ba9ea6c0a57@iol.pt (in reply to RCPT TO command)非 Internet メイルの連絡形式から DSN に変換した時に、 その変換者の名前を書きます。
変換した時には必ずかかなければなりません。 それ以外の場合には使ってはいけません。
最終 MTA の記録 ID です。これは最終 MTA の記録と照合する時 に便利です。
RFC 1894 ではこの部分の小題が乱丁になってます。
報告 MTA が送ろうとしていた宛先を書き入れます。
報告 MTA は、その address-type 的に正しい構文の generic-address を書き入れることは期待されていません。配送系が受け取った そのままの宛先を書き入れます。但し、 CR や LF のような DSN の構造上問題があるものはそのままにしておく必要はありません。 (というか放っておいたらいけません。 (xtext で定義しておけば 良かったのにねえ。))
例:
最後に配送試行された時刻 (失敗・成功に関わらず。) です。 DSN のメッセージの Date:領域の時刻とは必ずしも一致しません。
特に、関門で DSN に変換する際には、 DSN の Date: 領域は 変換時刻が、 LAD: 領域には(関門の向こうの方で)最後に 試行された時刻が入ります。
時刻不明の際は書いてはいけません。
値は封筒の唯一識別子で、送信者または送信 MTA がつけたものです。 送信者が返却された報告を見て、どのメッセージに対するものか特定する のに使います。
なお、これは Message-ID ではありません。
メッセージ受信元の MTA の名前を書きます。 Internet メイルで SMTP の場合は、名前は HELO か EHLO で名乗られたもの にするべきで、ネットワーク・アドレスを comment で併記するべきです。 (併記形式は RFC 2821 の Received:領域の定義に倣うのがいいと思われます。)
通信中に失敗するなどした相手先の MTA の名前です。
DSN に書かれた処理 (配送・中継など) をしようとした MTA。
SMTP クライアントがサーバーに、 RCPT TO: ほげほげ、 と送ろうとして失敗した場合、クライアントは DSN を書くんだけど、 このクライアントのドメイン名がこの Reporting-MTA: 領域に 書かれる。サーバーのドメイン名は、 Remote-MTA: 領域に。
関門の向こうでエラーになって、戻って来た関門が DSN 形式 にエラー報告を変換するよーな時に、 Reporting-MTA: 領域 には元の(関門の向こうの)エラー報告 MTA を書く。 (で、この場合 関門 MTA = DSN を書く MTA ≒ Reporting-MTA: = 関門の向こうのエラー報告 MTA)
報告 MTA が複数の名前を持つ場合、メッセージ送信元側での 名前にするべき。 (Internet メイルからほんじゃらメイル(謎) への関門で、 Internet から送られてきたメイルがエラーで Internet にエラー報告を送り返す時に、ほんじゃら世界の名前 (ほんじゃら☆MTA☆例) じゃなくて Internet の名前 (foo.mta.example) を書く、ってことだろう。)
例:
遅延 "delayed" の時に、配送を中止する予定時刻を書き入れます。
遅延の時は省略可能、それ以外のときは使ってはいけません。
例によって、実験目的に利用出来ます。
Final-Recipient: 領域のメイル・アドレスが他の アドレスの別名であるときに使われるみたいです。 中身は他の *-Recipient: 領域と同じ。
その他の領域は、 IANA で登録しないといけません。 (登録簿は どれですか?)
拡張領域の目的は、
(a) 外部配送系の配送情報の情報から変換時の損失を失くすため。 このとき、 X400-Physical-Forwarding-Address みたいに 配送系の名前から始まるとよさげ。
(b) 特定転送系の診断情報を書くため。このとき、 SMTP-Remote-Recipient-Address みたいに転送系の名前から 始まるとよさげ。
(c) 特定 MTA の診断情報を書くため。このとき、 Foomail-Queue-ID みたいに MTA 実装名から始めるとよさげ。 MTA 開発者が一々 IANA に登録なんてめんどーだ、 と思いなさるなら、 X-Foomail-Log-ID みたいにすべし、と。
(Final-Log-ID: 領域って、ほんとは削除されるんだったんじゃないかなー?)
[6] 例:
X-Postfix-Queue-ID: 84863BC0E5X-Postfix-Sender: rfc822; foo@example.com-Email-service-for-IOL-isp--apoioaocliente-iol-pt--
((Email service for IOL isp (apoioaocliente@iol.pt))
)
って Postfix
のソース・コードを単純に置換したんじゃないか?
[22] DSN を UTF-8 を使えるように拡張したものが RFC 5337 で定義されています。
[30] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) <http://tools.ietf.org/html/rfc3801#section-4.6>