Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10080.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

[RFC2156] defined a mapping of header fields between the formats specified in X.400 and [RFC822]. One of the mapped fields is the "Expires" header field, which provides a date and time at which a message is considered to lose its validity.¶

[RFC4021] registered the field with IANA but stated that it is "not for general use." This document extends the use of the "Expires" header field to Internet email in general, whether the message comes from an X.400 gateway or elsewhere.¶

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

The date and time of expiration can be used by the mailbox provider or the MUA (Mail User Agent) to de-emphasize certain messages, or not display them at all, to unclutter the user's mailbox.¶

A Message Creator is an agent that generates messages for delivery. In the parlance of [RFC5598], this is an Author or Originator.¶

A Message Reader is either an agent consuming a message or an agent storing a message. In the parlance of [RFC5598], this is a Message Store or a Message User Agent.¶

2. Defining Expiration

[RFC2156] defined a field called "Expires", which replaced "Expiry-Date" introduced in [RFC1327]. It did not define the term further, except to say that no automatic handling past that date can be expected. [RFC5536] defined "Expires" for Netnews as a date and time beyond which the poster considers the article no longer relevant and thus suitable for removal; however, it did not actually require such removal. The consensus definition used in this document is that beyond the stated expiration date, the message "loses its validity".¶

The header field's use in email has been limited, with no formal semantic definition to date. No consensus exists to establish a more precise definition, in deference to existing implementations. Accordingly, no additional normative definition is provided here, nor is any requirement established for any particular handling by message readers.¶

3. Header Field Definition

The header field definition remains the same as in [RFC2156] and [RFC4021]. It indicates the time at which a message loses its validity. Using the ABNF [RFC5234] from [RFC5322], its syntax is:¶

expires = "Expires:" date-time CRLF

Example:¶

Expires: Wed, 3 Dec 2025 17:22:57 +0000¶

4. Advice to Message Creators

Message creators add the header field along with a relevant date and time when they know that the message loses its validity. This could apply to commercial newsletters that include time-limited offers, event announcements, social notifications, and periodic announcement messages.¶

Message creators MUST NOT include more than one "Expires" header field in a message.¶

5. Advice to Message Readers

Message readers, such as mailbox providers, web mail, and MUAs could de-emphasize the display of expired messages or not display them. They could allow users to control the actions to take for expired messages.¶

The information provided in the header field is intended to be used as a signal to provide an improved experience to the end user. For instance, systems might 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.¶

Mail software MUST NOT discard or reject a message based solely on the content of this header field, if present, and SHOULD NOT delete messages bearing an "Expires" field with a date and time in the past unless deliberately configured to do so by the mailbox owner.¶

6. Interoperability Considerations

As "Expires" has never been formally defined for Internet messages other than those translated from X.400, there might have been implementations that used this header field name in an incompatible way. Though the authors have never seen such a message, there is a theoretical risk of confusion.¶

7. Security Considerations

A message creator can put any date in an "Expires" header field, including dates in the distant past or future. Without further knowledge about the message creator, recipient systems and message readers cannot assume that the contents of the header are accurate or benign.¶

For example, a malicious message creator might send spam mail that includes an expiry date in the past, in the hope that recipients would not see or report the mail, and that adaptive spam filters would use it as non-spam training material. A creator might include a date in the immediate future in the hope that a recipient would see and act on a message but could not find it later to complain about it. Or, a creator might include a date in the distant future in the hope that the message would stay in a recipient's inbox and would be more likely to be read.¶

While the header field can be useful for determining how to display a message to a user, it is unlikely to be useful for determining whether the message is wanted or is fraudulent.¶

8. IANA Considerations

IANA has updated an existing entry in the "Permanent Message Headers Field Names" registry.¶

Header Field Name:

Expires¶

Protocol:

mail¶

Status:

standard¶

Author/Change Controller:

IETF¶

Trace:

no¶

Reference:

RFC 10080¶

Acknowledgements

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

Authors' Addresses