Internet Message Access Protocol (IMAP) - SAVEDATE Extension
Extracted elements (15)
The save date attribute was introduced because the existing internal date attribute can be set to an arbitrary value for messages delivered via APPEND and is usually copied from the source for COPY, making it unreliable for determining when a message arrived in its current mailbox. A concrete use case is expiring messages in a Trash mailbox: internal date reflects original receipt time, not when the user moved the message to Trash.
The SAVEDATESUPPORTED search key is the mechanism for clients to detect per-mailbox save date support at search time. Mailboxes whose underlying storage does not support save date will silently fall back to internal date for date-range search keys, which clients must account for when interpreting results.
Unlike the internal date attribute, the save date is not copied during IMAP COPY (RFC 3501) or MOVE (RFC 6851) operations; each copy of a message in a different mailbox receives an independent save date reflecting its own delivery time to that mailbox.
IMAP servers that support this extension MUST include "SAVEDATE" in the response list to the CAPABILITY command.
In the context of the IMAP Multimailbox SEARCH Extension (RFC 7377), the fallback from save date to internal date MUST apply to each mailbox individually, so only mailboxes lacking save date support use internal date.
Once calculated, the save date attribute MUST NOT change as long as the message is contained within the same mailbox. Copying or moving the message to another mailbox always results in a new save date in the destination; the source copy's save date remains unaffected.
The current date and time at which a message is delivered to a mailbox MUST be used to set the save date attribute, irrespective of the delivery command (APPEND, COPY, or MOVE) or the message's origin.
When the underlying storage of a mailbox does not support the save date attribute, the SAVEDBEFORE, SAVEDON, and SAVEDSINCE search keys MUST use the internal date attribute instead as a fallback.
A new FETCH data item "SAVEDATE" is defined for the FETCH command, allowing clients to retrieve the save date of a message.
Four new SEARCH command keys are defined: SAVEDBEFORE <date> (save date earlier than specified date), SAVEDON <date> (save date within specified date), SAVEDSINCE <date> (save date on or after specified date), and SAVEDATESUPPORTED (matches all messages when storage supports save date; matches none when not supported).
The FETCH response includes a "SAVEDATE" data item containing a date-time string representing the save date of the message. If the underlying mailbox storage does not support the save date attribute, the value returned is always NIL rather than a string.
The save date message attribute is the date and time at which a message was saved in the mailbox it currently resides in. It is always set to the moment of delivery to the mailbox, regardless of the delivery mechanism (APPEND, COPY, or MOVE), and cannot be set arbitrarily.
IANA added "SAVEDATE" to the existing "IMAP Capabilities" registry. No new registry is created by this document.
There are no known additional security issues introduced by the SAVEDATE extension beyond those described in the base IMAP protocol (RFC 3501).
The SAVEDATE fetch response item is encoded as: "SAVEDATE" SP (date-time / nil), where date-time follows the IMAP date-time format (e.g., "01-Jan-2015 18:50:53 +0100") and nil indicates no save date support in the underlying storage.