Updated Use of the Expires Message Header Field

Internet Engineering Task Force (IETF)                         B. Billon
Request for Comments: 10080                                        Splio
Updates: 4021                                                  J. Levine
Category: Standards Track                                  Standcore LLC
ISSN: 2070-1721                                             October 2026


            Updated Use of the Expires Message Header Field

Abstract

   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
   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
     1.1.  Requirements Language
   2.  Defining Expiration
   3.  Header Field Definition
   4.  Advice to Message Creators
   5.  Advice to Message Readers
   6.  Interoperability Considerations
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

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.

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.  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 (https://www.iana.org/assignments/message-
   headers).

   Header Field Name:  Expires

   Protocol:  mail

   Status:  standard

   Author/Change Controller:  IETF

   Trace:  no

   Reference:  RFC 10080

9.  References

9.1.  Normative 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>.

   [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>.

   [RFC4021]  Klyne, G. and J. Palme, "Registration of Mail and MIME
              Header Fields", RFC 4021, DOI 10.17487/RFC4021, March
              2005, <https://www.rfc-editor.org/info/rfc4021>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [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>.

9.2.  Informative References

   [RFC822]   Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
              TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC822,
              August 1982, <https://www.rfc-editor.org/info/rfc822>.

   [RFC1327]  Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
              10021 and RFC 822", RFC 1327, DOI 10.17487/RFC1327, May
              1992, <https://www.rfc-editor.org/info/rfc1327>.

   [RFC5536]  Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
              Article Format", RFC 5536, DOI 10.17487/RFC5536, November
              2009, <https://www.rfc-editor.org/info/rfc5536>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <https://www.rfc-editor.org/info/rfc5598>.

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

   Benjamin Billon
   Splio
   Email: bbillon@splio.com


   John Levine
   Standcore LLC
   Email: standards@standcore.com