[要約] RFC 5465はIMAP NOTIFY拡張機能に関する仕様であり、IMAPサーバーからの変更通知をクライアントに送信するためのメカニズムを提供します。目的は、クライアントがリアルタイムでメールボックスの変更を把握できるようにすることです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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.
アイドルコマンド（[RFC2177]で定義）は、選択したメールボックスのIMAP MailStoreイベントに関するIMAPサーバーがIT通知をプッシュするモードにクライアントが移動する方法を提供します。ただし、アイドル拡張機能は、どのサーバーイベントを送信できるか、各イベントに応答してサーバーが送信する情報を制限または制御しません。また、アイドルは選択したメールボックスにのみ適用されるため、メールボックスごとに追加の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サーバーは、次の場合にMailStoreの変更に関する情報のみをクライアントに送信します。
- 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.
- クライアントコマンドの結果（たとえば、フェッチまたはストアコマンドへのフェッチの回答） - 他のセッションの変更の結果としてコマンドの終了直前（例えば存在または抹消）の未承諾応答として、および - アイドルコマンド中。
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コマンドは、これらの最後の2つのケースで返される可能性のある情報を拡張し、また許可し、コマンド間の更新に関する情報をサーバーに送信することを要求します。また、Notifyコマンドでは、クライアントが選択したメールボックスの承認された情報が送信された情報を拡張し、他のメールボックスに関して送信される更新情報を要求することもできます。
The interaction between IDLE and NOTIFY commands is described in Section 4.
アイドルコマンドと通知コマンドの相互作用については、セクション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]はこのドキュメントで補強され、更新戻りオプションを拡張して、新しいメッセージが配信または別のセッションに追加されたときに返されるFetch-attsのリストを指定します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]で定義されている通知に準拠したサーバーが拡張リスト応答を返すことができなければならない場合でも、リスト拡張[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.
結果：OK-サーバーは、要求に応じてクライアントに通知します。いいえ - サポートされていない通知イベント、通知が複雑すぎるか高価など。悪いコマンドは不明、無効、サポートされていない、または未知の引数があります。
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コマンドには2つのフォームがあります。通知なしでは、クライアントがサーバーで起こっているいかなる種類のイベントにも関心がないことを指定してください。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セットコマンドは、フラグの変更や新規または抹消されたメッセージなど、現在選択されているメールボックス（存在する場合）に蓄積された変更を直ちに返している必要があります。したがって、成功した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コマンドは、メッセージに関連したメールボックスへのメッセージ関連の変更の通知を要求できます。これは、メッセージ通知が生成されている時点であれば、これは、選択された[セクション6.1を参照）に選択した[選択]セットセットコマンドで選択された[選択]メールボックスセレクター（セクション6.1を参照）を指定することによって行われます。選択された/選択されたメールボックスセレクターがNotify Setコマンドで指定されていない場合、これは、クライアントが現在選択されているメールボックスの<メッセージ-Event>を受け取りたくないことを意味します。これは、選択されたものを指定することと同じです。
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.
クライアントは、他のメールボックスの名前または限られたメールボックスパターンの一致で通知を要求することもできます。現在選択されているメールボックスに返されたメッセージ関連の通知は、選択したメールボックスがコマンドの名前で表示されている（またはパターンと一致する）場合でも、選択された/選択されたメールボックス仕様によって指定されたものになります。非メサージ関連の通知は、選択された/選択された配置以外のメールボックス仕様によって制御されます。
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 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.
NotifyコマンドがMessageNew、MessageExpunge、AnnotationChange、またはFlagChange通知を、現在選択しているメールボックス以外のメールボックスのFlagChange通知を有効にし、クライアントがステータスインジケータパラメーターを指定した場合、notifyのタグ付けされたOKを前にサーバーがそのメールボックスのステータス応答を送信する必要があります。MessageNewが有効になっている場合、ステータス応答にはメッセージ、uidnext、およびuidvalidityを含める必要があります。MessageExpungeが有効になっている場合、ステータス応答にメッセージが含まれている必要があります。AnnotationChangeまたはFlagChangeのいずれかが含まれており、サーバーがCondstore [RFC4551]および/またはQRESYNC [RFC5162]拡張をサポートする場合、ステータス応答にはuidivalityとhighestmodseqを含める必要があります。ステータスインジケータパラメーターがないため、クライアントは追加のステータス応答を回避できます。これは、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」がありますが、クライアントは指定されたイベントの処理に必要な別の権利を持っていません。サーバーは、\ noaccess name属性を含む拡張されていない拡張リスト応答で応答する必要があります。
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').
クライアントが現在の興味深いイベントのリストで指定されたメールボックスの少なくとも1つにアクセスできる場合、サーバーはタグ付きOK応答を返す必要があります。クライアントが指定されたメールボックスのいずれにもアクセスできず、将来アクセスしないことができる場合、サーバーはタグなしの応答を返すことができます（たとえば、クライアントは「Subtree Bar/foo」、 'bar/fooのイベントを指定しました「存在せず、親「バー」の返品\ noinferiorsをリストします）。
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.
クライアントがサポートされていないタイプのイベントの情報を要求した場合、サーバーはタグ付けされたNO応答でコマンドを拒否する必要があります（悪いことではありません）。この応答には、サーバーがサポートするすべてのイベントの名前をリストする必要があるBadevent Responseコードが含まれている必要があります。
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
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.
通知は、一部のクライアントにとってアイドルを不要にします。クライアントがコマンドで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.
コマンドでMSNSと '*'を使用するクライアントは、notifyコマンドに選択したドレイのメールボックス仕様を指定する場合でも、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.
イベントがこのクライアントによって引き起こされている場合、サーバーはクライアントに通知することを省略する必要があります。たとえば、クライアントの問題が作成され、新しく作成されたメールボックスをカバーする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.
フラッグチェンジおよび/または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セットでなしイベント仕様を使用したり、Notify Noneを使用したりして、必要なイベントを省略しないようにサーバーに指示できます。特に、SETの通知...クライアントがスナップショット施設として使用することはありません。
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およびFlags/Annotation Fetch Dataアイテムを含める必要がある未承諾のフェッチ応答を送信してクライアントに通知する必要があります。また、新しいフラグやOK [PermanntFlags ...]の応答を送信する場合があります。
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]で指定されているように検索コンテキストが有効である場合、必要に応じて、検索addtoまたはesearch removerfromも生成されます。この場合、フェッチの応答はESEarch Responseに先行する必要があります。
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およびUIDialidityステータスデータ項目を含むステータス応答を送信します。\ seedフラグが変更されたメッセージの数が変更された場合、サーバーにはステータス応答に目に見えないデータ項目も含めることができます。Condstore/QRESYNCがクライアントによって有効になっていない場合、サーバーが目に見えないデータ項目を含めないことを選択した場合、サーバーはクライアントに通知しません。このイベントが要求された場合、サーバーはメールボックスuidalidityの変更についてクライアントに通知する必要があります。これは、uidalivityを含むステータス応答を送信することによって行われます。
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が使用されています： *ステータスリスト/レモネード（highestmodseq 65666665 uidalivity 101）
This covers both MessageNew and MessageAppend in [RFC5423].
これは、[RFC5423]のMessagenewとMessageapendの両方をカバーします。
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.
新しい/Appedメッセージが選択されたメールボックスにある場合、サーバーは、クライアントが要求した情報を含む未承諾の存在応答を送信することにより、クライアントにクライアントに通知します。クライアント自体が実行する選択したメールボックスへの追加またはコピーコマンドの結果として、この特定の接続でクライアントによって作成された新しいメッセージに対して、フェッチの応答を生成しないでください。サーバーがメッセージを最近としてマークする場合、サーバーは最近の応答を送信する場合もあります。
Note that a single EXISTS response can be returned for multiple MessageAppend/MessageNew events.
複数のMessageAppend/Messagenewイベントに対して、単一の存在する応答を返すことができることに注意してください。
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]で指定されているように検索コンテキストが有効である場合、必要に応じて検索ADDTOも生成されます。この場合、存在する応答はESEarch Responseに先行する必要があります。Notifyコマンドと検索およびソートコマンドの両方（セクション7を参照）は、新しいメッセージに対して返される属性を指定できます。これらの属性は、単一のフェッチ応答に結合する必要があります。サーバーは、複製データの送信を避ける必要があります。フェッチの応答は、回答を検索する任意の任意の応答に従う必要があります。
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.
新しい/Appedメッセージが別のメールボックスにある場合、サーバーは関連するメールボックスの承認ステータス（UIDNEXTメッセージ）応答を送信します。Condstore拡張[RFC4551]および/またはQRESYNC拡張[RFC5162]が有効になっている場合、HightModSeqステータスデータ項目をステータス応答に含める必要があります。
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.
クライアントは、\見られたフラグを暗黙的に設定したり、特定のボディパートの存在を前提としているフェッチ属性を使用してはなりません。uid、modseq、flags、envelope、body.peek [header.fields ...および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)
And in another mailbox, without CONDSTORE enabled: S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
そして、別のメールボックスで、Condstoreが有効になっていない：S： *ステータスリスト/レモネード（UIDNEXT 10002メッセージ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).
削除されたメッセージまたはメッセージが選択したメールボックスにある場合、サーバーは、[RFC5162]がサーバーによってサポートされ、クライアントによって有効になっている場合（または消滅した場合）、クライアントに通知します（または消滅します）。
If a search context is in effect, as specified in [RFC5267], an ESEARCH REMOVEFROM will also be generated, if appropriate.
[rfc5267]で指定されているように、検索コンテキストが有効な場合、必要に応じて、eSearch removerfromも生成されます。
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メッセージ）応答を送信します。QRESYNC [RFC5162]拡張機能が有効になっている場合、HightModSeqデータ項目もステータス応答に含める必要があります。
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の意味はいつでも変更できるため、クライアントはコマンドでMSNSを使用できなくなることに注意してください。たとえば、このようなクライアントはFetchを使用することはできませんが、UID Fetchを使用する必要があります。「*」の意味は、メッセージが追加または削除されたときにも変更できます。MSNSの使用を希望するクライアントは、選択したドレイのメールボックス仕様を使用するか、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： * vanished5444
And in another mailbox, when QRESYNC is not enabled: S: * STATUS misc (UIDNEXT 999 MESSAGES 554)
別のメールボックスでは、QRESYNCが有効になっていない場合：S： * STATUS MISC（UIDNEXT 999メッセージ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.
サーバーは、影響を受ける各メールボックス名の未承諾リストの応答を送信することにより、クライアントに通知します。イベント後、メールボックス名がクライアントがアクセスできるメールボックスを参照していない場合、\ nountistentフラグを含める必要があります。
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]を送信します。これは、古いメールボックス名の古い名前の拡張データアイテムを含みます。メールボックスの名前が変更された場合、その子供も名前が変更されます。この場合、子供向けの追加の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.
サーバーが作成または名前が変更されたときにメールボックスを自動的にサブスクライブする場合、影響を受ける各サブスクライブされたメールボックス名の未承諾リスト応答には、\サブスクライブ属性を含める必要があります（[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： * list（\ nonexistent） "。" "「inbox.deletedmailbox」
Example of a renamed mailbox: S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
変更されたメールボックスの例：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).
サーバーは、影響を受ける各メールボックス名の未承諾リストの応答を送信することにより、クライアントに通知します。イベント後にメールボックスがサブスクライブされている場合にのみ、\サブスクライブ属性（[rfc5258]を参照）が含まれています。リスト応答では、すべてのメールボックス属性を正確に計算する必要があることに注意してください（これはLSUBコマンドの動作とは異なります）。
Example: S: * LIST (\Subscribed) "/" "SubscribedMailbox"
例：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イベントを使用した結果、未承諾メタデータ応答を受け取るクライアントは、メタデータを有効にする必要はありません。
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
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イベントを使用した結果として、未承諾メタデータ応答を受け取るクライアントは、メタデータを有効にしたり、メタデータサーバーを有効にしたりする必要はありません。
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
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]」の応答を送信して通知する必要があります。
Example: S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...
例： * [通知オーバーフロー] ...コメントはこちらに行くことができます...
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.
通知が成功したとしても、後で監視されるメールボックスへのアクセスを失うことは依然として可能です。これが発生した場合、サーバーはこれらのメールボックスの監視を停止する必要があります。アクセスが後で付与された場合、サーバーはイベント監視を再開する必要があります。
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' rightを失う場合、\ noaccess name属性を使用して、サーバーはリストの応答を返す必要があります。同様に、メールボックスが以前に\ noaccessを持っていると報告され、「l」の権利が後で付与された場合、サーバーは\ noaccess name属性なしでリストの応答を返す必要があります。
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イベントが受信トレイに報告されています。2番目の<Event-Group>により、受信トレイにサブスクリプションイベントも報告されます。
C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) (personal (SubscriptionChange))
c：notify set（mailboxes inbox（messagenew messageexpunge））（personal（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).
次の例では、クライアントは、現在選択されているメールボックスを除くすべての個人メールボックスのフラッグチェンジイベントを要求します。これは、選択されたメールボックスの他のすべてのメッセージイベント定義をオーバーライドするため、これは前の例とは異なります（セクション3.1を参照）。
C: a notify set (selected (Messagenew (uid flags) messageExpunge)) (personal (MessageNew FlagChange MessageExpunge))
C：notify set（selected（messagenew（uid flags）messageexpunge））（personal（messageNewフラッグチャンゲexpunge）））））
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.
現在選択されているメールボックスに影響を与えるメールボックス仕様の1つのみを、任意のNotifyコマンドで指定できます。2つのそのようなメールボックス仕様（選択および選択された配置）を以下に説明します。
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.
どちらも、選択または検査のいずれかを使用して選択されたメールボックスを参照しています（[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>にのみ適用されます。選択されたセレクターまたは選択したセレクターのいずれかを使用して、他のタイプのイベントを指定することはエラーです。
The SELECTED mailbox specifier requires the server to send immediate notifications for the currently selected mailbox about all specified <message-event>s.
選択したメールボックス仕様は、指定されているすべての<メッセージ-Event>について、現在選択されているメールボックスの即時通知をサーバーに送信する必要があります。
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.
選択されたドレイされたメールボックス仕様は、クライアントが消去されたメッセージに関する情報を返すことを許可するコマンドを発行するまで、メッセージExpungeイベントを遅らせる必要があります（詳細については[RFC3501]のセクション7.4.1を参照）、たとえば、たとえば、NOOPまたはAまで、アイドルコマンドが発行されました。選択された配置が指定されている場合、サーバーは、クライアントが上記のコマンドのいずれかを発行するまで、他の<メッセージ-Event> sの返品を遅らせるか、すぐに返すことがあります。
Personal refers to all selectable mailboxes in the user's personal namespace(s), as defined in [RFC2342].
個人とは、[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）によってメッセージが配信される可能性のあるユーザーのパーソナルネームスペース内のすべての選択可能なメールボックスを指します（[電子メール]、特にセクション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.
サブスクライブは、ユーザーがサブスクライブするすべてのメールボックスを参照しています。
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.
通知拡張機能をサポートするサーバーもコンテキスト=検索および/またはコンテキスト= [rfc5267]で定義されているように並べ替えて、更新の返されたオプションが拡張され、クライアントが新しいメッセージが追加されたときに属性を返すことを要求できるようにコンテキスト結果セット。
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)
Note that the EXISTS response MUST precede any FETCH responses, and together they MUST precede the ESEARCH response.
存在する応答は、フェッチの応答に先行する必要があり、一緒になって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]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。[RFC3501]は、非ターミナル「能力」、「コマンドアース」、「メールボックス」、「Mailbox-Data」、「Resp-Text-Code」、および「Search-Key」を定義します。「モディファイアアップデート」非ターミナルは[RFC5267]で定義されています。「MBX-List-ofLag」は[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選択>「選択された」「選択された」非末端値は、「選択された」または「選択」と同じ方法で扱わなければなりません。
capability =/ "NOTIFY"
command-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
notify-set = "set" [status-indicator] sp event-groups;登録通知イベントを交換します。指定されたイベントのリスト付き
notify-none = "NONE"
; Cancel all registered notification
; events. The client is not interested
; in receiving any events.
status-indicator = SP "STATUS"
status-indicator = sp "status"
one-or-more-mailbox = mailbox / many-mailboxes
many-mailboxes = "(" mailbox *(SP mailbox) ")"
event-groups = event-group *(SP event-group)
event-groups = event-group *（sp event-group）
event-group = "(" filter-mailboxes SP events ")" ;; Only <message-event>s are allowed in <events> ;; when <filter-mailboxes-selected> is used.
event-group = "（"フィルターメールボックスSPイベント "）" ;;<section-event>は<sevents> ;;で許可されています。<filter-mailboxes選択>が使用される場合。
filter-mailboxes = filter-mailboxes-selected / filter-mailboxes-other
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-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.
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>).
mailbox-event = "MailboxName" /
"SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename".
user-event = "ServerMetadataChange"
event-ext = atom ;; For future extensions
event-ext = atom ;;将来の拡張機能
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
message-event-name = "MessageNew" /
"MessageExpunge" / "FlagChange" /
"AnnotationChange"
event-name = message-event-name / mailbox-event / user-event
event-name = message-event-name / mailbox-event / user-event
unsupported-events-code = "BADEVENT" SP "(" event-name *(SP event-name) ")"
unsupported-events-code = "badevent" sp "（" event-name *（sp event-name） "）"
modifier-update = "UPDATE" [ "(" fetch-att *(SP fetch-att) ")" ]
modifier-update = "update" ["（" fetch-att *（sp fetch-att） "）"]]
mbx-list-oflag =/ "\NoAccess"
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などのプログラムを使用して機密メッセージを削除することは完全に非実用的になります。Sieve [RFC5228]などを使用する方がはるかに優れています。
The IANA has added NOTIFY to the list of IMAP extensions.
IANAは、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件名：oldnameリスト拡張データ項目の登録
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>
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラー：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.
著者は、ピーター・コーツ、デイブ・クリッドランド、マーク・クリスピン、サイラス・ダブー、アビヒト・メノン・セン、ティモ・シランエン、エリック・バーガーの助けに感謝しています。特に、ピーター・コーツはこの文書に多くのテキストと有用な提案を提供しました。
Various examples are copied from other RFCs.
他のRFCからさまざまな例がコピーされています。
This document builds on one published and two unpublished drafts by the same authors.
このドキュメントは、同じ著者によって公開された1つと未発表のドラフトに基づいています。
[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 IDLEコマンド」、RFC 2177、1997年6月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC2342] Gahrns、M。and C. Newman、「IMAP4 Namespace」、RFC 2342、1998年5月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年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への拡張を収集した」、RFC 4466、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。およびS. Hole、「条件付き店舗操作またはクイックフラグの変更のためのIMAP拡張」、RFC 4551、2006年6月。
[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、「Quick Mailboxの再同期のためのIMAP4拡張」、RFC 5162、2008年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の増強」、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 -List Command Extensions」、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。and 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。、「Sive：An Email Filtering Language」、RFC 5228、2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[メールアーチ] Crocker、D。、「インターネットメールアーキテクチャ」、2008年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr。8 D-81671ミューンチェンドイツ
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 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Curtis.King@isode.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com