Network Working Group A. Gulbrandsen
Request for Comments: 5465 Oryx Mail Systems GmbH
Updates: 5267 C. King
Category: Standards Track A. Melnikov
Isode Ltd.
February 2009
Network Working Group A. Gulbrandsen
Request for Comments: 5465 Oryx Mail Systems GmbH
Updates: 5267 C. King
Category: Standards Track A. Melnikov
Isode Ltd.
February 2009
The IMAP NOTIFY Extension
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes.
此文档定义了一个IMAP扩展，该扩展允许客户端为指定邮箱请求特定类型的未经请求的通知，例如向此类邮箱添加或从中删除的邮件。
Table of Contents
目录
1. Overview and Rationale ..........................................3
2. Conventions Used in This Document ...............................4
3. The NOTIFY Extension ............................................4
3.1. The NOTIFY Command .........................................4
4. Interaction with the IDLE Command ...............................8
5. Event Types .....................................................8
5.1. FlagChange and AnnotationChange ............................9
5.2. MessageNew .................................................9
5.3. MessageExpunge ............................................10
5.4. MailboxName ...............................................11
5.5. SubscriptionChange ........................................12
5.6. MailboxMetadataChange .....................................12
5.7. ServerMetadataChange ......................................13
5.8. Notification Overflow .....................................13
5.9. ACL (Access Control List) Changes .........................13
6. Mailbox Specification ..........................................14
6.1. Mailbox Specifiers Affecting the Currently
Selected Mailbox ..........................................14
6.2. Personal ..................................................15
6.3. Inboxes ...................................................15
6.4. Subscribed ................................................15
6.5. Subtree ...................................................15
6.6. Mailboxes .................................................16
7. Extension to SEARCH and SORT Commands ..........................16
8. Formal Syntax ..................................................16
9. Security Considerations ........................................19
10. IANA Considerations ...........................................19
10.1. Initial LIST-EXTENDED Extended Data Item Registrations ...19
11. Acknowledgements ..............................................20
12. Normative References ..........................................20
13. Informative References ........................................21
1. Overview and Rationale ..........................................3
2. Conventions Used in This Document ...............................4
3. The NOTIFY Extension ............................................4
3.1. The NOTIFY Command .........................................4
4. Interaction with the IDLE Command ...............................8
5. Event Types .....................................................8
5.1. FlagChange and AnnotationChange ............................9
5.2. MessageNew .................................................9
5.3. MessageExpunge ............................................10
5.4. MailboxName ...............................................11
5.5. SubscriptionChange ........................................12
5.6. MailboxMetadataChange .....................................12
5.7. ServerMetadataChange ......................................13
5.8. Notification Overflow .....................................13
5.9. ACL (Access Control List) Changes .........................13
6. Mailbox Specification ..........................................14
6.1. Mailbox Specifiers Affecting the Currently
Selected Mailbox ..........................................14
6.2. Personal ..................................................15
6.3. Inboxes ...................................................15
6.4. Subscribed ................................................15
6.5. Subtree ...................................................15
6.6. Mailboxes .................................................16
7. Extension to SEARCH and SORT Commands ..........................16
8. Formal Syntax ..................................................16
9. Security Considerations ........................................19
10. IANA Considerations ...........................................19
10.1. Initial LIST-EXTENDED Extended Data Item Registrations ...19
11. Acknowledgements ..............................................20
12. Normative References ..........................................20
13. Informative References ........................................21
The IDLE command (defined in [RFC2177]) provides a way for the client to go into a mode where the IMAP server pushes it notifications about IMAP mailstore events for the selected mailbox. However, the IDLE extension doesn't restrict or control which server events can be sent, or what information the server sends in response to each event. Also, IDLE only applies to the selected mailbox, thus requiring an additional TCP connection per mailbox.
IDLE命令（在[RFC2177]中定义）为客户端提供了一种进入模式的方法，在该模式下，IMAP服务器向其推送有关所选邮箱的IMAP邮件存储事件的通知。但是，空闲扩展不限制或控制可以发送哪些服务器事件，或者服务器响应每个事件发送什么信息。此外，IDLE仅适用于所选邮箱，因此每个邮箱需要额外的TCP连接。
This document defines an IMAP extension that allows clients to express their preferences about unsolicited events generated by the server. The extension allows clients to only receive events that they are interested in, while servers know that they don't need to go to the effort of generating certain types of untagged responses.
本文档定义了一个IMAP扩展，该扩展允许客户端表达其对服务器生成的未经请求事件的偏好。该扩展只允许客户端接收他们感兴趣的事件，而服务器知道他们不需要生成某些类型的未标记响应。
Without the NOTIFY command defined in this document, an IMAP server will only send information about mailstore changes to the client in the following cases:
如果没有本文档中定义的NOTIFY命令，IMAP服务器将仅在以下情况下向客户端发送有关邮件存储更改的信息：
- as the result of a client command (e.g., FETCH responses to a FETCH or STORE command), - as unsolicited responses sent just before the end of a command (e.g., EXISTS or EXPUNGE) as the result of changes in other sessions, and - during an IDLE command.
- 作为客户端命令的结果（例如，对FETCH或STORE命令的FETCH响应），-作为命令结束前（例如，EXISTS或EXPUNGE）由于其他会话中的更改而发送的非请求响应，以及-在空闲命令期间。
The NOTIFY command extends what information may be returned in those last two cases, and also permits and requires the server to send information about updates between commands. The NOTIFY command also allows for the client to extend what information is sent unsolicited about the selected mailbox and to request some update information to be sent regarding other mailboxes.
NOTIFY命令扩展了最后两种情况下可能返回的信息，还允许并要求服务器在命令之间发送有关更新的信息。NOTIFY命令还允许客户端扩展未经请求发送的有关所选邮箱的信息，并请求发送有关其他邮箱的一些更新信息。
The interaction between IDLE and NOTIFY commands is described in Section 4.
IDLE和NOTIFY命令之间的交互在第4节中描述。
For the new messages delivered to or appended to the selected mailbox, the NOTIFY command can be used to request that a set of attributes be sent to the client in an unsolicited FETCH response. This allows a client to be a passive recipient of events and new mail and to be able to maintain full synchronisation without having to issue any subsequent commands except to modify the state of the mailbox on the server.
对于发送到所选邮箱或附加到所选邮箱的新邮件，可以使用NOTIFY命令请求在未经请求的获取响应中将一组属性发送到客户端。这允许客户端成为事件和新邮件的被动接收者，并且能够保持完全同步，而无需发出任何后续命令（修改服务器上邮箱的状态除外）。
Some mobile clients, however, may want mail "pushed" only for mail that matches a SEARCH pattern. To meet that need, [RFC5267] is augmented by this document to extend the UPDATE return option to specify a list of fetch-atts to be returned when a new message is delivered or appended in another session.
然而，一些移动客户端可能只希望对匹配搜索模式的邮件“推送”。为了满足这一需求，本文档对[RFC5267]进行了扩展，以扩展更新返回选项，以指定在另一个会话中传递或追加新消息时要返回的获取ATT列表。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The acronym MSN stands for Message Sequence Numbers (see Section 2.3.1.2 of [RFC3501]).
首字母缩略词MSN代表消息序列号（见[RFC3501]第2.3.1.2节）。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:", by the server. "[...]" means elision.
以“C:”开头的示例行由客户端发送，以“S:”开头的示例行由服务器发送。“[……]”是指省略。
IMAP servers that support this extension advertise the NOTIFY capability. This extension adds the NOTIFY command as defined in Section 5.1.
支持此扩展的IMAP服务器宣传NOTIFY功能。此扩展添加了第5.1节中定义的NOTIFY命令。
A server implementing this extension is not required to implement LIST-EXTENDED [RFC5258], even though a NOTIFY-compliant server must be able to return extended LIST responses, defined in [RFC5258].
实现此扩展的服务器不需要实现列表扩展[RFC5258]，即使符合NOTIFY的服务器必须能够返回[RFC5258]中定义的扩展列表响应。
Arguments: "SET" Optional STATUS indicator Mailboxes to be watched Events about which to notify the client
参数：“设置”可选状态指示器要监视的邮箱要通知客户端的事件
Or Arguments: "NONE"
或论点：“无”
Responses: Possibly untagged STATUS responses (for SET)
响应：可能未标记的状态响应（对于集合）
Result: OK - The server will notify the client as requested. NO - Unsupported NOTIFY event, NOTIFY too complex or expensive, etc. BAD - Command unknown, invalid, unsupported, or has unknown arguments.
结果：确定-服务器将根据请求通知客户端。否-不支持的NOTIFY事件、NOTIFY过于复杂或昂贵等。错误-命令未知、无效、不支持或具有未知参数。
The NOTIFY command informs the server that the client listens for event notifications all the time (even when no command is in progress), and requests the server to notify it about the specified set of events. The NOTIFY command has two forms. NOTIFY NONE specifies that the client is not interested in any kind of event happening on the server. NOTIFY SET replaces the current list of interesting events with a new list of events.
NOTIFY命令通知服务器客户端一直在侦听事件通知（即使没有命令在执行），并请求服务器通知指定的事件集。NOTIFY命令有两种形式。NOTIFY NONE指定客户端对服务器上发生的任何类型的事件不感兴趣。NOTIFY SET将当前的感兴趣事件列表替换为新的事件列表。
Until the NOTIFY command is used for the first time, the server only sends notifications while a command is being processed, and notifies the client about these events on the selected mailbox (see Section 5 for definitions): MessageNew, MessageExpunge, or FlagChange. It does not notify the client about any events on other mailboxes.
在首次使用NOTIFY命令之前，服务器仅在处理命令时发送通知，并将所选邮箱上的这些事件通知客户端（有关定义，请参阅第5节）：MessageNew、MessageExpunge或FlagChange。它不会将其他邮箱上的任何事件通知客户端。
The effect of a successful NOTIFY command lasts until the next NOTIFY command or until the IMAP connection is closed.
成功的NOTIFY命令的效果将持续到下一个NOTIFY命令或IMAP连接关闭为止。
A successful NOTIFY SET command MUST cause the server to immediately return any accumulated changes to the currently selected mailbox (if any), such as flag changes and new or expunged messages. Thus, a successful NOTIFY SET command implies an implicit NOOP command.
成功的NOTIFY SET命令必须使服务器立即将任何累积的更改返回到当前选定的邮箱（如果有），例如标志更改和新邮件或已删除邮件。因此，成功的NOTIFY SET命令意味着隐式的NOOP命令。
The NOTIFY SET command can request notifications of message-related changes to the selected mailbox, whatever that may be at the time the message notifications are being generated. This is done by specifying either the SELECTED or the SELECTED-DELAYED mailbox selector (see Section 6.1) in the NOTIFY SET command. If the SELECTED/SELECTED-DELAYED mailbox selector is not specified in the NOTIFY SET command, this means that the client doesn't want to receive any <message-event>s for the currently selected mailbox. This is the same as specifying SELECTED NONE.
NOTIFY SET命令可以请求对所选邮箱进行与邮件相关的更改通知，无论在生成邮件通知时发生了什么。通过在NOTIFY SET命令中指定SELECTED或SELECTED-DELATED邮箱选择器（请参见第6.1节）来完成此操作。如果在NOTIFY SET命令中未指定SELECTED/SELECTED-DELAYED邮箱选择器，这意味着客户端不希望接收当前所选邮箱的任何<message event>s。这与指定所选“无”相同。
The client can also request notifications on other mailboxes by name or by a limited mailbox pattern match. Message-related notifications returned for the currently selected mailbox will be those specified by the SELECTED/SELECTED-DELAYED mailbox specifier, even if the selected mailbox also appears by name (or matches a pattern) in the command. Non-message-related notifications are controlled by mailbox specifiers other than SELECTED/SELECTED-DELAYED.
客户端还可以通过名称或有限邮箱模式匹配请求其他邮箱上的通知。为当前选定邮箱返回的与邮件相关的通知将是由selected/selected-DELAYED邮箱说明符指定的通知，即使所选邮箱也按名称（或与模式匹配）显示在命令中。与邮件无关的通知由邮箱说明符控制，而不是由SELECTED/SELECTED-DELAYED控制。
If the NOTIFY command enables MessageNew, MessageExpunge, AnnotationChange, or FlagChange notifications for a mailbox other than the currently selected mailbox, and the client has specified the STATUS indicator parameter, then the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT, and UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST contain MESSAGES. If either AnnotationChange or FlagChange are
如果NOTIFY命令为当前选定邮箱以外的邮箱启用MessageNew、MessageExpunge、AnnotationChange或FlagChange通知，并且客户端已指定状态指示器参数，则服务器必须在NOTIFY标记为OK之前发送该邮箱的状态响应。如果启用了MessageNew，则状态响应必须包含消息、UIDNEXT和UIDValicity。如果启用了MessageExpunge，则状态响应必须包含消息。如果选择AnnotationChange或FlagChange
included and the server also supports the CONDSTORE [RFC4551] and/or QRESYNC [RFC5162] extensions, the STATUS response MUST contain UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows the client to avoid the additional STATUS responses. This might be useful if the client already retrieved this information before issuing the NOTIFY command.
包括并且服务器还支持CONDSTORE[RFC4551]和/或QRESYNC[RFC5162]扩展，状态响应必须包含UIDValicity和HIGHESTMODSEQ。缺少STATUS indicator参数允许客户端避免额外的状态响应。如果客户机在发出NOTIFY命令之前已检索到此信息，则这可能很有用。
Clients are advised to limit the number of mailboxes used with NOTIFY. Particularly, if a client asks for events for all accessible mailboxes, the server may swamp the client with updates about shared mailboxes. This may reduce the client's battery life. Also, this wastes both server and network resources.
建议客户端限制与NOTIFY一起使用的邮箱数。特别是，如果客户端请求所有可访问邮箱的事件，服务器可能会用有关共享邮箱的更新淹没客户端。这可能会缩短客户端的电池寿命。而且，这会浪费服务器和网络资源。
For each mailbox specified, the server verifies that the client has access using the following test:
对于指定的每个邮箱，服务器使用以下测试验证客户端是否具有访问权限：
- If the name does not refer to an existing mailbox, the server MUST ignore it.
- 如果该名称未引用现有邮箱，则服务器必须忽略它。
- If the name refers to a mailbox that the client can't LIST, the server MUST ignore it. For a server that implements [RFC4314], this means that if the client doesn't have the 'l' (lookup) right for the name, then the server MUST ignore the mailbox. This behavior prevents disclosure of potentially confidential information to clients who don't have rights to know it.
- 如果该名称引用了客户端无法列出的邮箱，则服务器必须忽略它。对于实现[RFC4314]的服务器，这意味着如果客户端没有名称的“l”（查找）权限，则服务器必须忽略邮箱。这种行为防止向无权知晓的客户披露潜在的机密信息。
- If the name refers to a mailbox that the client can LIST (e.g., it has the 'l' right from [RFC4314]), but the client doesn't have another right required for processing of the specified event(s), then the server MUST respond with an untagged extended LIST response containing the \NoAccess name attribute.
- 如果名称引用客户端可以列出的邮箱（例如，它具有[RFC4314]中的“l”权限），但客户端没有处理指定事件所需的其他权限，则服务器必须使用包含\n访问名属性的未标记扩展列表响应响应。
The server SHOULD return the tagged OK response if the client has access to at least one of the mailboxes specified in the current list of interesting events. The server MAY return the tagged NO response if the client has no access to any of the specified mailboxes and no access can ever be granted in the future (e.g., the client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist, and LIST returns \Noinferiors for the parent 'Bar').
如果客户端可以访问当前感兴趣事件列表中指定的至少一个邮箱，则服务器应返回带标记的OK响应。如果客户端无法访问任何指定邮箱，并且将来无法授予任何访问权限（例如，客户端为“Subtree Bar/Foo”指定的事件、“Bar/Foo”不存在，并且列表返回父“Bar”的\n周期），则服务器可能会返回标记的“NO”响应。
If the notification would be prohibitively expensive for the server (e.g., "notify me of all flag changes in all mailboxes"), the server MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] response.
如果通知对服务器来说代价过高（例如，“通知我所有邮箱中的所有标志更改”），服务器可能会拒绝带有标记的NO[NOTIFICATIONOVERFLOW]响应的命令。
If the client requests information for events of an unsupported type, the server MUST refuse the command with a tagged NO response (not a BAD). This response SHOULD contain the BADEVENT response code, which MUST list names of all events supported by the server.
如果客户端请求不受支持类型的事件的信息，服务器必须拒绝带有标记的“无响应”（不是坏响应）的命令。此响应应包含BADEVENT响应代码，该代码必须列出服务器支持的所有事件的名称。
Here's an example:
下面是一个例子：
S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
C: a login bob alice
S: a OK Password matched
C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
500)
S: [...]
S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S: b OK done
C: c select inbox
S: [...] (the usual 7-8 responses to SELECT)
S: c OK INBOX selected
(Time passes. A new message is delivered to mailbox
Lists/Lemonade.)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000
MESSAGES 501)
(Time passes. A new message is delivered to inbox.)
S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To
Subject)] {75}
S: Subject: Re: good morning
S: From: alice@example.org
S: To: bob@example.org
S:
S: )
(Time passes. The client decides it wants to know about
one more mailbox. As the client already knows necessary
STATUS information for all mailboxes below the Lists
mailbox, and because "notify set status" would cause
STATUS responses for *all* mailboxes specified in the
NOTIFY command, including the ones for which the client
already knows STATUS information, the client issues an
explicit STATUS request for the mailbox to be added to
the watch list, followed by the NOTIFY SET without the
STATUS parameter.)
C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
S: d STATUS completed
S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
C: a login bob alice
S: a OK Password matched
C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
500)
S: [...]
S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S: b OK done
C: c select inbox
S: [...] (the usual 7-8 responses to SELECT)
S: c OK INBOX selected
(Time passes. A new message is delivered to mailbox
Lists/Lemonade.)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000
MESSAGES 501)
(Time passes. A new message is delivered to inbox.)
S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To
Subject)] {75}
S: Subject: Re: good morning
S: From: alice@example.org
S: To: bob@example.org
S:
S: )
(Time passes. The client decides it wants to know about
one more mailbox. As the client already knows necessary
STATUS information for all mailboxes below the Lists
mailbox, and because "notify set status" would cause
STATUS responses for *all* mailboxes specified in the
NOTIFY command, including the ones for which the client
already knows STATUS information, the client issues an
explicit STATUS request for the mailbox to be added to
the watch list, followed by the NOTIFY SET without the
STATUS parameter.)
C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
S: d STATUS completed
C: e notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew)
S: e OK done
C: e notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew)
S: e OK done
If IDLE [RFC2177] (as well as this extension) is supported, then while processing any IDLE command, the server MUST send exactly the same events as instructed by the client using the NOTIFY command.
如果支持IDLE[RFC2177]（以及此扩展名），则在处理任何IDLE命令时，服务器必须发送与客户端使用NOTIFY命令指示完全相同的事件。
NOTIFY makes IDLE unnecessary for some clients. If a client does not use MSNs and '*' in commands, it can request MessageExpunge and MessageNew for the selected mailbox by using the NOTIFY command instead of entering the IDLE mode.
NOTIFY使某些客户端不需要空闲。如果客户端未在命令中使用MSNs和“*”，则可以使用NOTIFY命令而不是进入空闲模式，为所选邮箱请求MessageExpunge和MessageNew。
A client that uses MSNs and '*' in commands can still use the NOTIFY command if it specifies the SELECTED-DELAYED mailbox specifier in the NOTIFY command.
如果在NOTIFY命令中指定了选定的延迟邮箱说明符，则在命令中使用MSNs和“*”的客户端仍可使用NOTIFY命令。
Only some of the events in [RFC5423] can be expressed in IMAP, and for some of them there are several possible ways to express the event.
只有[RFC5423]中的一些事件可以用IMAP表示，对于其中一些事件，有几种可能的方式来表示事件。
This section specifies the events of which an IMAP server can notify an IMAP client, and how.
本节指定IMAP服务器可以通知IMAP客户端的事件以及通知方式。
The server SHOULD omit notifying the client if the event is caused by this client. For example, if the client issues CREATE and has requested a MailboxName event that would cover the newly created mailbox, the server SHOULD NOT notify the client of the MailboxName change.
如果事件是由该客户端引起的，服务器应该忽略通知客户端。例如，如果客户端发出CREATE并请求了将覆盖新创建邮箱的MailboxName事件，则服务器不应将MailboxName更改通知客户端。
All event types described in this document require the 'l' and 'r' rights (see [RFC4314]) on all observed mailboxes. Servers that don't implement [RFC4314] should map the above rights to their access-control model.
本文档中描述的所有事件类型都要求对所有观察到的邮箱具有“l”和“r”权限（请参见[RFC4314]）。未实现[RFC4314]的服务器应将上述权限映射到其访问控制模型。
If the FlagChange and/or AnnotationChange events are specified, MessageNew and MessageExpunge MUST also be specified by the client. Otherwise, the server MUST respond with the tagged BAD response.
如果指定了FlagChange和/或AnnotationChange事件，则客户端还必须指定MessageNew和MessageExpunge。否则，服务器必须使用标记的错误响应进行响应。
If one of MessageNew or MessageExpunge is specified, then both events MUST be specified. Otherwise, the server MUST respond with the tagged BAD response.
如果指定了MessageNew或MessageExpunge中的一个，则必须同时指定这两个事件。否则，服务器必须使用标记的错误响应进行响应。
The client can instruct the server not to send an event by omitting the necessary event from the list of events specified in NOTIFY SET, by using the NONE event specifier in the NOTIFY SET, or by using NOTIFY NONE. In particular, NOTIFY SET ... NONE can be used as a snapshot facility by clients.
客户端可以通过从NOTIFY集中指定的事件列表中省略必要的事件、使用NOTIFY集中的NONE事件说明符或使用NOTIFY NONE来指示服务器不发送事件。特别是，通知集。。。没有一个可用作客户端的快照功能。
If the flag and/or message annotation change happens in the selected mailbox, the server MUST notify the client by sending an unsolicited FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses.
如果所选邮箱中发生标志和/或消息批注更改，服务器必须通过发送未经请求的获取响应通知客户端，该响应必须包括UID和标志/批注获取数据项。它还可能发送新标志和/或OK[PERMANENTFLAGS…]响应。
If a search context is in effect as specified in [RFC5267], an ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if appropriate. In this case, the FETCH response MUST precede the ESEARCH response.
如果搜索上下文按照[RFC5267]中的规定生效，则还将生成一个ESEARCH ADDTO或ESEARCH REMOVEFROM（如果适用）。在这种情况下，FETCH响应必须在ESEARCH响应之前。
If the change happens in another mailbox, then the server responds with a STATUS response. The exact content of the STATUS response depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC [RFC5162] are enabled by the client, then the server sends a STATUS response that includes at least HIGHESTMODSEQ and UIDVALIDITY status data items. If the number of messages with the \Seen flag changes, the server MAY also include the UNSEEN data item in the STATUS response. If CONDSTORE/QRESYNC is not enabled by the client and the server chooses not to include the UNSEEN data item, the server does not notify the client. When this event is requested, the server MUST notify the client about mailbox UIDVALIDITY changes. This is done by sending a STATUS response that includes UIDVALIDITY.
如果更改发生在另一个邮箱中，则服务器将以状态响应进行响应。状态响应的确切内容取决于各种因素。如果客户机启用了CONDSTORE[RFC4551]和/或QRESYNC[RFC5162]，则服务器将发送至少包含HIGHESTMODSEQ和UIDValicity状态数据项的状态响应。如果带有\Seen标志的消息数量发生变化，服务器还可能在状态响应中包含未看到的数据项。如果客户端未启用CONDSTORE/QRESYNC，并且服务器选择不包含未看到的数据项，则服务器不会通知客户端。请求此事件时，服务器必须将邮箱UIDVality更改通知客户端。这是通过发送包含UIDVality的状态响应来完成的。
FlagChange covers the MessageRead, MessageTrash, FlagsSet, and FlagsClear events in [RFC5423].
FlagChange包括[RFC5423]中的MessageRead、MessageTrash、FlagsSet和FlagsClear事件。
Example in the selected mailbox: S: * 99 FETCH (UID 9999 FLAGS ($Junk))
所选邮箱中的示例：S:*99 FETCH（UID 9999标志（$Junk））
And in another mailbox, with CONDSTORE in use: S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY 101)
在另一个使用CONDSTORE的邮箱中：S:*状态列表/柠檬水（HIGHESTMODSEQ 65666665 UIDVality 101）
This covers both MessageNew and MessageAppend in [RFC5423].
这包括[RFC5423]中的MessageNew和MessageAppend。
If the new/appended message is in the selected mailbox, the server notifies the client by sending an unsolicited EXISTS response, followed by an unsolicited FETCH response containing the information requested by the client. A FETCH response SHOULD NOT be generated for a new message created by the client on this particular connection, for instance, as the result of an APPEND or COPY command to the selected mailbox performed by the client itself. The server MAY also send a RECENT response, if the server marks the message as \Recent.
如果新邮件/附加邮件位于所选邮箱中，服务器将通过发送未经请求的EXISTS响应通知客户端，然后发送包含客户端请求的信息的未经请求的FETCH响应。不应为客户端在此特定连接上创建的新邮件生成获取响应，例如，由于客户端本身对所选邮箱执行了APPEND或COPY命令。如果服务器将邮件标记为\RECENT，则服务器也可以发送最近的响应。
Note that a single EXISTS response can be returned for multiple MessageAppend/MessageNew events.
注意，对于多个MessageAppend/MessageNew事件，可以返回单个EXISTS响应。
If a search context is in effect as specified in [RFC5267], an ESEARCH ADDTO will also be generated, if appropriate. In this case, the EXISTS response MUST precede the ESEARCH response. Both the NOTIFY command and the SEARCH and SORT commands (see Section 7) can specify attributes to be returned for new messages. These attributes SHOULD be combined into a single FETCH response. The server SHOULD avoid sending duplicate data. The FETCH response(s) MUST follow any ESEARCH ADDTO responses.
如果搜索上下文按照[RFC5267]中的规定生效，则还将生成一个ESEARCH ADDTO（如果适用）。在这种情况下，EXISTS响应必须在ESEARCH响应之前。NOTIFY命令和SEARCH和SORT命令（参见第7节）都可以指定要为新消息返回的属性。这些属性应组合到单个提取响应中。服务器应避免发送重复数据。获取响应必须在任何ESEARCH ADDTO响应之后。
If the new/appended message is in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC extension [RFC5162] is enabled, the HIGHESTMODSEQ status data item MUST be included in the STATUS response.
如果新邮件/附加邮件位于其他邮箱中，则服务器会为相关邮箱发送未经请求的状态（UIDNEXT MESSAGES）响应。如果CONDSTORE扩展[RFC4551]和/或QRESYNC扩展[RFC5162]已启用，则状态响应中必须包含最高位ModSeq状态数据项。
The client SHOULD NOT use FETCH attributes that implicitly set the \seen flag, or that presuppose the existence of a given bodypart. UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and BODY/BODYSTRUCTURE may be the most useful attributes.
客户端不应使用隐式设置\seen标志或假定存在给定bodypart的获取属性。UID、MODSEQ、FLAGS、ENVELOPE、BODY.PEEK[标题.字段…和BODY/BODYSTRUCTURE可能是最有用的属性。
Note that if a client asks to be notified of MessageNew events with the SELECTED mailbox specifier, the number of messages can increase at any time, and therefore the client cannot refer to a specific message using the MSN/UID '*'.
请注意，如果客户端要求使用所选邮箱说明符通知MessageNew事件，则消息的数量随时会增加，因此客户端无法使用MSN/UID“*”引用特定消息。
Example in the selected mailbox:
S: * 444 EXISTS
S: * 444 FETCH (UID 9999)
Example in the selected mailbox:
S: * 444 EXISTS
S: * 444 FETCH (UID 9999)
And in another mailbox, without CONDSTORE enabled:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
And in another mailbox, without CONDSTORE enabled:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
If the expunged message or messages are in the selected mailbox, the server notifies the client using EXPUNGE (or VANISHED, if [RFC5162] is supported by the server and enabled by the client).
如果已删除的一封或多封邮件位于所选邮箱中，服务器将使用EXPUNGE通知客户端（如果服务器支持并由客户端启用[RFC5162]，则通知已消失）。
If a search context is in effect, as specified in [RFC5267], an ESEARCH REMOVEFROM will also be generated, if appropriate.
如果搜索上下文有效，如[RFC5267]中所述，如果合适，还将生成ESEARCH REMOVEFROM。
If the expunged message or messages are in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If the QRESYNC [RFC5162] extension is enabled, the HIGHESTMODSEQ data item MUST be included in the STATUS response as well.
如果已删除的一封或多封邮件位于另一个邮箱中，则服务器会为相关邮箱发送未经请求的状态（UIDNEXT messages）响应。如果启用了QRESYNC[RFC5162]扩展，则状态响应中还必须包含最高位ModSeq数据项。
Note that if a client requests MessageExpunge with the SELECTED mailbox specifier, the meaning of an MSN can change at any time, so the client cannot use MSNs in commands anymore. For example, such a client cannot use FETCH, but has to use UID FETCH. The meaning of '*' can also change when messages are added or expunged. A client wishing to keep using MSNs can either use the SELECTED-DELAYED mailbox specifier or can avoid using the MessageExpunge event entirely.
请注意，如果客户端使用选定的邮箱说明符请求MessageExpunge，则MSN的含义随时可能更改，因此客户端无法在命令中使用MSN。例如，这样的客户端不能使用FETCH，但必须使用UID FETCH。添加或删除消息时，“*”的含义也会发生变化。希望继续使用MSN的客户端可以使用选定的延迟邮箱说明符，也可以完全避免使用MessageExpunge事件。
The MessageExpunge notification covers both MessageExpunge and MessageExpire events from [RFC5423].
MessageExpunge通知涵盖[RFC5423]中的MessageExpunge和MessageExpire事件。
Example in the selected mailbox, without QRESYNC: S: * 444 EXPUNGE
所选邮箱中的示例，不带QRESYNC:S:*444删除
The same example in the selected mailbox, with QRESYNC: S: * VANISHED 5444
所选邮箱中的示例与QRESYNC:S:*5444相同
And in another mailbox, when QRESYNC is not enabled: S: * STATUS misc (UIDNEXT 999 MESSAGES 554)
在另一个邮箱中，当QRESYNC未启用时：S:*状态杂项（UIDNEXT 999 MESSAGES 554）
These notifications are sent if an affected mailbox name was created (with CREATE), deleted (with DELETE), or renamed (with RENAME). For a server that implements [RFC4314], granting or revocation of the 'l' right to the current user on the affected mailbox MUST be considered mailbox creation or deletion, respectively. If a mailbox is created or deleted, the mailbox itself and its direct parent (whether it is an existing mailbox or not) are considered to be affected.
如果创建（使用创建）、删除（使用删除）或重命名（使用重命名）受影响的邮箱名称，则会发送这些通知。对于实现[RFC4314]的服务器，向受影响邮箱上的当前用户授予或撤销“l”权限必须分别视为邮箱创建或删除。如果创建或删除邮箱，则认为邮箱本身及其直接父级（无论是否为现有邮箱）受到影响。
The server notifies the client by sending an unsolicited LIST response for each affected mailbox name. If, after the event, the mailbox name does not refer to a mailbox accessible to the client, the \Nonexistent flag MUST be included.
服务器通过为每个受影响的邮箱名称发送未经请求的列表响应来通知客户端。如果事件发生后，邮箱名称未引用客户端可访问的邮箱，则必须包含\Nonexistent标志。
For each LISTable mailbox renamed, the server sends an extended LIST response [RFC5258] for the new mailbox name, containing the OLDNAME extended data item with the old mailbox name. When a mailbox is renamed, its children are renamed too. No additional MailboxName events are sent for children in this case. When INBOX is renamed, a new INBOX is assumed to be created. No MailboxName event is sent for INBOX in this case.
对于重命名的每个可列出的邮箱，服务器将为新邮箱名称发送扩展列表响应[RFC5258]，其中包含具有旧邮箱名称的OLDNAME扩展数据项。重命名邮箱时，其子邮箱也将重命名。在这种情况下，不会为子级发送其他MailboxName事件。重命名收件箱时，假定将创建一个新的收件箱。在这种情况下，不会为收件箱发送MailboxName事件。
If the server automatically subscribes a mailbox when it is created or renamed, then the unsolicited LIST response for each affected subscribed mailbox name MUST include the \Subscribed attribute (see [RFC5258]). The server SHOULD also include \HasChildren or \HasNoChildren attributes [RFC5258] as appropriate.
如果服务器在创建或重命名邮箱时自动订阅邮箱，则每个受影响的订阅邮箱名称的非请求列表响应必须包含\subscribed属性（请参见[RFC5258]）。服务器还应酌情包括\HasChildren或\HasNoChildren属性[RFC5258]。
Example of a newly created mailbox (or granting of the 'l' right on the mailbox): S: * LIST () "/" "NewMailbox"
新创建的邮箱示例（或授予邮箱上的“l”权限）：S:*LIST（）“/”NewMailbox
And a deleted mailbox (or revocation of the 'l' right on the mailbox): S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
和已删除的邮箱（或撤销邮箱上的“l”权限）：S:*列表（\n不存在）”。“INBOX.DeletedMailbox”
Example of a renamed mailbox:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
Example of a renamed mailbox:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
The server notifies the client by sending an unsolicited LIST response for each affected mailbox name. If and only if the mailbox is subscribed after the event, the \Subscribed attribute (see [RFC5258]) is included. Note that in the LIST response, all mailbox attributes MUST be accurately computed (this differs from the behavior of the LSUB command).
服务器通过为每个受影响的邮箱名称发送未经请求的列表响应来通知客户端。如果且仅当邮箱在事件后订阅，则包含\subscribed属性（请参见[RFC5258]）。请注意，在列表响应中，必须准确计算所有邮箱属性（这与LSUB命令的行为不同）。
Example:
S: * LIST (\Subscribed) "/" "SubscribedMailbox"
Example:
S: * LIST (\Subscribed) "/" "SubscribedMailbox"
Support for this event type is OPTIONAL unless the METADATA extension [RFC5464] is also supported by the server, in which case support for this event type is REQUIRED.
对此事件类型的支持是可选的，除非服务器也支持元数据扩展[RFC5464]，在这种情况下，需要对此事件类型的支持。
A client willing to receive unsolicited METADATA responses as a result of using the MailboxMetadataChange event in the NOTIFY command doesn't have to issue ENABLE METADATA.
由于在NOTIFY命令中使用MailboxMetadataChange事件而希望接收未经请求的元数据响应的客户端不必发出ENABLE METADATA。
The server sends an unsolicited METADATA response (as per Section 4.4.2 of [RFC5464]). If possible, only the changed metadata SHOULD be included, but if the server can't detect a change to a single metadata item, it MAY include all metadata items set on the mailbox. If a metadata item is deleted (set to NIL), it MUST always be included in the METADATA response.
服务器发送未经请求的元数据响应（根据[RFC5464]第4.4.2节）。如果可能，只应包括更改的元数据，但如果服务器无法检测到单个元数据项的更改，则可能包括邮箱上设置的所有元数据项。如果元数据项被删除（设置为NIL），则它必须始终包含在元数据响应中。
Example:
S: * METADATA "INBOX" /shared/comment
Example:
S: * METADATA "INBOX" /shared/comment
Support for this event type is OPTIONAL unless the METADATA or the METADATA-SERVER extension [RFC5464] is also supported by the server, in which case support for this event type is REQUIRED.
对此事件类型的支持是可选的，除非服务器也支持元数据或元数据服务器扩展[RFC5464]，在这种情况下，需要对此事件类型的支持。
A client willing to receive unsolicited METADATA responses as a result of using the ServerMetadataChange event in the NOTIFY command doesn't have to issue ENABLE METADATA or ENABLE METADATA-SERVER.
由于在NOTIFY命令中使用ServerMetadataChange事件而希望接收未经请求的元数据响应的客户端不必发出ENABLE METADATA或ENABLE METADATA-SERVER。
The server sends an unsolicited METADATA response (as per Section 4.4.2 of [RFC5464]). Only the names of changed metadata entries SHOULD be returned in such METADATA responses. If a metadata item is deleted (set to NIL), it MUST always be included in the METADATA response.
服务器发送未经请求的元数据响应（根据[RFC5464]第4.4.2节）。此类元数据响应中只应返回已更改元数据项的名称。如果元数据项被删除（设置为NIL），则它必须始终包含在元数据响应中。
Example:
S: * METADATA "" /shared/comment
Example:
S: * METADATA "" /shared/comment
If the server is unable or unwilling to deliver as many notifications as it is being asked to, it may disable notifications for some or all clients. It MUST notify these clients by sending an untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE command had just been received.
如果服务器无法或不愿意发送请求发送的通知数量，则可能会禁用部分或所有客户端的通知。它必须通过发送一个未标记的“OK[NOTIFICATIONOVERFLOW]”响应来通知这些客户机，其行为就像刚刚收到notify NONE命令一样。
Example: S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...
示例：S:*确定[NOTIFICATIONOVERFLOW]…可以在此处添加注释。。。
Even if NOTIFY succeeds, it is still possible to lose access to the mailboxes being monitored at a later time. If this happens, the server MUST stop monitoring these mailboxes. If access is later granted, the server MUST restart event monitoring.
即使NOTIFY成功，以后仍有可能失去对正在监视的邮箱的访问。如果发生这种情况，服务器必须停止监视这些邮箱。如果以后授予访问权限，服务器必须重新启动事件监视。
The server SHOULD return the LIST response with the \NoAccess name attribute if and when the mailbox loses the 'l' right. Similarly, the server SHOULD return the LIST response with no \NoAccess name attribute if the mailbox was previously reported as having \NoAccess and the 'l' right is later granted.
如果邮箱失去“l”权限，服务器应返回带有\n访问名属性的列表响应。类似地，如果邮箱先前报告为具有\n访问权限，并且稍后授予了“l”权限，则服务器应返回具有\n无访问权限名称属性的列表响应。
Mailboxes to be monitored can be specified in several different ways.
可以通过几种不同的方式指定要监视的邮箱。
Only 'SELECTED' and 'SELECTED-DELAYED' (Section 6.1) match the currently selected mailbox. All other mailbox specifications affect other (non-selected) mailboxes.
只有“选定”和“选定-延迟”（第6.1节）与当前选定的邮箱匹配。所有其他邮箱规范都会影响其他（未选定）邮箱。
Note that multiple <event-group>s can apply to the same mailbox. The following example demonstrates this. In this example, MessageNew and MessageExpunge events are reported for INBOX, due to the first <event-group>. A SubscriptionChange event will also be reported for INBOX, due to the second <event-group>.
请注意，多个<event group>s可应用于同一邮箱。下面的示例演示了这一点。在本例中，由于第一个<event group>，会为收件箱报告MessageNew和MessageExpunge事件。由于第二个<event group>，收件箱也将报告SubscriptionChange事件。
C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) (personal (SubscriptionChange))
C：通知集（邮箱收件箱（Messagenew messageExpunge））（个人（SubscriptionChange））
A typical client that supports the NOTIFY extension would ask for events on the selected mailbox and some named mailboxes.
支持NOTIFY扩展的典型客户端将请求所选邮箱和某些命名邮箱上的事件。
In the next example, the client asks for FlagChange events for all personal mailboxes except the currently selected mailbox. This is different from the previous example because SELECTED overrides all other message event definitions for the currently selected mailbox (see Section 3.1).
在下一个示例中，客户端要求为除当前选定邮箱之外的所有个人邮箱提供FlagChange事件。这与前面的示例不同，因为选定的将覆盖当前选定邮箱的所有其他邮件事件定义（请参见第3.1节）。
C: a notify set (selected (Messagenew (uid flags) messageExpunge)) (personal (MessageNew FlagChange MessageExpunge))
C：通知集（选中（Messagenew（uid标志）messageExpunge））（个人（Messagenew标志更改messageExpunge））
Only one of the mailbox specifiers affecting the currently selected mailbox can be specified in any NOTIFY command. The two such mailbox specifiers (SELECTED and SELECTED-DELAYED) are described below.
在任何NOTIFY命令中，只能指定一个影响当前选定邮箱的邮箱说明符。下面介绍这两个邮箱说明符（SELECTED和SELECTED-DELAYED）。
Both refer to the mailbox that was selected using either SELECT or EXAMINE (see [RFC3501], Sections 6.3.1 and 6.3.2). When the IMAP connection is not in the selected state, such mailbox specifiers don't refer to any mailbox.
两者均指使用SELECT或EXAMINE选择的邮箱（参见[RFC3501]，第6.3.1和6.3.2节）。当IMAP连接未处于选定状态时，此类邮箱说明符不会引用任何邮箱。
The mailbox specifiers only apply to <message-event>s. It is an error to specify other types of events with either the SELECTED or the SELECTED-DELAYED selector.
邮箱说明符仅适用于<message event>s。使用SELECTED或SELECTED-DELAYED选择器指定其他类型的事件是错误的。
The SELECTED mailbox specifier requires the server to send immediate notifications for the currently selected mailbox about all specified <message-event>s.
所选邮箱说明符要求服务器立即为当前所选邮箱发送有关所有指定<message event>s的通知。
The SELECTED-DELAYED mailbox specifier requires the server to delay a MessageExpunge event until the client issues a command that allows returning information about expunged messages (see Section 7.4.1 of [RFC3501] for more details), for example, till a NOOP or an IDLE command has been issued. When SELECTED-DELAYED is specified, the server MAY also delay returning other <message-event>s until the client issues one of the commands specified above, or it MAY return them immediately.
SELECTED-DELAYED mailbox说明符要求服务器延迟MessageExpunge事件，直到客户端发出允许返回已删除邮件信息的命令为止（有关更多详细信息，请参阅[RFC3501]第7.4.1节），例如，直到发出NOOP或IDLE命令为止。当指定SELECTED-DELAYED时，服务器也可以延迟返回其他<message event>s，直到客户机发出上面指定的命令之一，或者可以立即返回它们。
Personal refers to all selectable mailboxes in the user's personal namespace(s), as defined in [RFC2342].
Personal是指[RFC2342]中定义的用户个人命名空间中的所有可选邮箱。
Inboxes refers to all selectable mailboxes in the user's personal namespace(s) to which messages may be delivered by a Message Delivery Agent (MDA) (see [EMAIL-ARCH], particularly Section 4.3.3).
收件箱是指用户个人名称空间中的所有可选邮箱，消息可通过消息传递代理（MDA）传递到这些邮箱（请参见[EMAIL-ARCH]，特别是第4.3.3节）。
If the IMAP server cannot easily compute this set, it MUST treat "inboxes" as equivalent to "personal".
如果IMAP服务器无法轻松计算此集合，则必须将“收件箱”视为等同于“个人”。
Subscribed refers to all mailboxes subscribed to by the user.
Subscribed是指用户订阅的所有邮箱。
If the subscription list changes, the server MUST reevaluate the list.
如果订阅列表发生更改，服务器必须重新评估该列表。
Subtree is followed by a mailbox name or list of mailbox names. A subtree refers to all selectable mailboxes that are subordinate to the specified mailbox plus the specified mailbox itself.
子树后面是邮箱名称或邮箱名称列表。子树是指从属于指定邮箱和指定邮箱本身的所有可选邮箱。
Mailboxes is followed by a mailbox name or a list of mailbox names. The server MUST NOT do a wildcard expansion. This means there is no special treatment for the LIST wildcard characters ('*' and '%') if they are present in mailbox names.
邮箱后面是邮箱名称或邮箱名称列表。服务器不能进行通配符扩展。这意味着，如果列表通配符（“*”和“%”）出现在邮箱名称中，则不会对它们进行特殊处理。
If the server that supports the NOTIFY extension also supports CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [RFC5267], the UPDATE return option is extended so that a client can request that FETCH attributes be returned when a new message is added to the context result set.
如果支持NOTIFY扩展的服务器还支持[RFC5267]中定义的CONTEXT=SEARCH和/或CONTEXT=SORT，则更新返回选项将被扩展，以便客户端可以请求在将新消息添加到上下文结果集中时返回提取属性。
For example:
例如：
C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO
FROM SUBJECT)])) FROM "boss"
S: * ESEARCH (TAG "a00") (COUNT 17)
S: a00 OK
[...a new message is delivered...]
S: * EXISTS 93
S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)]
{76}
S: Subject: Re: good morning
S: From: myboss@example.org
S: To: bob@example.org
S:
S: )
S: * ESEARCH (TAG "a00") ADDTO (0 93)
C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO
FROM SUBJECT)])) FROM "boss"
S: * ESEARCH (TAG "a00") (COUNT 17)
S: a00 OK
[...a new message is delivered...]
S: * EXISTS 93
S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)]
{76}
S: Subject: Re: good morning
S: From: myboss@example.org
S: To: bob@example.org
S:
S: )
S: * ESEARCH (TAG "a00") ADDTO (0 93)
Note that the EXISTS response MUST precede any FETCH responses, and together they MUST precede the ESEARCH response.
请注意，EXISTS响应必须位于任何FETCH响应之前，并且它们必须一起位于ESEARCH响应之前。
No untagged FETCH response SHOULD be returned if a message becomes a member of UPDATE SEARCH due to flag or annotation changes.
如果消息由于标志或注释更改而成为更新搜索的成员，则不应返回未标记的获取响应。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "command-auth", "mailbox", "mailbox-data", "resp-text-code", and "search-key". The "modifier-update" non-terminal is defined in [RFC5267]. "mbx-list-oflag" is defined in [RFC3501] and updated by [RFC5258].
以下语法规范使用[RFC5234]中指定的增广巴科斯诺尔形式（ABNF）表示法。[RFC3501]定义了非终端的“能力”、“命令验证”、“邮箱”、“邮箱数据”、“resp文本代码”和“搜索键”。[RFC5267]中定义了“修改器更新”非终端。“mbx标签列表”在[RFC3501]中定义，并由[RFC5258]更新。
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. For example, the <filter-mailboxes-selected> non-terminal value "SELECTED" must be treated in the same way as "Selected" or "selected".
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。例如，<filter mailboxes selected>非终端值“selected”必须以与“selected”或“selected”相同的方式处理。
capability =/ "NOTIFY"
能力=/“通知”
command-auth =/ notify
命令auth=/notify
notify = "NOTIFY" SP (notify-set / notify-none)
notify=“notify”SP（notify set/notify none）
notify-set = "SET" [status-indicator] SP event-groups ; Replace registered notification events ; with the specified list of events
通知set=“set”[状态指示器]SP事件组；替换已注册的通知事件；使用指定的事件列表
notify-none = "NONE"
; Cancel all registered notification
; events. The client is not interested
; in receiving any events.
notify-none = "NONE"
; Cancel all registered notification
; events. The client is not interested
; in receiving any events.
status-indicator = SP "STATUS"
状态指示器=SP“状态”
one-or-more-mailbox = mailbox / many-mailboxes
one-or-more-mailbox = mailbox / many-mailboxes
many-mailboxes = "(" mailbox *(SP mailbox) ")"
many-mailboxes = "(" mailbox *(SP mailbox) ")"
event-groups = event-group *(SP event-group)
事件组=事件组*（SP事件组）
event-group = "(" filter-mailboxes SP events ")" ;; Only <message-event>s are allowed in <events> ;; when <filter-mailboxes-selected> is used.
事件组=“（“筛选器邮箱SP事件”）”；；<events>中只允许<message event>s；；使用<filter mailboxes selected>时。
filter-mailboxes = filter-mailboxes-selected / filter-mailboxes-other
筛选邮箱=筛选所选邮箱/筛选其他邮箱
filter-mailboxes-other = "inboxes" / "personal" / "subscribed" /
( "subtree" SP one-or-more-mailbox ) /
( "mailboxes" SP one-or-more-mailbox )
filter-mailboxes-other = "inboxes" / "personal" / "subscribed" /
( "subtree" SP one-or-more-mailbox ) /
( "mailboxes" SP one-or-more-mailbox )
filter-mailboxes-selected = "selected" / "selected-delayed"
;; Apply to the currently selected mailbox only.
;; Only one of them can be specified in a NOTIFY
;; command.
filter-mailboxes-selected = "selected" / "selected-delayed"
;; Apply to the currently selected mailbox only.
;; Only one of them can be specified in a NOTIFY
;; command.
events = ( "(" event *(SP event) ")" ) / "NONE"
;; As in [MSGEVENT].
;; "NONE" means that the client does not wish
;; to receive any events for the specified
;; mailboxes.
events = ( "(" event *(SP event) ")" ) / "NONE"
;; As in [MSGEVENT].
;; "NONE" means that the client does not wish
;; to receive any events for the specified
;; mailboxes.
event = message-event /
mailbox-event / user-event / event-ext
event = message-event /
mailbox-event / user-event / event-ext
message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] )
/ "MessageExpunge"
/ "FlagChange"
/ "AnnotationChange"
;; "MessageNew" includes "MessageAppend" from
;; [MSGEVENT]. "FlagChange" is any of
;; "MessageRead", "MessageTrash", "FlagsSet",
;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
;; includes "MessageExpire" [MSGEVENT].
;; MessageNew and MessageExpunge MUST always
;; be specified together. If FlagChange is
;; specified, then MessageNew and MessageExpunge
;; MUST be specified as well.
;; The fett-att list may only be present for the
;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).
message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] )
/ "MessageExpunge"
/ "FlagChange"
/ "AnnotationChange"
;; "MessageNew" includes "MessageAppend" from
;; [MSGEVENT]. "FlagChange" is any of
;; "MessageRead", "MessageTrash", "FlagsSet",
;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
;; includes "MessageExpire" [MSGEVENT].
;; MessageNew and MessageExpunge MUST always
;; be specified together. If FlagChange is
;; specified, then MessageNew and MessageExpunge
;; MUST be specified as well.
;; The fett-att list may only be present for the
;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).
mailbox-event = "MailboxName" /
"SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename".
mailbox-event = "MailboxName" /
"SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename".
user-event = "ServerMetadataChange"
user-event = "ServerMetadataChange"
event-ext = atom ;; For future extensions
事件ext=原子；；用于将来的扩展
oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
;; Extended data item (mbox-list-extended-item)
;; returned in a LIST response when a mailbox is
;; renamed.
;; Note 1: the OLDNAME tag can be returned
;; with or without surrounding quotes, as per
;; mbox-list-extended-item-tag production.
oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
;; Extended data item (mbox-list-extended-item)
;; returned in a LIST response when a mailbox is
;; renamed.
;; Note 1: the OLDNAME tag can be returned
;; with or without surrounding quotes, as per
;; mbox-list-extended-item-tag production.
resp-text-code =/ "NOTIFICATIONOVERFLOW" / unsupported-events-code
resp text code=/“NOTIFICATIONOVERFLOW”/不支持的事件代码
message-event-name = "MessageNew" /
"MessageExpunge" / "FlagChange" /
"AnnotationChange"
message-event-name = "MessageNew" /
"MessageExpunge" / "FlagChange" /
"AnnotationChange"
event-name = message-event-name / mailbox-event / user-event
事件名称=消息事件名称/邮箱事件/用户事件
unsupported-events-code = "BADEVENT" SP "(" event-name *(SP event-name) ")"
不支持的事件代码=“BADEVENT”SP”（“事件名称*（SP事件名称）”）
modifier-update = "UPDATE" [ "(" fetch-att *(SP fetch-att) ")" ]
修饰符update=“update”[“（“获取附件*（SP获取附件）”）”]
mbx-list-oflag =/ "\NoAccess"
标签的mbx列表=/“\n不访问”
It is very easy for a client to deny itself service using NOTIFY. Asking for all events on all mailboxes may work on a small server, but with a big server, can swamp the client's network connection or processing capability. In the worst case, the server's processing could also degrade the service it offers to other clients.
客户端很容易使用NOTIFY拒绝自己的服务。请求所有邮箱上的所有事件可能在小型服务器上工作，但在大型服务器上，可能会淹没客户端的网络连接或处理能力。在最坏的情况下，服务器的处理也会降低它向其他客户端提供的服务。
Server authors should be aware that if a client issues requests and does not listen to the resulting responses, the TCP window can easily fill up, and a careless server might block. This problem also exists in plain IMAP; however, this extension magnifies the problem.
服务器作者应该知道，如果客户端发出请求而不侦听结果响应，TCP窗口很容易被填满，粗心的服务器可能会阻塞。这个问题在普通IMAP中也存在；然而，这种扩展放大了问题。
This extension makes it possible to retrieve messages immediately when they are added to the mailbox. This makes it wholly impractical to delete sensitive messages using programs like imapfilter. Using SIEVE [RFC5228] or similar is much better.
此扩展允许在邮件添加到邮箱时立即检索邮件。这使得使用imapfilter之类的程序删除敏感消息完全不切实际。使用筛子[RFC5228]或类似物更好。
The IANA has added NOTIFY to the list of IMAP extensions.
IANA已将NOTIFY添加到IMAP扩展列表中。
The following entry has been added to the LIST-EXTENDED response registry [RFC5258]:
以下条目已添加到列表扩展响应注册表[RFC5258]：
To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED extended data item
致：iana@iana.org主题：旧名称列表-扩展数据项的注册
LIST-EXTENDED extended data item tag: OLDNAME
列表-扩展数据项标记：OLDNAME
LIST-EXTENDED extended data item description: The OLDNAME extended data item describes the old mailbox name for the mailbox identified by the LIST response.
列表扩展数据项说明：OLDNAME扩展数据项说明列表响应标识的邮箱的旧邮箱名称。
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): none
哪个列表扩展选项（及其类型）导致返回此扩展数据项（如果有）：无
Published specification : RFC 5465, Section 5.4.
已发布规范：RFC 5465，第5.4节。
Security considerations: none
安全考虑：无
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information: Alexey
Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information: Alexey
Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
The authors gratefully acknowledge the help of Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo Sirainen, and Eric Burger. In particular, Peter Coates contributed lots of text and useful suggestions to this document.
作者衷心感谢彼得·科茨、戴夫·克里德兰、马克·克里斯宾、塞勒斯·达布、阿比吉特·梅农·森、蒂莫·西莱宁和埃里克·伯格的帮助。特别是，Peter Coates为本文件提供了大量文本和有用的建议。
Various examples are copied from other RFCs.
从其他RFC复制了各种示例。
This document builds on one published and two unpublished drafts by the same authors.
本文件以同一作者的一份已发表和两份未发表的草稿为基础。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[RFC2177]Leiba，B.，“IMAP4空闲命令”，RFC2177，1997年6月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC2342]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC2342，1998年5月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC4466，2006年4月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.translate error, please retry
[RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008.
[RFC5162]Melnikov，A.，Cridland，D.，和C.Wilson，“用于快速邮箱重新同步的IMAP4扩展”，RFC 51622008年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.
[RFC5258]Leiba，B.和A.Melnikov，“互联网消息访问协议第4版-列表命令扩展”，RFC 5258，2008年6月。
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[RFC5267]Cridland，D.和C.King，“IMAP4的上下文”，RFC 5267，2008年7月。
[RFC5423] Newman, C. and R. Gellens, "Internet Message Store Events", RFC 5423, Month 2009.
[RFC5423]Newman，C.和R.Gellens，“互联网信息商店事件”，RFC 5423，2009年第二个月。
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[RFC5464]Daboo，C.，“IMAP元数据扩展”，RFC 5464，2009年2月。
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]Guenther，P.，Ed.，和T.Showalter，Ed.，“筛选：电子邮件过滤语言”，RFC 5228，2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[EMAIL-ARCH]Crocker，D.，“互联网邮件架构”，正在进行的工作，2008年10月。
Authors' Addresses
作者地址
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx邮件系统有限公司Schweppermannstr。德国慕尼黑8D-81671
EMail: arnt@oryx.com
EMail: arnt@oryx.com
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Curtis King Isode Ltd 5城堡商业村英国米德尔塞克斯郡汉普顿车站路36号TW12 2BX
EMail: Curtis.King@isode.com
EMail: Curtis.King@isode.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com