Skip to main content

Updated Use of the Expires Message Header Field
draft-ietf-mailmaint-expires-00

Document Type Active Internet-Draft (mailmaint WG)
Authors Benjamin BILLON , John R. Levine
Last updated 2024-09-24 (Latest revision 2024-08-12)
Replaces draft-billon-expires
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Feb 2025
WGLC on draft-ietf-mailmaint-expires
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to (None)
draft-ietf-mailmaint-expires-00
Network Working Group                                          B. Billon
Internet-Draft                                                     Splio
Intended status: Standards Track                               J. Levine
Expires: 13 February 2025                                  Standcore LLC
                                                          12 August 2024

            Updated Use of the Expires Message Header Field
                    draft-ietf-mailmaint-expires-00

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 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 13 February 2025.

Copyright Notice

   Copyright (c) 2024 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 13 February 2025                [Page 1]
Internet-Draft                   expires                     August 2024

Table 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 . . . . . . . . . . . . . . . . . .   4
   6.  Interoperability Considerations . . . . . . . . . . . . . . .   4
   7.  Security considerations . . . . . . . . . . . . . . . . . . .   4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   11. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  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 13 February 2025                [Page 2]
Internet-Draft                   expires                     August 2024

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 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 2024 17:22:57 +0000

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

   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.

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.

Billon & Levine         Expires 13 February 2025                [Page 3]
Internet-Draft                   expires                     August 2024

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.

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 13 February 2025                [Page 4]
Internet-Draft                   expires                     August 2024

9.  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 document

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

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

Billon & Levine         Expires 13 February 2025                [Page 5]
Internet-Draft                   expires                     August 2024

   [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' Addresses

   Benjamin Billon
   Splio
   Email: bbillon@splio.com

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Billon & Levine         Expires 13 February 2025                [Page 6]