Splio

bbillon@splio.com

Standcore LLC

standards@standcore.com

ART mailmaint email This document allows broader use of the "Expires" message header field for mail messages. Message creators can then indicate when a message expires, while recipients can use this information to handle an expired message differently.

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 .

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 () 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

• .  Introduction
  • .  Requirements Language
• .  Defining Expiration
• .  Header Field Definition
• .  Advice to Message Creators
• .  Advice to Message Readers
• .  Interoperability Considerations
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction defined a mapping of header fields between the formats specified in X.400 and . 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. 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 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 , 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 , this is a Message Store or a Message User Agent.

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 when, and only when, they appear in all capitals, as shown here.

Defining Expiration defined a field called "Expires", which replaced "Expiry-Date" introduced in . It did not define the term further, except to say that no automatic handling past that date can be expected. 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.

Header Field Definition The header field definition remains the same as in and . It indicates the time at which a message loses its validity. Using the ABNF from , its syntax is: expires = "Expires:" date-time CRLF Example: Expires: Wed, 3 Dec 2025 17:22:57 +0000

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.

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.

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.

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.

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK] This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

Acknowledgements This document was informed by discussions with and/or contributions from , , , , and .

Authors' Addresses Splio

bbillon@splio.com

Standcore LLC

standards@standcore.com