Network Working Group B. Billon Internet-Draft Splio Intended status: Standards Track J. Levine Expires: 16 October 2022 Standcore LLC 14 April 2022 Updated Use of the Expires Message Header Field draft-billon-expires-03 Abstract This document allows broader use of the Expires message header field for SMTP. Senders can then indicate when a message sent becomes valueless and can safely be deleted, while recipients would use the information to delete 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 16 October 2022. 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 16 October 2022 [Page 1] Internet-Draft expires April 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Header Field example . . . . . . . . . . . . . . . . . . . . 2 3. Security considerations . . . . . . . . . . . . . . . . . . . 3 4. Advice to Senders . . . . . . . . . . . . . . . . . . . . . . 3 5. Advice to Receivers (Mailbox providers, Webmails and MUAs) . 3 6. Past History of the Expires: header . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 10. Informative References . . . . . . . . . . . . . . . . . . . 4 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 field definition and syntax remain the same. expires = "Expires" ":" date-time Example: Expires: Wed, 1 Dec 2021 17:22:57 +0000 Senders MUST NOT include more than one Expires header in the message they send. If there is more than one Expires header then receivers SHOULD treat this as if no Expires header is present. Billon & Levine Expires 16 October 2022 [Page 2] Internet-Draft expires April 2022 3. Security considerations Dates in this header 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 MUST be made safe against this possibility. 4. Advice to Senders Senders SHOULD 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 (e.g. Commercial newsletters --especially when including time-limited offers, Event announcements, Social notifications, Time-limited access codes ...). In all other cases, senders SHOULD NOT set an Expires header. 5. Advice to Receivers (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. Therefore, no email should be silently and automatically deleted solely based on the value of the Expires header field. Mailbox providers SHOULD explain to users how the information provided in the Expires header are processed, SHOULD indicate when viewing an expired message, and SHOULD give users control over the actions to take for expired messages. The information provided in the header should 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 users to set up an automatic rule to clean up expired email from specific senders or with specific characteristics, or provide a mode to quickly view and process all expired email. In certain cases, email messages can be used as proof or element of investigation. As an early deletion may compromise the intended investigation, mailbox providers can ignore the Expires information in such cases. Presence of the Expires header field MUST NOT be interpreted as a sign of legitimacy. Billon & Levine Expires 16 October 2022 [Page 3] Internet-Draft expires April 2022 6. Past History of the Expires: header [RFC4021] defines a number of header fields that can be added to Internet messages such as 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 a SMTP context, whether the message comes from a X.400 gateway as initially intended in [RFC2156], or from a RFC821/SMTP MTA. 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 [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, . 10. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Billon & Levine Expires 16 October 2022 [Page 4] Internet-Draft expires April 2022 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Benjamin Billon Splio Email: bbillon@splio.com John Levine Standcore LLC Email: standards@standcore.com Billon & Levine Expires 16 October 2022 [Page 5]