[要約] RFC 3503は、IMAPのためのMDNプロファイルであり、メッセージの受信確認や配信状況の通知を可能にする。目的は、IMAPクライアントとサーバー間でMDNを送受信するための標準化と一貫性を提供すること。
Network Working Group A. Melnikov
Request for Comments: 3503 ACI Worldwide/MessagingDirect
Category: Standards Track March 2003
Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
メッセージ処分通知（MDN）インターネットメッセージアクセスプロトコルのプロファイル（IMAP）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.
RFC 2298で定義されているメッセージ処分通知（MDN）施設は、メッセージが受信者によるメッセージ処理を認めることを要求できる手段と、そのような謝辞に使用する形式を提供します。ただし、複数のメールユーザーエージェント（MUA）がインターネットメッセージアクセスプロトコル（IMAP4）環境でMDNの生成を処理する方法は説明していません。
This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products.
このドキュメントでは、このような環境でMDNを処理する方法について説明し、製品にMDNサポートを追加したいIMAP4の実装者にガイドラインを提供します。
Table of Contents
目次
1. Conventions Used in this Document............................. 2
2. Introduction and Overview..................................... 2
3. Client behavior............................................... 3
3.1. Client behavior when receiving a message................. 5
3.2. Client behavior when copying a message................... 5
3.3. Client behavior when sending a message................... 5
3.4. Client behavior when saving a temporary message.......... 5
4. Server behavior............................................... 5
4.1. Server that supports arbitrary keywords.................. 5
4.2. Server that supports only $MDNSent keyword............... 5
4.3. Interaction with IMAP ACL extension...................... 6
5. Examples...................................................... 6
6. Security Considerations....................................... 7
7. Formal Syntax................................................. 7
8. Acknowledgments............................................... 7
9. Normative References.......................................... 8
10. Author's Address.............................................. 8
11. Full Copyright Statement...................................... 9
"C:" and "S:" in examples show lines sent by the client and server respectively.
「C：」と「S：」は、例ではそれぞれクライアントとサーバーによって送信された行を示しています。
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document when typed in uppercase are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワードは、「必要ではない」、「そうでなければ」、「すべきではない」、「そうでない」、および「必要」、「必要」、および「必要」は、大文字で入力されたときに、「要件レベルを示すためにRFCで使用するためのキーワード」で定義されると解釈されるべきです。[キーワード]。
This memo defines an additional [IMAP4] mailbox keyword that allows multiple Mail User Agents (MUAs) to know if a requested receipt notification was sent.
このメモは、複数のメールユーザーエージェント（MUA）が要求された領収書通知が送信されたかどうかを知ることができる追加の[IMAP4]メールボックスキーワードを定義します。
Message Disposition Notification [MDN] does not require any special support of IMAP in the case where a user has access to the mailstore from only one computer and is using a single MUA. In this case, the MUA behaves as described in [MDN], i.e., the MUA performs automatic processing and generates corresponding MDNs, it performs requested action and, with the user's permission, sends appropriate MDNs. The MUA will not send MDN twice because the MUA keeps track of sent notifications in a local configuration. However, that does not work when IMAP is used to access the same mailstore from different locations or is using different MUAs.
メッセージ処分通知[MDN]は、ユーザーが1つのコンピューターのみからメールストアにアクセスし、単一のMUAを使用している場合、IMAPの特別なサポートを必要としません。この場合、MUAは[MDN]で説明されているように動作します。つまり、MUAは自動処理を実行し、対応するMDNを生成し、要求されたアクションを実行し、ユーザーの許可を得て適切なMDNを送信します。MUAがローカル構成で送信通知を追跡しているため、MUAはMDNを2回送信しません。ただし、IMAPを使用して異なる場所から同じメールストアにアクセスするか、異なるMUAを使用している場合、それは機能しません。
This document defines a new special purpose mailbox keyword $MDNSent that must be used by MUAs. It does not define any new command or response for IMAP, but describes a technique that MUAs should use to achieve interoperability.
このドキュメントでは、MUASが使用する必要がある新しい特別な目的メールボックスキーワード$ mdnsentを定義します。IMAPの新しいコマンドまたは応答を定義するものではありませんが、MUAが相互運用性を実現するために使用すべき手法を説明しています。
When a client opens a mailbox for the first time, it verifies that the server is capable of storing the $MDNSent keyword by examining the PERMANENTFLAGS response code. In order to support MDN in IMAP, a server MUST support either the $MDNSent keyword, or arbitrary message keywords.
クライアントが初めてメールボックスを開くと、永続的なフラッグ応答コードを調べてサーバーが$ MDNSENTキーワードを保存できることを確認します。IMAPでMDNをサポートするには、サーバーは$ MDNSENTキーワードまたは任意のメッセージキーワードのいずれかをサポートする必要があります。
The use of IMAP requires few additional steps in mail processing on the client side. The following timeline modifies the timeline found in Section 4 of [MDN].
IMAPを使用するには、クライアント側でのメール処理に追加のステップはほとんど必要ありません。次のタイムラインは、[MDN]のセクション4にあるタイムラインを変更します。
-- User composes message.
- ユーザーはメッセージを作成します。
-- User tells MUA to send message.
- ユーザーはMUAにメッセージを送信するように指示します。
-- MUA passes message to MSA (original recipient information passed along). MUA [optionally] saves message to a folder for sent mail with $MDNSent flag set.
-MUAはメッセージをMSAに渡します（元の受信者情報が渡されました）。MUA [オプションで]は、$ MDNSENTフラグセットを使用して送信メールのフォルダーにメッセージを保存します。
-- MSA sends message to MTA.
-MSAはMTAにメッセージを送信します。
-- Final MTA receives message.
- 最終的なMTAはメッセージを受信します。
-- Final MTA delivers message to MUA (possibly generating DSN).
- 最終的なMTAはMUAにメッセージを配信します（おそらくDSNを生成）。
-- MUA logs into IMAP server, opens mailbox, verifies if mailbox can store $MDNSent keyword by examining PERMANENTFLAGS response.
-MUAはIMAPサーバーにログを記録し、メールボックスを開き、Mailboxが永続的なフラグ応答を調べて$ MDNSENTキーワードを保存できる場合に検証します。
-- MUA performs automatic processing and generates corresponding MDNs ("dispatched", "processed", "deleted", "denied" or "failed" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes) for messages that do not have $MDNSent keyword, or \Draft flag set. (*)
-MUAは自動処理を実行し、対応するMDNS（「ディスパッチ」、「処理」、「削除」、「拒否」、「失敗した」処分タイプを「自動アクション」、「MDN-Sent-Automately」処分モード）で生成します。$ mdnsentキーワード、または\ドラフトフラグセットを持たないメッセージ。（*）
-- MUA sets the $MDNSent keyword for every message that required an automatic MDN to be sent, whether or not the MDN was sent.
-MUAは、MDNが送信されたかどうかにかかわらず、自動MDNを送信する必要があるすべてのメッセージに対して$ MDNSENTキーワードを設定します。
-- MUA displays a list of messages to user.
-MUAは、ユーザーへのメッセージのリストを表示します。
-- User selects a message and requests that some action be performed on it.
- ユーザーはメッセージを選択し、何らかのアクションを実行するようにリクエストします。
-- MUA performs requested action and, with user's permission, sends appropriate MDN ("displayed", "dispatched", "processed", "deleted", "denied" or "failed" disposition type with "manual-action" and "MDN-sent-manually" or "MDN-sent-automatically" disposition mode). If the generated MDN is saved to a mailbox with the APPEND command, the client MUST specify the $MDNSent keyword in the APPEND.
-MUAは要求されたアクションを実行し、ユーザーの許可を得て、適切なMDN（「表示」、「ディスパッチ」、「処理」、「削除」、「拒否」、「マニュアルアクション」および「MDN」で送信します。-sent-andally "または" mdn-sent-automatical "処分モード）。生成されたMDNが追加のコマンドを使用してメールボックスに保存された場合、クライアントは付録の$ MDNSENTキーワードを指定する必要があります。
-- MUA sets the $MDNSent keyword for all messages for which the user confirmed the dispatching of disposition (or was explicitly prohibited to do so).
-MUAは、ユーザーが処分の派遣を確認した（またはそうすることを明示的に禁止されていた）すべてのメッセージに対して$ MDNSENTキーワードを設定します。
-- User possibly performs other actions on message, but no further MDNs are generated.
- ユーザーはメッセージで他のアクションを実行する可能性がありますが、それ以上のMDNは生成されません。
(*) Note: MUA MUST NOT use \Recent flag as an indicator that it should send MDN, because according to [IMAP4], "If multiple connections have the same mailbox selected simultaneously, it is undefined which of these connections will see newly-arrived messages with \Recent set and which will see it without \Recent set". Thus, using \Recent as an indicator will cause unpredictable client behavior with different IMAP4 servers. However, the client MAY use \Seen flag as one of the indicators that MDN must not be sent. The client MUST NOT use any other standard flags, like \Draft or \Answered, to indicate that MDN was previously sent, because they have different well known meaning. In any case, in the presence of the $MDNSent keyword, the client MUST ignore all other flags or keywords for the purpose of generating an MDN and MUST NOT send the MDN.
（*）注：[IMAP4]によれば、「IMAP4]によれば、MUAはMDNを送信する必要があるという指標として\最近のフラグを使用してはいけません。\最近のセットで到着したメッセージと、最近のセットなしで表示されます」。したがって、\最近をインジケーターとして使用すると、異なるIMAP4サーバーで予測不可能なクライアントの動作を引き起こします。ただし、クライアントは、MDNを送信してはならないという指標の1つとして、Seed Flagを使用する場合があります。クライアントは、\ドラフトや\回答などの他の標準フラグを使用して、MDNが以前に送信されたことを示してはなりません。いずれにせよ、$ MDNSENTキーワードの存在下で、クライアントはMDNを生成する目的で他のすべてのフラグまたはキーワードを無視する必要があり、MDNを送信してはなりません。
When the client opens a mailbox for the first time, it must verify that the server supports the $MDNSent keyword, or arbitrary message keywords by examining PERMANENTFLAGS response code.
クライアントが初めてメールボックスを開くとき、サーバーが$ MDNSENTキーワード、または永続的なフラグ応答コードを調べて任意のメッセージキーワードをサポートすることを確認する必要があります。
The client MUST NOT try to set the $MDNSent keyword if the server is incapable of storing it permanently.
サーバーが永久に保存できない場合、クライアントは$ MDNSENTキーワードを設定しようとしてはなりません。
The client MUST be prepared to receive NO from the server as the result of STORE $MDNSent when the server advertises the support of storing arbitrary keywords, because the server may limit the number of message keywords it can store in a particular mailbox. A client SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
サーバーが特定のメールボックスに保存できるメッセージキーワードの数を制限する可能性があるため、サーバーが任意のキーワードを保存するサポートを宣伝する場合、Store $ mdnsentの結果として、クライアントはサーバーからNOを受信する準備をする必要があります。$ MDNSENTキーワードの保存に失敗した場合、クライアントはMDNを送信しないでください。
Once the $MDNSent keyword is set, it MUST NOT be unset by a client. The client MAY set the $MDNSent keyword when a user denies sending the notification. This prohibits all other MUAs from sending MDN for this message.
$ MDNSENTキーワードが設定されたら、クライアントが設定してはなりません。ユーザーが通知の送信を拒否したときに、クライアントは$ MDNSENTキーワードを設定できます。これにより、他のすべてのMUAがこのメッセージに対してMDNを送信することを禁止しています。
The client MUST NOT send MDN if a message has the $MDNSent keyword set. It also MUST NOT send MDN if a message has \Draft flag, because some clients use this flag to mark a message as incomplete.
メッセージに$ MDNSENTキーワードセットがある場合、クライアントはMDNを送信してはなりません。また、メッセージに\ドラフトフラグがある場合はMDNを送信してはなりません。一部のクライアントは、このフラグを使用してメッセージを不完全としてマークするためです。
See the timeline in section 3 for details on client behavior when receiving a message.
メッセージを受信するときのクライアントの動作の詳細については、セクション3のタイムラインを参照してください。
The client SHOULD verify that $MDNSent is preserved on a COPY operation. Furthermore, when a message is copied between servers with the APPEND command, the client MUST set the $MDNSent keyword correctly.
クライアントは、$ mdnsentがコピー操作に保存されていることを確認する必要があります。さらに、Appendコマンドを使用してサーバー間でメッセージがコピーされると、クライアントは$ MDNSENTキーワードを正しく設定する必要があります。
When saving a sent message to any folder, the client MUST set the $MDNSent keyword to prevent another client from sending MDN for the message.
送信されたメッセージを任意のフォルダーに保存するとき、クライアントは$ MDNSENTキーワードを設定して、別のクライアントがメッセージのMDNを送信できないようにする必要があります。
When saving an unfinished message to any folder client MUST set $MDNSent keyword to prevent another client from sending MDN for the message.
フィニッシュメッセージをフォルダーに保存する場合、クライアントは$ MDNSENTキーワードを設定して、別のクライアントがメッセージのMDNを送信できないようにする必要があります。
Server implementors that want to follow this specification must insure that their server complies with either section 4.1 or section 4.2. If the server also supports the IMAP [ACL] extension, it MUST also comply with the section 4.3.
この仕様に従いたいサーバー実装者は、サーバーがセクション4.1またはセクション4.2に準拠していることを保証する必要があります。サーバーがIMAP [ACL]拡張機能もサポートする場合、セクション4.3にも準拠する必要があります。
No changes are required from the server to make it compatible with the extension described in this document if it supports arbitrary keywords.
任意のキーワードをサポートしている場合、このドキュメントで説明されている拡張機能と互換性のあるものにするために、サーバーから変更は必要ありません。
Servers that support only the $MDNSent keyword MUST preserve it on the COPY operation. It is also expected that a server that supports SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
$ mdnsentキーワードのみをサポートするサーバーは、コピー操作に保存する必要があります。また、検索<Flag>をサポートするサーバーが検索キーワード$ MDNSENTもサポートすることも期待されています。
Any server that conforms to either 4.1 or 4.2 and also supports the IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY even if the client does not have 'w' right. This will prevent the generation of a duplicated MDN for the same message. Note that the server MUST still check if the client has rights to perform the COPY operation on a message according to [ACL].
4.1または4.2のいずれかに適合し、IMAP [ACL]拡張機能をサポートするサーバーは、クライアントが「W」を正しくない場合でも、コピーの$ MDNSENTキーワードを保存する必要があります。これにより、同じメッセージの重複したMDNの生成が妨げられます。[ACL]に従って、メッセージでコピー操作を実行する権利がクライアントがいるかどうかをサーバーが確認する必要があることに注意してください。
1) MUA opens mailbox for the first time.
1) MUAは初めてメールボックスを開きます。
a) The server supports storing of arbitrary keywords
a) サーバーは、任意のキーワードの保存をサポートしています
C: a100 select INBOX
S: * FLAGS (\Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
S: * 5 EXISTS
S: * 3 RECENT
S: * OK [UIDVALIDITY 894294713]
S: a100 OK [READ-WRITE] Completed
b) The server supports storing of the $MDNSent keyword
b) サーバーは、$ mdnsentキーワードの保存をサポートしています
C: a100 select INBOX
S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
S: * 5 EXISTS
S: * 3 RECENT
S: * OK [UIDVALIDITY 894294713]
S: a100 OK [READ-WRITE] Completed
2) The MUA successfully sets the $MDNSent keyword
2) MUAは、$ MDNSENTキーワードを正常に設定します
C: a200 STORE 4 +FLAGS ($MDNSent)
S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
S: a200 OK STORE completed
3) The server refuses to store the $MDNSent keyword
3) サーバーは、$ MDNSENTキーワードの保存を拒否します
C: a200 STORE 4 +FLAGS ($MDNSent)
S: a200 NO STORE failed : no space left to store $MDNSent keyword
4) All clients and servers MUST treat the $MDNSent keyword as case
insensitive in all operations, as stated in [IMAP].
C: a300 FETCH 1:* FLAGS
S: * 1 FETCH (FLAGS (\Seen))
S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
S: * 3 FETCH (FLAGS ())
S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
S: * 5 FETCH (FLAGS ($MDNSent))
S: * 6 FETCH (FLAGS (\Recent))
S: a300 OK FETCH completed
C: a400 SEARCH KEYWORDS $mdnsent
S: * SEARCH 2 4 5
S: a400 OK SEARCH completed
There are no known security issues with this extension, not found in [MDN] and/or [IMAP4].
[MDN]および/または[IMAP4]には見られない、この拡張機能には既知のセキュリティの問題はありません。
Section 4.3 changes ACL checking requirements on an IMAP server that implements IMAP [ACL] extension.
セクション4.3は、IMAP [ACL]拡張機能を実装するIMAPサーバーのACLチェック要件を変更します。
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822], as modified by [IMAP4]. Non-terminals referenced, but not defined below, are as defined by [IMAP4].
次の構文仕様では、[RFC-822]で指定されているように、[IMAP4]で修正されているように、拡張されたBackus-Naurフォーム（BNF）表記を使用します。参照されている非末端は、以下では定義されていませんが、[IMAP4]で定義されています。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上または小文字または小文字の文字を使用することは、編集の明確性のみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
flag_keyword ::= "$MDNSent" / other_keywords
other_keywords ::= atom
This document is the product of discussions that took place on the IMAP mailing list. Special gratitude to Cyrus Daboo and Randall Gellens for reviewing the document.
このドキュメントは、IMAPメーリングリストで行われた議論の産物です。ドキュメントをレビューしてくれたCyrus DabooとRandall Gellensに特別な感謝。
Thank you to my father who as he has helped to make me what I am. I miss you terribly.
彼が私を作るのを手伝ってくれた父に感謝します。私はあなたがいなくて寂しいです。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MDN] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[MDN] Fajman、R。、「メッセージ処分通知のための拡張可能なメッセージ形式」、RFC 2298、1998年3月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[ACL] Myers、J。、「IMAP4 ACL Extension」、RFC 2086、1997年1月。
Alexey Melnikov ACI Worldwide/MessagingDirect 59 Clarendon Road Watford, Hertfordshire United Kingdom, WD17 1FQ
Alexey Melnikov Aci Worldwide/MessagingDirect 59 Clarendon Road Watford、Hertfordshire United、WD17 1FQ
Phone: +44 1923 81 2877
EMail: mel@messagingdirect.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。