Email Retention Extensions
draft-lanov-email-retention-period-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Dennis Lanov | ||
| Last updated | 2024-09-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lanov-email-retention-period-00
Internet Engineering Task Force D. Lanov, Ed.
Internet-Draft Cisco Systems
Intended status: Informational 19 September 2024
Expires: 23 March 2025
Email Retention Extensions
draft-lanov-email-retention-period-00
Abstract
This document proposes extensions to the SMTP, IMAP, POP3, and MIME
protocols to introduce a standard mechanism for email retention
period management.
Status of This Memo
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 Notice
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.
Lanov Expires 23 March 2025 [Page 1]
Internet-Draft Abbreviated Title September 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SMTP Retention Period Header . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SMTP Retention Header Format . . . . . . . . . . . . . . 3
2.3. SMTP Extension Definition . . . . . . . . . . . . . . . . 3
3. IMAP Retention Period Command . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. IMAP Command . . . . . . . . . . . . . . . . . . . . . . 3
3.3. IMAP Server Behavior . . . . . . . . . . . . . . . . . . 4
4. POP3 Retention Period Command . . . . . . . . . . . . . . . . 4
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. POP3 Command . . . . . . . . . . . . . . . . . . . . . . 4
4.3. POP3 Server Behavior . . . . . . . . . . . . . . . . . . 4
5. MIME Retention Period Header . . . . . . . . . . . . . . . . 4
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. MIME Header Extension . . . . . . . . . . . . . . . . . . 4
5.3. MIME Processing Behavior . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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.
Lanov Expires 23 March 2025 [Page 2]
Internet-Draft Abbreviated Title September 2024
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SMTP Retention Period Header
2.1. 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.
2.2. SMTP Retention Header Format
Example of SMTP Retention Header
Retention: Sun, 15 Sep 2024 12:00:00 GMT
2.3. 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.
3. IMAP Retention Period Command
3.1. 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.
3.2. IMAP Command
A new IMAP command, FETCH RETENTION, allows clients to query the
retention period.
Example of IMAP FETCH RETENTION command
Lanov Expires 23 March 2025 [Page 3]
Internet-Draft Abbreviated Title September 2024
Client requests: A001 FETCH 1 (RETENTION)
Server responds:
* 1 FETCH (RETENTION "Sun, 15 Sep 2024 12:00:00 GMT")
3.3. 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.
4. POP3 Retention Period Command
4.1. Overview
The X-RETENTION command is introduced for POP3 servers to support
retention period retrieval.
4.2. POP3 Command
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
4.3. POP3 Server Behavior
POP3 servers MUST delete or archive messages that have exceeded their
retention period and SHOULD notify clients of this status.
5. MIME Retention Period Header
5.1. 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.
5.2. MIME Header Extension
Example of MIME Retention Header
Lanov Expires 23 March 2025 [Page 4]
Internet-Draft Abbreviated Title September 2024
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Retention: Sun, 15 Sep 2024 12:00:00 GMT
5.3. MIME Processing Behavior
Clients and servers MUST enforce the removal of content based on the
Retention header.
6. IANA Considerations
This document requests IANA register the Retention header for MIME
and the SMTP RETENTION extension in the appropriate registries.
7. 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.
8. References
8.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/info/rfc1939>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
Lanov Expires 23 March 2025 [Page 5]
Internet-Draft Abbreviated Title September 2024
[I-D.ietf-mailmaint-expires]
BILLON, B. and J. R. Levine, "Updated Use of the Expires
Message Header Field", Work in Progress, Internet-Draft,
draft-ietf-mailmaint-expires-00, 12 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
mailmaint-expires-00>.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156,
DOI 10.17487/RFC2156, January 1998,
<https://www.rfc-editor.org/info/rfc2156>.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address
Dennis Lanov (editor)
Cisco Systems
Email: dennis.lanov@gmail.com
Lanov Expires 23 March 2025 [Page 6]