]> Cisco Systems

dennis.lanov@gmail.com

General Internet Engineering Task Force Email Expiration This document proposes extensions to the SMTP, IMAP, POP3, and MIME protocols to introduce a standard mechanism for email retention period management.

Introduction Email protocols such as SMTP , IMAP , POP3 , and MIME are widely used for the transmission, retrieval, and management of email messages. However, there is no native support for managing the retention period of emails across these protocols. This document introduces extensions that define a unified mechanism for setting and managing a retention period for email messages. The retention period defines a point in time after which the email message or its content should be removed or marked inaccessible. This proposal builds on previous work, such as and that extended the "Expires" header to email. However, our proposal goes further by specifying not only de-emphasizing or hiding messages but also enabling the automatic removal of email after the retention period, extending this capability to cover multiple protocols (SMTP, IMAP, POP3, MIME) and making it enforceable across servers and clients.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SMTP Retention Period Header

Overview An SMTP header, RETENTION, is introduced to specify the retention period for an email message at the time of sending. This enables the server to know when the message should be deleted or marked inaccessible after the defined retention period.

SMTP Retention Header Format Example of SMTP Retention Header

SMTP Extension Definition The client includes the Retention header during the MAIL FROM phase of SMTP. SMTP servers MUST respect this header and act upon the email when the retention period is reached by deleting or rendering it inaccessible. Servers not supporting this extension MAY ignore the Retention header, but SHOULD provide a notification of non-compliance.

IMAP Retention Period Command

Overview IMAP servers and clients need a mechanism to retrieve and act on email retention periods. The EXPIRE capability is added to IMAP, allowing clients to fetch retention information.

IMAP Command A new IMAP command, FETCH RETENTION, allows clients to query the retention period. Example of IMAP FETCH RETENTION command

IMAP Server Behavior IMAP servers MUST enforce retention periods, deleting or archiving messages as appropriate after the specified retention time. Servers SHOULD allow clients to query the retention status of a message and notify users when a message has expired.

POP3 Retention Period Command

Overview The X-RETENTION command is introduced for POP3 servers to support retention period retrieval.

POP3 Command The X-RETENTION command allows POP3 clients to request the retention period for a message. Example of POP3 X-RETENTION command

POP3 Server Behavior POP3 servers MUST delete or archive messages that have exceeded their retention period and SHOULD notify clients of this status.

MIME Retention Period Header

Overview To extend retention period management to multimedia content, a new MIME header, Retention, is introduced, which defines when email content (attachments, body text) should be removed or made inaccessible.

MIME Header Extension Example of MIME Retention Header

MIME Processing Behavior Clients and servers MUST enforce the removal of content based on the Retention header.

IANA Considerations This document requests IANA register the Retention header for MIME and the SMTP RETENTION extension in the appropriate registries.

Security Considerations The retention period introduces potential risks if critical messages are deleted prematurely. Implementers should ensure compliance with legal and regulatory requirements, such as data retention policies in healthcare (HIPAA) or financial sectors (SEC Rule 17a-4), and ensure appropriate handling of retention for sensitive data.

References Normative References This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK] This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] Splio Standcore LLC This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.