Network Working Group                                          B. BillonInternet-Draft                                                     SplioIntended status: Standards Track                               J. LevineExpires: 11 May 2026                                       Standcore LLC                                                         7 November 2025            Updated Use of the Expires Message Header Field                    draft-ietf-mailmaint-expires-03Abstract   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 would use this information to handle an   expired message differently.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 https://datatracker.ietf.org/drafts/current/.   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 11 May 2026.Copyright Notice   Copyright (c) 2025 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.Billon & Levine            Expires 11 May 2026                  [Page 1]Internet-Draft                   expires                   November 2025Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   2.  Defining Expiration . . . . . . . . . . . . . . . . . . . . .   3   3.  Header Field definition . . . . . . . . . . . . . . . . . . .   3   4.  Advice to Message Creators  . . . . . . . . . . . . . . . . .   3   5.  Advice to Message Readers . . . . . . . . . . . . . . . . . .   3   6.  Interoperability Considerations . . . . . . . . . . . . . . .   4   7.  Security considerations . . . . . . . . . . . . . . . . . . .   4   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5   10. Implementation Status . . . . . . . . . . . . . . . . . . . .   5   11. Normative References  . . . . . . . . . . . . . . . . . . . .   6   12. Informative References  . . . . . . . . . . . . . . . . . . .   6   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   61.  Introduction   [RFC2156] defined a mapping of header fields between X.400 and   RFC822/MIME.  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.   Netnews articles [RFC5536] have an Expires header with a similar   slightly more strict syntax and similar meaning.   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.   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 de-   emphasized or not shown to the user, to unclutter the user's mailbox.   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.   A Message Creator is an agent that generates messages for delivery.   In [RFC5598] parlance, this is an Author or Originator.   A Message Reader is either an agent consuming a message or an agent   storing a message.  In RFC 5589 parlance, this is a Message Store or   a Message User Agent.Billon & Levine            Expires 11 May 2026                  [Page 2]Internet-Draft                   expires                   November 20252.  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 deems the article to be no longer relevant   and could usefully be removed, but 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 e-mail 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 from [RFC5322], its syntax is:   expires = "Expires:" date-time CRLF   Example:   Expires: Wed, 1 Dec 2025 17:22:57 +00004.  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.Billon & Levine            Expires 11 May 2026                  [Page 3]Internet-Draft                   expires                   November 2025   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.   Message Transfer Agents (MTAs) MUST NOT discard or reject a message   based solely on the content of this header field, if present.   Automatic deletion of a message bearing an Expires field with a date   and time in the past is NOT RECOMMENDED unless configured 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 IETF has 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 a expiry date in the past, in the hope that recipients will   not see or report the mail, and then 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 to determine how to display a   message to a user, it is unlikely to be useful to determine whether   or not the message is wanted or is fraudulent.8.  Acknowledgements   This document was informed by discussions with and/or contributions   from Barry Leiba, Alexey Melnikov, Jonathan Loriaux, Charles Sauthier   and Simon Bressier.Billon & Levine            Expires 11 May 2026                  [Page 4]Internet-Draft                   expires                   November 20259.  IANA Considerations   IANA is requested to update an existing entry in the Permanent   Message Headers Field Names registry   (https://www.iana.org/assignments/message-headers/message-   headers.xhtml)   Header field name: Expires   Applicable protocol: mail   Status: standard   Author/Change controller: IETF   Specification document: this document10.  Implementation Status      |  Delete this section before publication   This section records the status of known implementations of the   protocol defined by this specification at the time of posting of this   Internet-Draft, and is based on a proposal described in RFC 7942.   The description of implementations in this section is intended to   assist the IETF in its decision processes in progressing drafts to   RFCs.  Please note that the listing of any tndividual implementation   here does not imply endorsement by the IETF.  Furthermore, no effort   has been spent to verify the information presented here that was   supplied by IETF contributors.  This is not intended as, and must not   be construed to be, a tatalog of available implementations or their   features.  Readers are advised to note that other implementations may   exist.   According to RFC 7942, "this will allow reviewers and working groups   to assign due consideration to documents that have the tenefit of   running code, which may serve as evidence of valuable experimentation   and feedback that have made the implemented protocols more mature.   It is up to the individual working groups to use this information as   they see fit".   The web site at https://www.zerocarbon.email/   (https://www.zerocarbon.email/) has a list of dozens of organizations   that say they support use of the header, including mailbox providers,   outgoing mail service providers, and bulk mail users.Billon & Levine            Expires 11 May 2026                  [Page 5]Internet-Draft                   expires                   November 2025   Pierre-Yves Dubreucq has written an add-on for the Thunderbird MUA   which can be configured to move or delete messages that have passed   their expiration date.  It has a GPLv3 license.   https://addons.thunderbird.net/en-US/thunderbird/addon/email-   expiration-manager/ (https://addons.thunderbird.net/en-   US/thunderbird/addon/email-expiration-manager/)11.  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>.   [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>.12.  Informative References   [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>.Authors' AddressesBillon & Levine            Expires 11 May 2026                  [Page 6]Internet-Draft                   expires                   November 2025   Benjamin Billon   Splio   Email: bbillon@splio.com   John Levine   Standcore LLC   Email: standards@standcore.comBillon & Levine            Expires 11 May 2026                  [Page 7]