Applications lemonade I-D Internet-Draft One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to-client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system.

A message store is used to organize Internet Messages into one or more mailboxes, possibly hierarchical, annotate them in various ways and provide access to these messages and associated meta-data. Three different standards-based protocols have been widely deployed to remotely access a message store. Post Office Protocol (POP) provides simple download-and-delete access to a single mail drop (which is a subset of the functionality typically associated with a message store). Internet Message Access Protocol (IMAP) provides an extensible feature-rich model for online, offline and disconnected access to a message store with minimal constraints on any associated "fat-client" user interface. Finally, mail access applications built on top of Hypertext Transfer Protocol (HTTP) which run in standards-based web browsers provide a third standards-based access mechanism for online-only access. While simple and/or ad-hoc mechanisms for notifications have sufficed to some degree in the past (e.g., Simple New Mail Notification, IMAP4 IDLE command), as the scope and importance of message stores expands, the demand for a more complete store notification system increases. Some of the driving forces behind this demand include: Mobile devices with intermittent network connectivity that have "new mail" or "message count" indicators Unified messaging systems which include both Internet and voice mail require support for a message waiting indicator on phones Interaction with systems for event-based or utility-computing billing Simplify the process of passing message store events to non-Internet notification systems A calendar system may wish to subscribe to MessageNew notifications in order to support iMIP. Some jurisdictions have laws or regulations for information protection and auditing which require interoperable protocols between message stores built by messaging experts and compliance auditing systems built by compliance experts. Vendors who have deployed proprietary notification systems for their Internet message stores have seen significant demand to provide notifications for more and more events. As a first step towards building a notification system, this document attempts to enumerate the core events that real-world customers demand. This document includes those events which can be generated by the use of IMAP4Rev1 and some existing extensions. As new IMAP extensions are defined, or additional event types or parameters need to be added, the set specified here can be extended by means of an IANA registry with update requirements, as specified in .

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 RFC 2119 When these words appear in lower-case or with initial-capital letters, they are not RFC 2119 key words.

This section to be removed if/when this draft is published as an RFC.

Added discussion of message integrity to Security Considerations. Reviewed use of "may", "must" and "should" for conversion to "MAY", "MUST" and "SHOULD". Reworded MessageNew and MessageExpire text. Additional clarifying text added to Future Extensions. Added explicit prohibition on \Recent in FlagsSet to match the one in FlagsClear (\Recent was also explicitly excluded from flagNames). Clarified that Logout disconnection types are suggestions only. Added serverDomain and serverPort parameters, and clarified clientPort. Clarified that a kilobyte is 1024 octets. Clarified that FlagSet and FlagClear include one or more flags or keywords. Changed "cover about 95% of the known use cases" to "an overwhelming majority of known use cases" in Event Types.

Reworded statement on optional versus mandatory and removed Anchor 11. Included mailbox admin events in list of exceptions in Appendix A, and deleted Anchor 23.

Added QuotaChange event.

Fix typo in Login event Remove UIDVALIDITY from MailboxRename event. Made event names hierarchical: Changed AppendMessage to MessageAppend, ExpireMessage to MessageExpire, ExpungeMessage to MessageExpunge, NewMessage to MessageNew, OverQuota to QuotaExceed, UnderQuota to QuotaWithin, ReadMessages to MessageRead, TrashMessages to MessageTrash, SetFlags to FlagsSet, and ClearFlags to FlagsClear; deleted Editor's Note asking if this should be done. Made ACL information a future extension in MailboxCreate.

Add text indicating that mailboxes may contain Internet messages and/or child mailboxes. Remove word "folder" from definition of "mailbox." Add editor's note regarding optionality in this document. Add editor's note regarding optional vs. mandatory events. Add editor's note regarding event names. Remove U.S.-centric wording regarding laws. Review uses of "will" and change as appropriate. Clarification of server address in login event. Add MailboxCreate, MailboxDelete, MailboxRename, and MailboxSubscribe events. Add mailboxName and oldMailboxName parameter.s Move RFC2822 from normative to informative. Add IANA Considerations and reference to RFC 2434. Minor grammatical improvements. Incorporate edits from Alexey Melnikov. Add editor's note regarding deployment of mailbox admin events. Add Acknowledgments section. Fix formatting to add blank line between paragraphs in event and parameter lists. Add reference to RFC 2119 and "Conventions" section. Update RFC 2222 to RFC 4422.

Add modseq event parameter. Add tags event parameter.

Rename draft title Add Change History section. Update reference to URLAUTH. Add FlagsSet, FlagsClear events and flagNames parameter. Update future events section to reflect this change. Removed unnecessary normative reference to NAMESPACE.

The following terminology is used in this document: A container for Internet messages and/or child mailboxes. A mailbox may or may not permit delivery of new messages via a mail delivery agent. A mailbox identifier provides sufficient information to identify a specific mailbox on a specific server instance. An IMAP URL can be a mailbox identifier. Protocols which provide clients (e.g., a mail user agent or web browser) with access to the message store including but not limited to IMAP, POP and HTTP. As defined in . As defined in IMAP4rev1. UIDVALIDITY is critical to the correct operation of a caching mail client. When it changes, the client MUST flush its cache. It's particularly important to include UIDVALIDITY with event notifications related to message addition or removal in order to keep the message data correctly synchronized.

The events that are generated by a message store depend to some degree on the model used to represent a message store. The model the IETF has for a message store is implicit from IMAP4rev1 and extensions, so that model is assumed by this document. A message store event typically has an associated mailbox name and usually has an associated user name (or authorization identity if using the terminology from SASL). Events referring to a specific message can use an IMAP URL to do so. Events referring to a set of messages can use an IMAP URL to the mailbox plus an IMAP UID set. Each notification has a type and parameters. The type determines the type of event, while the parameters supply information about the context of the event that may be used to adjust subscription preferences or may simply supply data associated with the event. The types and parameter names in this document are restricted to US-ASCII printable characters so these events can be easily mapped to an arbitrary notification system. However, this document assumes arbitrary parameter values (including large and multi-line values) can be encoded with the notification system. Systems which lack that feature could only implement a subset of these events. This document does not indicate which event parameters are mandatory or optional. That is done in documents which specify specific message formats or bindings to a notification system. For scalability reasons, some degree of filtering at event generation is necessary. At the very least, the ability to turn on and off groups of related events and to suppress inclusion of large parameters (such as messageContent) is needed. A sophisticated publish/subscribe notification system may be able to propagate cumulative subscription information to the publisher. Some of these events might be logically collapsed into a single event type with a required parameter to distinguish between the cases (e.g., QuotaExceed and QuotaWithin). However until such time that an event subscription model is formulated, it's not practical to make such decisions. We thus note only the fact that some of these events may be viewed as a single event type.

This section discusses the different types of events useful in a message store event notification system. The intention is to document the events sufficient to cover an overwhelming majority of known use cases while leaving less common event types for the future. This section mentions parameters which are important or specific to the events described here. Event parameters likely to be included in most or all notifications are discussed in the next section.

This section includes events related to message addition and deletion. A message was appended or concatenated to a mailbox by a message access client. For the most part, this is identical to the MessageNew event type, except that the SMTP envelope information is not included as a parameter, but information about which protocol triggered the event MAY be included. See the MessageNew event for more information. One or more messages were expired from a mailbox due to server expiration policy and are no longer accessible by the end-user. The parameters include a mailbox identifier which MUST include UIDVALIDITY, and a UID set which describes the messages. Information about which server expiration policy was applied may be included in the future. One or more messages were expunged from a mailbox by an IMAP CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action and are no longer accessible by the end-user. The parameters include a mailbox identifier which MUST include UIDVALIDITY, a UID set, and MAY also indicate which access protocol triggered the event. A new message was received into a mailbox via a message delivery agent. The parameters include a message identifier which for IMAP-accessible message stores MUST include UIDVALIDITY and UID. The parameters MAY also include SMTP envelope and other arbitrary message and mailbox meta-data. In some cases, the entire new message itself may be included. The set of parameters SHOULD be adjustable to the client's preference with limits set by server policy. An interesting policy, for example, would be to include messages up to 2K in size with the notification, but for larger messages to include a URLAUTH reference. An operation failed (typically MessageNew) because the user's mailbox exceeded one of the quotas (e.g., disk quota, message quota, quota by message context, etc). The parameters SHOULD include at least the relevant user and quota, and optionally the mailbox. Quota usage SHOULD be included if possible. Parameters needed to extend this to support quota by context are not presently described in this document, but could be added in the future. An operation occurred (typically MessageExpunges or MessageExpires) which reduced the user's quota usage under their limit. The user's quota was changed.

This section includes events related to changes in message flags. One or more messages in the mailbox were marked as read or seen by a user. Note that POP has no concept of read or seen messages, so these events are only generated by IMAP or HTTP clients (or equivalent). The parameters include a mailbox identifier and a set of message UIDs. One or more messages were marked for future deletion by the user but are still accessible over protocol (the user's client may or may not make these messages accessible through its user interface). The parameters include a mailbox identifier and a set of message UIDs. One or more messages in the mailbox had one or more IMAP flags or keyword sets. The parameters include a list of IMAP flag or keyword names that were set, a mailbox identifier and a set of message UIDs that were impacted. The flagNames MUST not include \Recent. For compatibility with simpler clients, it SHOULD be configurable whether setting the \Seen or \Deleted flags results in this event or the simpler MessageRead/MessageTrash events. By default, the simpler message forms SHOULD be used for MessageRead and MessageTrash. One or more messages in the mailbox had one or more IMAP flags or keywords cleared. The parameters include a list of IMAP flag or keyword names that were cleared, a mailbox identifier and a set of message UIDs that were impacted. The flagNames parameter MUST not include \Recent.

This section lists events related to message store access accounting. A user has logged in to the system via IMAP, HTTP, POP or some other mechanism. The parameters include the domain name and port used to access the server and the user's authorization identity. Additional possible parameters include the client's IP address and port, the authentication identity (if different from the authorization identity), the service name, the authentication mechanism, information about any negotiated security layers, a timestamp and other information. A user has logged out or otherwise been disconnected from the message store via IMAP, HTTP, POP or some other mechanism. The parameters include the server domain name and the user's authorization identity. Additional parameters MAY include any of the information from the "Login" event as well as information about the type of disconnect (suggested values include graceful, abort, timeout, and security layer error), the duration of the connection or session and other information.

This section lists events related to the management of mailboxes. A mailbox has been created, or an access control changed on an existing mailbox so that it is now accessible by the user. If the mailbox creation caused the creation of new mailboxes earlier in the hierarchy, separate MailboxCreate events are not generated for those as their creation is implied. The parameters include the created mailbox identifier, its UIDVALIDITY for IMAP-accessible message stores, and MAY also indicate which access protocol triggered the event. Access/permissions information (such as ACL settings) require a standardized format to be included, and so are left for future extension. A mailbox has been deleted, or an access control changed on an existing mailbox so that it is no longer accessible by the user. Note that if the mailbox has child mailboxes, only the specified mailbox has been deleted, not the children. The mailbox becomes \NOSELECT and the hierarchy remains unchanged, as per the description of the DELETE command in RFC 3501IMAP4rev1. The parameters include the deleted mailbox identifier, and MAY also indicate which access protocol triggered the event. A mailbox has been renamed. Note that, per the description of the RENAME command in RFC 3501IMAP4rev1, special semantics regarding the mailbox hierarchy apply when INBOX is renamed (child mailboxes are usually included in the rename, but are excluded when INBOX is renamed). When a mailbox other than INBOX is renamed and its child mailboxes are also renamed as a result, separate MailboxRename events are not generated for the child mailboxes, as their renaming is implied. If the rename caused the creation of new mailboxes earlier in the hierarchy, separate MailboxCreate events are not generated for those as their creation is implied. When INBOX is renamed, a new INBOX is created. A MailboxCreate event is not generated for the new INBOX, since it is implied. The parameters include the old mailbox identifier, the new mailbox identifier, and MAY also indicate which access protocol triggered the event. A mailbox has been added to the subscription list. The parameters include the user whose subscription list has been affected and the mailbox identifier, and MAY also indicate which access protocol triggered the event. A mailbox has been removed from the subscription list. The parameters include the user whose subscription list has been affected and the mailbox identifier, and MAY also indicate which access protocol triggered the event.

This section lists parameters included with these events. Included with all events generated by message access protocols. The authentication identity associated with this event, as distinct from the authorization identity (see "user"). This is not included when it is the same as the value of the user parameter. May be included with MessageAppend and MessageNew. The IMAP BODYSTRUCTURE of the message. Included with all events generated by message access protocols. The IP address of the message store access client which performed the action which triggered the notification. Included with all events generated by message access protocols. The port number of the message store access client which performed an action which triggered the notification (the port from which the connection occurred). Included with QuotaExceed, QuotaWithin, and QuotaChange notifications relating to a user or mailbox disk quota. May be included with other notifications. Disk quota limit in kilobytes (1024 octets). Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox disk quota. May be included with other notifications. Disk space used in kilobytes (1024 octets). Only disk space which counts against the quota is included. May be included with the MessageNew notification. The message transfer envelope associated with final delivery of the message for the MessageNew notification. This includes the MAIL FROM and relevant RCPT TO line(s) used for final delivery with CRLF delimiters and any ESMTP parameters. Included with FlagsSet and FlagsClear events. May be included with MessageAppend and MessageNew to indicate flags which were set initially by the APPEND command or delivery agent respectively. A space-separated list of IMAP flag or keyword names that were set or cleared. Flag names begin with backslash while keyword names do not. The \Recent flag is explicitly not permitted in the list. Included in events which affect mailboxes. URI describing the mailbox. In the case of MailboxRename, this refers to the new name. Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox message count quota. May be included with other notifications. Quota limit on the number of messages in the mailbox, for events referring to a mailbox. May be included with MessageAppend and MessageNew. The entire message itself. Size based suppression of this SHOULD be available. May be included with MessageAppend and MessageNew. Size of the RFC 2822 message itself in octets. This value matches the length of the IMAP literal returned in response to an IMAP FETCH of BODY[] for the referenced message. Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox message count quota. May be included with other notifications. Number of messages in the mailbox. This is typically included with message addition and deletion events. May be included with any notification referring to one message. This is the 64-bit integer MODSEQ as defined in . No assumptions about MODSEQ can be made if this is omitted. URI describing the old name of a renamed or moved mailbox. May be included with any notification. The process ID of the process which generated the notification. May be included with any notification. The name of the process which generated the notification. Included in Login, and optionally in Logout or other events. The domain name or IP address used to access the server or mailbox. Included in Login, and optionally in Logout or other events. The port number used to access the server. This is often a well-known port. May be included with any notification. The fully qualified domain name of the server which generated the event. Note that this may be different from the server name used to access the mailbox included in the mailbox identifier. May be included with any notification. The name of the service which triggered the event. Suggested values include "imap", "pop", "http", and "admincli" (for an administrative client). May be included with any notification. This is a comma-separated list of UTF-8 tags. One or more tags can be set at the time a notification criteria or notification subscription is created. Subscribers can use tags for additional client-side filtering or dispatch of events. May be included with any notification. When the notification was generated in syntax. May be included with any notification referring to a mailbox. The UID that is projected to be assigned next in the mailbox. This is typically included with message addition and deletion events. This is equivalent to the UIDNEXT status item in the IMAP STATUS command. Included with MessageExpires, MessageExpunges, MessageRead, MessageTrash, FlagsSet and FlagsClear. This includes the set of IMAP UIDs referenced. Included with all notifications and refers to the IMAP server, a mailbox or a message. Typically an IMAP URL. This can include the name of the server used to access the mailbox/message, the mailbox name, the UIDVALIDITY of the mailbox, and the UID of a specific message. Included with all events generated by message access protocols. This is the SASL authorization identifier used when the user connected to the access protocol which triggered the event. For events associated with a mailbox, this may be different from the owner of the mailbox specified in the IMAP URL.

The IANA is requested to create a new registry for "Internet Message Store Events" containing two sub-registries: event names and event parameters. For both event names and event parameters, entries which do not start with "vnd." are added by the IETF and intended for interoperable use. Entries which start with "vnd." are intended for private use by one or more parties and are allocated to avoid collisions. The initial values are contained in this document. Using IANA Considerations terminology, entries which do not start with "vnd." are allocated by IETF Consensus, while those starting with "vnd." are allocated First Come First Served.

Notifications can produce a large amount of traffic and expose sensitive information. When notification mechanisms are used to maintain state between a different entities, the ability to corrupt or manipulate notification messages could enable an attacker to modulate the state of these entities. For example, if an attacker were able to modify notifications sent from a message store to an auditing server, he could modify the "user" and "messageContent" parameters in MessageNew notifications to create false audit log entries. A competent transfer protocol for notifications must consider authentication, authorization, privacy, and message integrity, as well as denial-of-service issues. While the IETF has adequate tools and experience to address these issues for mechanisms which involve only one TCP connection, notification or publish/subscribe protocols which are more sophisticated than a single end-to-end TCP connection will need to pay extra attention to these issues and carefully balance requirements to successfully deploy a system with security and privacy considerations.

Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed and offered improvements to this draft. Richard Barnes did a nice review during Last Call.

This document specifies core functionality based on events which are believed to be well understood, have known use cases and are implemented by at least one deployed real-world Internet message store. (A few events are exceptions to the last test only: FlagsSet, FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, MailboxSubscribe, and MailboxUnSubscribe.) Some events have been suggested, but are postponed to future extensions because they do not meet this criteria. These events include messages which have been moved to archive storage and may require extra time to access, quota by message context, authentication failure, user mail account disabled, annotations, and mailbox ACL or metadata change. The descriptions of several events note additional parameters which are likely candidates for future inclusion. See for how the list of events and parameters can be extended. In order to narrow the scope of this document to something that can be completed, only events generated from the message store (by a message access module, administrative module or message delivery agent) are considered. A complete mail system is normally linked with an identity system which would also publish events of interest to a message store event subscriber. Events of interest include account created/deleted/disabled and password changed/expired.