Skip to main content

Updated Use of the Expires Message Header Field
draft-billon-expires-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Benjamin BILLON , John R. Levine
Last updated 2022-11-29 (Latest revision 2022-11-22)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd (None)
Shepherd write-up Show Last changed 2022-11-27
IESG IESG state In Last Call (ends 2022-12-27)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to (None)
IANA IANA review state IANA - Review Needed
draft-billon-expires-06
Network Working Group                                          B. Billon
Internet-Draft                                                     Splio
Intended status: Standards Track                               J. Levine
Expires: 26 May 2023                                       Standcore LLC
                                                        22 November 2022

            Updated Use of the Expires Message Header Field
                        draft-billon-expires-06

Abstract

   This document allows broader use of the Expires message header field
   for mail messages.  Message creators can then indicate when a message
   sent becomes valueless and can safely be deleted, while recipients
   would use the information to delete or ignore these valueless
   messages.

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 26 May 2023.

Copyright Notice

   Copyright (c) 2022 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 26 May 2023                  [Page 1]
Internet-Draft                   expires                   November 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Header Field example  . . . . . . . . . . . . . . . . . . . .   2
   3.  Security considerations . . . . . . . . . . . . . . . . . . .   3
   4.  Advice to Message Creators  . . . . . . . . . . . . . . . . .   3
   5.  Advice to Message Readers (Mailbox providers, Webmails and
           MUAs) . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   6.  Past History of the Expires: header field . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   10. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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
   deleted, in an attempt to unclutter the user's mailbox and spare
   storage resources.

   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.  Header Field example

   The header field definition and syntax remain the same as in
   [RFC4021], the time at which a message loses its validity.

   expires = "Expires" ":" date-time

   Example:

   Expires: Wed, 1 Dec 2021 17:22:57 +0000

   Message creators MUST NOT include more than one Expires header field
   in the message they send.

   If there is more than one Expires header field then message readers
   SHOULD act as if no Expires header field is present.

Billon & Levine            Expires 26 May 2023                  [Page 2]
Internet-Draft                   expires                   November 2022

3.  Security considerations

   Dates in this header field can be set a long way in the past or in
   the future, including outside the range of internal time
   representations in some programming environments - all software which
   processes the Expires header field MUST be made safe against this
   possibility.

4.  Advice to Message Creators

   Message creators add the header field along with a relevant date and
   time when they know that the content of the message has no value
   after a given point of time.  This could apply to commercial
   newsletters, that include time-limited offers, event announcements,
   social notifications, or Time-limited access codes.

5.  Advice to Message Readers (Mailbox providers, Webmails and MUAs)

   The expiration of a message's validity would logically lead to the
   deletion of the message.  However, users on most systems do not
   expect their emails to disappear, and may not be aware that any
   particular email has an Expires header field.  Therefore, no email
   should be silently and automatically deleted solely based on the
   value of the Expires header field.

   Mailbox providers could indicate when a user is viewing an expired
   message, and could allow users to control over the actions to take
   for expired messages.

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

   In certain cases, email messages can be used as an element of an
   investigation.  An early deletion may compromise an investigation, so
   mailbox providers could ignore the Expires information in such cases.

   Presence of the Expires header field MUST NOT be interpreted as a
   sign that a message is legitimate.

Billon & Levine            Expires 26 May 2023                  [Page 3]
Internet-Draft                   expires                   November 2022

6.  Past History of the Expires: header field

   [RFC4021] defines a number of header fields that can be added to
   Internet messages including those used for mapping between X.400 and
   RFC822/MIME [RFC2156].  One of them is the Expires header field that
   provides the date and time at which a message is considered to lose
   its validity.

   The same principle can be applied to the Expires header field in
   general, whether the message comes from a X.400 gateway as initially
   intended in [RFC2156], or elsewhere.

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

7.  Acknowledgements

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

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

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

Billon & Levine            Expires 26 May 2023                  [Page 4]
Internet-Draft                   expires                   November 2022

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

10.  Informative References

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

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

Authors' Addresses

   Benjamin Billon
   Splio
   Email: bbillon@splio.com

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Billon & Levine            Expires 26 May 2023                  [Page 5]