Network Working Group A. Melnikov
Request for Comments: 3503 ACI Worldwide/MessagingDirect
Category: Standards Track March 2003
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)
Internet消息访问协议（IMAP）的消息处置通知（MDN）配置文件
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.
版权所有（C）互联网协会（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）如何在Internet消息访问协议（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
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].
本文件中的关键字“必须”、“不得”、“应该”、“不应该”和“可能”在大写时应按照“RFCs中用于指示需求水平的关键字”[关键字]中的定义进行解释。
This memo defines an additional [IMAP4] mailbox keyword that allows multiple Mail User Agents (MUAs) to know if a requested receipt notification was sent.
此备忘录定义了一个额外的[IMAP4]邮箱关键字，允许多个邮件用户代理（MUA）知道是否发送了请求的接收通知。
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.
如果用户只能从一台计算机访问邮件存储并使用单个MUA，则消息处置通知[MDN]不需要IMAP的任何特殊支持。在这种情况下，MUA的行为如[MDN]中所述，即MUA执行自动处理并生成相应的MDN，它执行请求的操作，并在用户许可的情况下发送适当的MDN。MUA不会两次发送MDN，因为MUA在本地配置中跟踪已发送的通知。但是，当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定义任何新的命令或响应，但描述了MUAs应使用的实现互操作性的技术。
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.
当客户端第一次打开邮箱时，它通过检查PERMANENTFLAGS响应代码来验证服务器是否能够存储$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服务器，打开邮箱，通过检查PERMANENTFLAGS响应验证邮箱是否可以存储$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执行自动处理，并为未设置$MDNSent关键字或\Draft标志的邮件生成相应的MDN（“已调度”、“已处理”、“已删除”、“已拒绝”或“失败”处置类型，带有“自动操作”和“MDN自动发送”处置模式）。(*)
-- 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的邮件设置$MDNSent关键字，无论是否发送了MDN。
-- 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”或“自动发送MDN”处置模式）。如果使用APPEND命令将生成的MDN保存到邮箱，则客户端必须在APPEND命令中指定$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.
（*）注意：MUA不得使用\Recent标志作为其应发送MDN的指示符，因为根据[IMAP4]，“如果多个连接同时选择了相同的邮箱，则未定义这些连接中的哪些将看到具有\Recent set的新到达邮件，哪些将看到不具有\Recent set的邮件”。因此，使用\Recent作为指示器将导致不同IMAP4服务器的客户端行为不可预测。但是，客户端可以使用\Seen标志作为MDN不能发送的指示符之一。客户端不得使用任何其他标准标志（如\Draft或\responsed）来表示以前发送过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.
当客户端第一次打开邮箱时，它必须通过检查PERMANENTFLAGS响应代码来验证服务器是否支持$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.
当服务器宣布支持存储任意关键字时，客户端必须准备好从服务器接收“否”，因为服务器可能会限制它可以存储在特定邮箱中的邮件关键字的数量。如果客户端无法存储$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。如果消息具有\Draft标志，它也不能发送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
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
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
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
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].
4) 所有客户端和服务器在所有操作中都必须将$MDNSent关键字视为不区分大小写，如[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
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]中指定的增广巴科斯诺尔形式（BNF）表示法，并由[IMAP4]修改。参考但未在下面定义的非端子由[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
flag_keyword ::= "$MDNSent" / other_keywords
other_keywords ::= atom
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.，“用于消息处置通知的可扩展消息格式”，RFC22981998年3月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[ACL]迈尔斯，J.，“IMAP4 ACL扩展”，RFC2086，1997年1月。
Alexey Melnikov ACI Worldwide/MessagingDirect 59 Clarendon Road Watford, Hertfordshire United Kingdom, WD17 1FQ
Alexey Melnikov ACI Worldwide/MessagingDirect英国赫特福德郡克拉伦登路沃特福德59号，WD17 1FQ
Phone: +44 1923 81 2877
EMail: mel@messagingdirect.com
Phone: +44 1923 81 2877
EMail: mel@messagingdirect.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（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编辑功能的资金目前由互联网协会提供。