Internet-Draft expires November 2022
Billon & Levine Expires 26 May 2023 [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 for mail messages. Message creators can then indicate when a message sent becomes valueless and can safely be deleted, while recipients would use the information to delete or ignore these valueless messages.

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 26 May 2023.

Table of Contents

1. Introduction

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 header field definition and syntax remain the same as in [RFC4021], the time at which a message loses its validity.

expires = "Expires" ":" date-time


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

Message creators MUST NOT include more than one Expires header field in the message they send.

If there is more than one Expires header field then message readers SHOULD act as if no Expires header field is present.

3. Security considerations

Dates in this header field can be set a long way in the past or in the future, including outside the range of internal time representations in some programming environments - all software which processes the Expires header field MUST be made safe against this possibility.

4. Advice to Message Creators

Message creators add the header field along with a relevant date and time when they know that the content of the message has no value after a given point of time. This could apply to commercial newsletters, that include time-limited offers, event announcements, social notifications, or Time-limited access codes.

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

The expiration of a message's validity would logically lead to the deletion of the message. However, users on most systems do not expect their emails to disappear, and may not be aware that any particular email has an Expires header field. Therefore, no email should be silently and automatically deleted solely based on the value of the Expires header field.

Mailbox providers could indicate when a user is viewing an expired message, and could allow users to control over the actions to take for expired messages.

The information provided in the header field is intended to be used as a signal that could be used to provide a feature or improved experience to the end-user. For instance, systems may allow automatic rules to clean up expired email from specific message creators or with defined characteristics, or to provide a mode to quickly handle all expired email.

In certain cases, email messages can be used as an element of an investigation. An early deletion may compromise an investigation, so mailbox providers could ignore the Expires information in such cases.

Presence of the Expires header field MUST NOT be interpreted as a sign that a message is legitimate.

6. Past History of the Expires: header field

[RFC4021] defines a number of header fields that can be added to Internet messages including 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 general, whether the message comes from a X.400 gateway as initially intended in [RFC2156], or elsewhere.

Netnews articles [RFC5536] have an Expires header with a similar slightly more strict syntax and similar meaning.

7. Acknowledgements

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

8. IANA Considerations

IANA is requested to update an existing entry in the Permanent Message Headers Field Names registry

Header field name: Expires

Applicable protocol: mail

Status: standard

Author/Change controller: IETF

Specification document: this document

9. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, DOI 10.17487/RFC2156, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

10. Informative References

Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, , <>.
Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, DOI 10.17487/RFC5536, , <>.

Authors' Addresses

Benjamin Billon
John Levine
Standcore LLC