Internet-Draft expires December 2021
Billon & Levine Expires 17 June 2022 [Page]
Network Working Group
Intended Status:
Standards Track
B. Billon
J. Levine
Standcore LLC

Updated Use of the Expires Message Header Field


This document allows broader use of the Expires message header field. Senders can then indicate when a message sent becomes valueless and can safely be deleted.

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

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 17 June 2022.

Table of Contents

1. Introduction

[RFC4021] defines a number of header fields that can be added to Internet messages such as those used for mapping between X.400 and RFC822/MIME [RFC2156]. One of them is the Expires header field that provides the date and time at which a message is considered to lose its validity.

The same principle can be applied to the Expires header field in a SMTP context, whether the message comes from a X.400 gateway as initially intended in [RFC2156], or from a RFC821/SMTP MTA.

The date and time of expiration can be used by the mailbox provider or the MUA to indicate to the user that certain messages could be deleted, in an attempt to unclutter the user's mailbox and spare storage resources.

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. Header Field example

The field definition and syntax remain the same.

expires = "Expires" ":" date-time


Expires: Wed, 1 Dec 2021 17:22:57 +0000

There should be only one occurrence of the header field in a single message. The presence of more than one Expires header would make them void.

3. Security considerations

The expiration of a message's validity should lead to the deletion of the message. In certain cases, such as emails being used as proof or element of investigation, an early deletion may compromise the intended investigation. For this reason, we want to avoid the header field to be tempered with.

3.1. DKIM

Senders including the Expires header field MUST sign the message with DKIM [RFC6376] and include the field in the h= tag.

Receivers MUST NOT consider the value provided in the Expires header field if the DKIM check fails.

4. Implementation and Usage Consideration

4.1. Advice to senders

Senders SHOULD add the header field along with a relevant date and time whenever applicable.

Commercial newsletters are good candidates, especially when including time-limited offers.

Social notification and one-time-password emails SHOULD include the Expires header field, with an expiration set within a few days at most.

Payment receipts, bank statements, contracts and other emails that should be kept or archived by the recipient SHOULD NOT include the Expires header field.

5. Advice to Receivers (Mailbox providers, Webmails and MUAs)

Generally, no email should be automatically deleted solely based on the value of the Expires header field.

The information provided in the header should be used as a signal that could be used to provide a feature or improved experience to the end-user. Automation of email deletion based on the value of the Expires header may be set by the end-user.

Receivers can prevent deletion from happening if necessary.

Presence of the Expires header field MUST NOT be interpreted as a sign of legitimacy.

6. Acknowledgements

This document was informed by discussions with and/or contributions from Jonathan Loriaux, Charles Sauthier and Simon Bressier.

7. IANA Considerations

This document has no IANA actions.

8. Normative References

Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, DOI 10.17487/RFC2156, , <>.
Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, , <>.

9. Informative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

Authors' Addresses

Benjamin Billon
John Levine
Standcore LLC