| Internet-Draft | Abbreviated Title | September 2024 |
| Lanov | Expires 23 March 2025 | [Page] |
This document proposes extensions to the SMTP, IMAP, POP3, and MIME protocols to introduce a standard mechanism for email retention period management.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 March 2025.¶
Copyright (c) 2024 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 (https://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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Email protocols such as SMTP [RFC5321], IMAP [RFC9051], POP3 [RFC1939], and MIME [RFC2045] 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 [RFC2156] and [I-D.ietf-mailmaint-expires] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
Example of SMTP Retention Header¶
Retention: Sun, 15 Sep 2024 12:00:00 GMT¶
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 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.¶
A new IMAP command, FETCH RETENTION, allows clients to query the retention period.¶
Example of IMAP FETCH RETENTION command¶
Client requests: A001 FETCH 1 (RETENTION) Server responds: * 1 FETCH (RETENTION "Sun, 15 Sep 2024 12:00:00 GMT")¶
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.¶
The X-RETENTION command is introduced for POP3 servers to support retention period retrieval.¶
The X-RETENTION command allows POP3 clients to request the retention period for a message.¶
Example of POP3 X-RETENTION command¶
Client requests: X-RETENTION 1 Server responds: +OK Retention date: Sun, 15 Sep 2024 12:00:00 GMT¶
POP3 servers MUST delete or archive messages that have exceeded their retention period and SHOULD notify clients of this status.¶
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.¶
Example of MIME Retention Header¶
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Retention: Sun, 15 Sep 2024 12:00:00 GMT¶
Clients and servers MUST enforce the removal of content based on the Retention header.¶
This document requests IANA register the Retention header for MIME and the SMTP RETENTION extension in the appropriate registries.¶
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.¶