RFC 5423

Internet Message Store Events

📅 published March 2009, from ietf

RFC 5423: Internet Message Store Events 💌

Okay bestie, this is the RFC that's basically about telling you the moment something happens in your inbox 📬✨ Written by R. Gellens (QUALCOMM Inc.) and C. Newman (Sun Microsystems), and published in March 2009 in the Network Working Group stream. It's a Standards Track doc, which means it's a real spec people are supposed to implement 🫶. This header doesn't say it obsoletes or updates any other RFC, so it doesn't claim to replace anything. Iconic 💅

Status of This Memo 📋

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🙏. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document 📜.

Abstract 🦋

Okay so here's the tea 🍵. The existing Internet mail and messaging standards are missing a way for servers to tell other servers, and clients, about message store events. As mail stretches into more stuff like voice mail, devices like cell phones, and integrations with things like web portals and legal compliance systems, we need an interoperable notification system 🔥. This doc tries to list the kinds of events that real-world consumers of that system actually care about.

It describes events and event parameters that are useful in several cases, including notifying administrative systems and end users 🎀. It is not meant to replace a message access facility like IMAP 🙅‍♀️.

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Event Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Event Types  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Message Addition and Deletion  . . . . . . . . . . . . . .  5
     4.2.  Message Flags  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Access Accounting  . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Mailbox Management . . . . . . . . . . . . . . . . . . . .  8
   5.  Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Future Extensions . . . . . . . . . . . . . . . . . . 17

1. Introduction 🌟

Okay so a message store is what organizes [RFC5322] Internet Messages into one or more mailboxes (which can be hierarchical 🌳), lets you annotate them in different ways, and gives you access to the messages and their metadata 📂. Three standards-based protocols have been widely deployed to access a message store remotely, and they're all kind of different bestie 👯‍♀️:

  • The Post Office Protocol (POP) [RFC1939] gives you simple download-and-delete access to a single mail drop. That's a subset of what a message store usually does 📭.
  • The Internet Message Access Protocol (IMAP) [RFC3501] is the extensible, feature-rich one. It supports online, offline, and disconnected access with minimal constraints on any "fat-client" user interface 💅.
  • Mail access apps built on the Hypertext Transfer Protocol (HTTP) [RFC2616] that run in standards-based web browsers give you a third option, for online-only access 🌐.

Simple and/or ad-hoc notification mechanisms have kind of gotten by so far, like "Simple New Mail Notification" [RFC4146] and "IMAP4 IDLE Command" [RFC2177] 🥹. But as message stores get bigger and more important, the demand for a more complete store notification system keeps growing 📈. Some of the big reasons behind that demand:

  • Mobile devices with intermittent network connectivity that have "new mail" or "message count" indicators 📱.
  • Unified messaging systems that include both Internet and voice mail need support for a message-waiting indicator on phones ☎️.
  • Interaction with systems for event-based or utility-computing billing 💸.
  • Making it simpler to pass message store events to non-Internet notification systems 🔔.
  • A calendar system may want to subscribe to MessageNew notifications so it can support iMIP [RFC2447] 🗓️.
  • Some jurisdictions have laws or regulations for information protection and auditing. Those 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 been getting a lot of demand for notifications on more and more events 😭. So as a first step toward building a notification system, this doc lists the core events that real-world customers are asking for 🎯.

This document includes the events that can be generated by using IMAP4rev1 [RFC3501] and some existing extensions 🧩. As new IMAP extensions get defined, or new event types or parameters need to be added, the set specified here can be extended through an IANA registry with update requirements, as specified in Section 6 📋.

1.1. Conventions Used in This Document 🎀

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 [RFC2119]. When these words show up in lower-case or with initial capital letters, they are not RFC 2119 key words 🙈.

2. Terminology 📖

Here's the vocab for this doc, so we're all on the same page ✨.

mailbox: 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 📥.

mailbox identifier: A mailbox identifier gives you enough info to identify a specific mailbox on a specific server instance. An IMAP URL can be a mailbox identifier 🔑.

message access protocols: Protocols that give clients (like a mail user agent or web browser) access to the message store. That includes, but isn't limited to, IMAP, POP, and HTTP 🌈.

message context: As defined in [RFC3458] 🧠.

UIDVALIDITY: As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the correct operation of a caching mail client. When it changes, the client MUST flush its cache. It's especially important to include UIDVALIDITY with event notifications about message addition or removal, so the message data stays correctly synchronized 🚨.

3. Event Model 🧚

The events a message store generates depend somewhat on the model used to represent that store. The model the IETF has for a message store is implicit in IMAP4rev1 and its extensions, so this document assumes that same model 💜.

A message store event usually has an associated mailbox name, and it usually has an associated user name. If you're using SASL terminology, that's the authorization identity from "Simple Authentication and Security Layer" (SASL) [RFC4422] 🔐. Events about a specific message can point to it with an IMAP URL [RFC5092] 🔗. Events about a set of messages can use an IMAP URL to the mailbox, plus an IMAP UID (Unique Identifier) set 🫧.

Each notification has a type and parameters. The type tells you what kind of event it is, while the parameters give you context about the event 🎯. Those parameters can be used to adjust subscription preferences, or they can just be data attached to the event 📦. The types and parameter names in this doc are limited to US-ASCII printable characters, so these events can be easily mapped to an arbitrary notification system 🗺️. The doc also assumes that arbitrary parameter values, including large and multi-line ones, can be encoded with the notification system. Systems that lack that feature could only implement a subset of these events 🥺.

This document does not say which event parameters are mandatory or optional. That's handled in documents that specify particular message formats or bindings to a notification system 📝.

For scalability reasons, some filtering at event generation is necessary 📉. At the very least, you need the ability to turn on and off groups of related events, and to suppress the inclusion of large parameters (like messageContent) 🚫. A sophisticated publish/subscribe notification system may be able to propagate cumulative subscription information to the publisher 🌸.

Some of these events could logically be collapsed into a single event type with a required parameter that tells the cases apart, for example QuotaExceed and QuotaWithin 🤓. But until an event subscription model gets formulated, it's not practical to make those decisions. So for now, this doc just notes the fact that some of these events may be viewed as a single event type 🤷‍♀️.

4. Event Types 💅

This section talks about the different types of events that are useful in a message store event notification system. The goal is to document enough events to cover an overwhelming majority of known use cases, while leaving the less common event types for the future 🔮. This section also mentions parameters that are important or specific to the events described here. Event parameters that are likely to be included in most or all notifications get covered in the next section 💖.

4.1. Message Addition and Deletion 📬✨

okay so this section is all about the events for messages getting added or deleted, and yes I'm obsessed 💅

MessageAppend 🦋

okay so this one fires when a message gets appended or concatenated into a mailbox by a message access client. honestly it's giving MessageNew but with one twist: the SMTP envelope info is NOT a parameter here 🙈 but info about which protocol triggered the event MAY be included. go check MessageNew for the rest, it's iconic 💖

MessageExpire 🍓

this one happens when one or more messages get expired from a mailbox because of the server's expiration policy, and the end user can't reach them anymore 😭

the parameters include a mailbox identifier that MUST include UIDVALIDITY, plus a UID set that describes the messages. no cap, that MUST is non-negotiable 🫶

info about which server expiration policy got applied MAY be included in the future, so stay tuned 🔮

MessageExpunge 🧹

this is when one or more messages get expunged from a mailbox through an IMAP CLOSE/EXPUNGE, a POP3 DELE+QUIT, HTTP, or some equivalent client action, and the end user can't access them anymore. bye bye 👋

the parameters include a mailbox identifier that MUST include UIDVALIDITY, a UID set, and they MAY also indicate which access protocol triggered the event 🌸

MessageNew 💌

a new message got received into a mailbox through a message delivery agent. literally the main character moment of this whole section ✨

the parameters include a message identifier that, for IMAP-accessible message stores, MUST include UIDVALIDITY and a UID. the parameters MAY also include an SMTP envelope and other arbitrary message and mailbox metadata. 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 to include a URLAUTH [RFC4467] reference for larger messages. that's lowkey genius 🧠💜

QuotaExceed 🚫

an operation failed (usually a MessageNew) because the user's mailbox went over one of the quotas, like disk quota, message quota, quota by message context, and so on. ugh, rude 😤

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 aren't described in this document yet, but they could be added in the future 🌈

QuotaWithin 🎉

an operation happened (usually MessageExpunge or MessageExpire) that brought the user's quota usage back under the limit. we love a comeback 🙌

QuotaChange 🔄

the user's quota was changed. that's it, that's the event 🫠

4.2. Message Flags 🏳️‍🌈

this section is all about events for changes in message flags, so let's get into it 💅

MessageRead 👀

one or more messages in the mailbox got marked as read or seen by a user. quick note: POP has no concept of read or seen messages, so these events only get generated by IMAP or HTTP clients (or equivalent) 🙅‍♀️

the parameters include a mailbox identifier and a set of message UIDs.

MessageTrash 🗑️

one or more messages got marked for future deletion by the user, but they're still accessible over the protocol. whether the user's client makes them accessible through its UI is up to the client, so it may or may not 🤷‍♀️

the parameters include a mailbox identifier and a set of message UIDs.

FlagsSet 🚩

one or more messages in the mailbox had one or more IMAP flags or keywords set.

the parameters include a list of IMAP flag or keyword names that were set, a mailbox identifier, and the set of UIDs of affected messages. the flagNames parameter 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 🎀

FlagsClear 🧼

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 the set of UIDs of affected messages. the flagNames parameter MUST NOT include \Recent 🚫

4.3. Access Accounting 🎟️

this section lists events related to message store access accounting. the paper trail era 📝

Login 🔑

a user logged into the system via IMAP, HTTP, POP, or some other mechanism. slay 💖

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 it's different from the authorization identity), the service name, the authentication mechanism, info about any negotiated security layers, a timestamp, and other stuff 🧚

Logout 👋

a user logged out or otherwise got 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 info from the "Login" event, plus info about the type of disconnect (suggested values include graceful, abort, timeout, and security layer error), the duration of the connection or session, and other info 💜

4.4. Mailbox Management 📁

this section lists events related to managing mailboxes, aka the organizational queen era 👑

MailboxCreate 🌱

a mailbox got created, or an access control changed on an existing mailbox so it's now accessible by the user. if creating a mailbox caused new mailboxes earlier in the hierarchy to be created, separate MailboxCreate events are NOT generated, since their creation is implied 🙈

the parameters include the created mailbox identifier, its UIDVALIDITY for IMAP-accessible message stores, and they MAY also indicate which access protocol triggered the event. access and permissions info (like Access Control List (ACL) [RFC4314] settings) needs a standardized format before it can be included, so it's left for future extension 🔮

MailboxDelete 💥

a mailbox got deleted, or an access control changed on an existing mailbox so it's no longer accessible by the user. note that if the mailbox has child mailboxes, only the specified mailbox got deleted, not the children. the mailbox becomes \NOSELECT, and the hierarchy stays unchanged, as described for the DELETE command in IMAP4rev1 [RFC3501] 🫣

the parameters include the deleted mailbox identifier and MAY also indicate which access protocol triggered the event.

MailboxRename ✏️

a mailbox got renamed. okay so per the description of the RENAME command in IMAP4rev1 [RFC3501], special rules for the mailbox hierarchy apply when INBOX is renamed. child mailboxes are usually included in the rename, but they're excluded when INBOX is renamed 🧐

when a mailbox other than INBOX gets renamed and its child mailboxes get renamed too, separate MailboxRename events are NOT generated for the children, since their renaming is implied. if the rename caused new mailboxes to be created earlier in the hierarchy, separate MailboxCreate events are NOT generated for those either, since 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's implied 🌸

the parameters include the old mailbox identifier, the new mailbox identifier, and they MAY also indicate which access protocol triggered the event.

MailboxSubscribe 📌

a mailbox got added to the server-stored subscription list, like the one managed by the IMAP SUBSCRIBE and UNSUBSCRIBE commands.

the parameters include the user whose subscription list was affected, the mailbox identifier, and they MAY also indicate which access protocol triggered the event 💖

MailboxUnSubscribe 🚪

a mailbox got removed from the subscription list. bye, mailbox 🫶

the parameters include the user whose subscription list was affected, the mailbox identifier, and they MAY also indicate which access protocol triggered the event.

5. Event Parameters ✨

okay bestie, this is the parameter section 🎀 Every event can come with extra info attached, and these are the names for all that info. Let's go through them one by one 💅

admin 👑 Included with all events generated by message access protocols. This is the authentication identity tied to the event, which is not the same thing as the authorization identity (that's user, see below). If it's the same as the user value, it doesn't get included, because why repeat yourself 🙄

bodyStructure 🧚 May be included with MessageAppend and MessageNew. This is the IMAP BODYSTRUCTURE of the message 🦋

clientIP 🌸 Included with all events generated by message access protocols. This is the IPv4 or IPv6 address of the message store access client that did the thing that set off the notification 👀

clientPort 💜 Included with all events generated by message access protocols. This is the port number of that same client, the port the connection came in from 🔌

diskQuota 🍓 Included with QuotaExceed, QuotaWithin, and QuotaChange notifications about a user or mailbox disk quota. It may also show up with other notifications. The value is the disk quota limit in kilobytes, where a kilobyte is 1024 octets 📏

diskUsed ✨ Included with QuotaExceed and QuotaWithin notifications about a user or mailbox disk quota. It may also show up with other notifications. The value is the disk space used in kilobytes (1024 octets each). Only the space that counts against the quota gets included, so no sneaky extras 🙅‍♀️

envelope 💌 May be included with the MessageNew notification. This is the message transfer envelope that was used for the final delivery of the message. It has the MAIL FROM and the relevant RCPT TO line(s) used for that delivery, with CRLF delimiters, plus any ESMTP parameters. Very detailed, very iconic 📮

flagNames 🏳️‍🌈 Included with FlagsSet and FlagsClear events. It may also be included with MessageAppend and MessageNew, to show which flags were set at the start by the APPEND command or the delivery agent, respectively. The value is a list (probably space-separated) of IMAP flag or keyword names that were set or cleared. Flag names start with a backslash, while keyword names don't. And the \Recent flag is explicitly not allowed in the list, so don't even try it 🚫

mailboxID 📬 Included in events that affect mailboxes. It's a URI describing the mailbox. For a MailboxRename, this points at the new name 🫶

maxMessages 🔢 Included with QuotaExceed and QuotaWithin notifications about a user or mailbox message count quota. It may also show up with other notifications. This is the quota limit on how many messages a mailbox can hold, for events that are about a mailbox 📦

messageContent 💅 May be included with MessageAppend and MessageNew. This is the entire message itself. Size-based suppression of this SHOULD be available, so you can keep the big stuff out when it's too chunky 🍰

messageSize 📏 May be included with MessageAppend and MessageNew. This is the size of the RFC 5322 message in octets. The value matches the length of the IMAP literal that comes back when you do an IMAP FETCH of BODY[] for the referenced message, so the numbers line up perfectly 🥰

messages 🧮 Included with QuotaExceed and QuotaWithin notifications about a user or mailbox message count quota. It may also show up with other notifications. This is the number of messages in the mailbox, and it's usually included with message addition and deletion events ➕➖

modseq 🔐 May be included with any notification that's about one message. This is the 64-bit integer MODSEQ defined in [RFC4551]. If it's left out, you can't make any assumptions about MODSEQ, so don't guess, bestie 🙈

oldMailboxID 🦋 This is a URI describing the old name of a mailbox that got renamed or moved 🧳

pid 🔥 May be included with any notification. This is the process ID of the process that made the notification 🆔

process 🌈 May be included with any notification. This is the name of the process that made the notification 🏷️

serverDomain 🌍 Included in Login and optionally in Logout or other events. This is the domain name, or the IP address (v4 or v6), used to reach the server or mailbox 🗺️

serverPort 🚪 Included in Login and optionally in Logout or other events. This is the port number used to reach the server. It's often a well-known port, so you can usually guess it 😌

serverFQDN 🎯 May be included with any notification. This is the fully qualified domain name of the server that made the event. Heads up, it can be different from the server name used to reach the mailbox, which is the one in the mailbox identifier 👯

service 🧚‍♀️ May be included with any notification. This is the name of the service that set off the event. Suggested values are "imap", "pop", "http", and "admincli" (for an administrative client) 🛠️

tags 🏷️ May be included with any notification. This is a list of UTF-8 tags (probably comma-separated). You can set one or more tags when you make a notification criteria or notification subscription. Subscribers can use tags for extra client-side filtering or dispatch of events, which is super handy 🗂️

timestamp ⏰ May be included with any notification. This is when the event that set off the notification happened. (The protocol carrying the notification might have its own timestamp for when the notification got generated, too.) This MAY be an approximate time, so it's not always exact 🫠

Timestamps are written in local time and include the offset from UTC. That bit is used in several places in Internet mail. They're normally in [RFC3339] format, so the time zone drama is handled 🌏

uidnext 🔜 May be included with any notification that's about a mailbox. This is the UID that's projected to be assigned next in the mailbox. It's usually included with message addition and deletion events. It's the same thing as the UIDNEXT status item in the IMAP STATUS command 🪄

uidset 🧾 Included with MessageExpires, MessageExpunges, MessageRead, MessageTrash, FlagsSet, and FlagsClear. This is the set of IMAP UIDs that get referenced 🔢

uri 🔗 Included with all notifications. This is a reference to the IMAP server, a mailbox, or a message. It's typically an IMAP URL, and it can include the name of the server used to reach the mailbox or message, the mailbox name, the UIDVALIDITY of the mailbox, and the UID of a specific message. Basically everything you need to find it 🗺️✨

user 👸 Included with all events generated by message access protocols. This is the authorization identifier that the client used when it connected to the access protocol that set off the event. Some protocols (like many SASL mechanisms) tell authorization and authentication identifiers apart. For events tied to a mailbox, this can be different from the owner of the mailbox in the IMAP URL, so don't assume they match 🧐

6. IANA Considerations 🗂️

Okay, so IANA has made a brand-new registry for "Internet Message Store Events" 🎉 It has two sub-registries, one for event names and one for event parameters. For both of them, entries that don't start with "vnd." get added by the IETF and are meant for interoperable use. Entries that do start with "vnd." are meant for private use by one or more parties, and they get allocated so nobody collides 🤝

The initial values are in this document, so you can find them right here 📖

If we speak in [RFC5226] terms (the IANA Considerations guidelines), entries that don't start with "vnd." are allocated by IETF Consensus, while the "vnd." ones are allocated First Come First Served. It's giving organised 📋💖

7. Security Considerations 💀

Okay, this section is serious, so buckle up 😭 Notifications can create a lot of traffic and can expose sensitive information. When notification mechanisms are used to keep state in sync between different entities, the ability to corrupt or manipulate notification messages could let an attacker change the state of those entities. For example, if an attacker could modify notifications sent from a message store to an auditing server, they could change the "user" and "messageContent" parameters in MessageNew notifications and create false audit log entries. Yikes 🚨

A competent transfer protocol for notifications must consider authentication, authorization, privacy, and message integrity, as well as denial-of-service issues. The IETF has solid tools and experience for these issues when a mechanism only involves one TCP connection. But notification or publish/subscribe protocols that are more sophisticated than a single end-to-end TCP connection will need to pay extra attention to these issues. They also need to carefully balance their requirements so they can deploy a system that handles the security and privacy considerations properly 🔐🫶

8. Acknowledgments 🌷

Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh reviewed this document and offered improvements. Richard Barnes also did a lovely review during Last Call 💖 Thank you, legends ✨

9. References 📚

9.1. Normative References 💜

Here are the normative references, with all their details:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
           4rev1", RFC 3501, March 2003.

[RFC5092]  Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
           November 2007.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

9.2. Informative References 🦋

And here are the informative ones, the extra reading for when you want to go deeper 🧠

[RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
           STD 53, RFC 1939, May 1996.

[RFC2177]  Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.

[RFC2447]  Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
           Message-Based Interoperability Protocol (iMIP)", RFC 2447,
           November 1998.

[RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
           Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
           Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
           Internet: Timestamps", RFC 3339, July 2002.

[RFC3458]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
           Context for Internet Mail", RFC 3458, January 2003.

[RFC4146]  Gellens, R., "Simple New Mail Notification", RFC 4146,
           August 2005.

[RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
           RFC 4314, December 2005.

[RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
           Security Layer (SASL)", RFC 4422, June 2006.

[RFC4467]  Crispin, M., "Internet Message Access Protocol (IMAP) -
           URLAUTH Extension", RFC 4467, May 2006.

[RFC4551]  Melnikov, A. and S. Hole, "IMAP Extension for Conditional
           STORE Operation or Quick Flag Changes Resynchronization",
           RFC 4551, June 2006.

[RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
           October 2008.

Appendix A. Future Extensions 🔮

okay so this is the "not yet, bestie" section 💅 the spec only includes events that are well understood, have real use cases, and are actually running in at least one deployed real-world Internet message store 🫶 ... the exceptions are FlagsSet, FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, MailboxSubscribe, and MailboxUnSubscribe, which skip only that last test 🎀

Some events were suggested but got postponed to future extensions because they don't meet those criteria 🥺 these include messages moved to archive storage (which may take 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 also mention extra parameters that are likely candidates for future inclusion ✨ if you want to know how the list of events and parameters can be extended, check out Section 6 💖

Also, to keep the scope small enough to actually finish 🏁, only events generated from the message store are considered (by a message access module, an administrative module, or a message delivery agent) 🌸 a full mail system is normally linked with an identity system that would also publish events of interest to a message store event subscriber, like account created/deleted/disabled and password changed/expired 👑 those are not in scope here, but they're giving very real-world energy 💀

Authors' Addresses 🦋

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA  92651
USA

Phone:
EMail: rg+ietf@qualcomm.com


Chris Newman
Sun Microsystems
800 Royal Oaks
Monrovia, CA  91016-6347
USA

Phone:
EMail: chris.newman@sun.com
📦 where this page comes from