idnits 2.17.1 draft-billon-expires-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 April 2022) is 743 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Billon 3 Internet-Draft Splio 4 Intended status: Standards Track J. Levine 5 Expires: 16 October 2022 Standcore LLC 6 14 April 2022 8 Updated Use of the Expires Message Header Field 9 draft-billon-expires-03 11 Abstract 13 This document allows broader use of the Expires message header field 14 for SMTP. Senders can then indicate when a message sent becomes 15 valueless and can safely be deleted, while recipients would use the 16 information to delete these valueless messages. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 16 October 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Header Field example . . . . . . . . . . . . . . . . . . . . 2 53 3. Security considerations . . . . . . . . . . . . . . . . . . . 3 54 4. Advice to Senders . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Advice to Receivers (Mailbox providers, Webmails and MUAs) . 3 56 6. Past History of the Expires: header . . . . . . . . . . . . . 4 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 60 10. Informative References . . . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The date and time of expiration can be used by the mailbox provider 66 or the MUA to indicate to the user that certain messages could be 67 deleted, in an attempt to unclutter the user's mailbox and spare 68 storage resources. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 72 "OPTIONAL" in this document are to be interpreted as described in BCP 73 14 [RFC2119] [RFC8174] when, and only when, they appear in all 74 capitals, as shown here. 76 2. Header Field example 78 The field definition and syntax remain the same. 80 expires = "Expires" ":" date-time 82 Example: 84 Expires: Wed, 1 Dec 2021 17:22:57 +0000 86 Senders MUST NOT include more than one Expires header in the message 87 they send. 89 If there is more than one Expires header then receivers SHOULD treat 90 this as if no Expires header is present. 92 3. Security considerations 94 Dates in this header can be set a long way in the past or in the 95 future, including outside the range of internal time representations 96 in some programming environments - all software which processes the 97 Expires header MUST be made safe against this possibility. 99 4. Advice to Senders 101 Senders SHOULD add the header field along with a relevant date and 102 time when they know that the content of the message has no value 103 after a given point of time (e.g. Commercial newsletters 104 --especially when including time-limited offers, Event announcements, 105 Social notifications, Time-limited access codes ...). 107 In all other cases, senders SHOULD NOT set an Expires header. 109 5. Advice to Receivers (Mailbox providers, Webmails and MUAs) 111 The expiration of a message's validity would logically lead to the 112 deletion of the message. However, users on most systems do not 113 expect their emails to disappear, and may not be aware that any 114 particular email has an Expires header. Therefore, no email should 115 be silently and automatically deleted solely based on the value of 116 the Expires header field. 118 Mailbox providers SHOULD explain to users how the information 119 provided in the Expires header are processed, SHOULD indicate when 120 viewing an expired message, and SHOULD give users control over the 121 actions to take for expired messages. 123 The information provided in the header should be used as a signal 124 that could be used to provide a feature or improved experience to the 125 end-user. For instance, systems may allow users to set up an 126 automatic rule to clean up expired email from specific senders or 127 with specific characteristics, or provide a mode to quickly view and 128 process all expired email. 130 In certain cases, email messages can be used as proof or element of 131 investigation. As an early deletion may compromise the intended 132 investigation, mailbox providers can ignore the Expires information 133 in such cases. 135 Presence of the Expires header field MUST NOT be interpreted as a 136 sign of legitimacy. 138 6. Past History of the Expires: header 140 [RFC4021] defines a number of header fields that can be added to 141 Internet messages such as those used for mapping between X.400 and 142 RFC822/MIME [RFC2156]. One of them is the Expires header field that 143 provides the date and time at which a message is considered to lose 144 its validity. 146 The same principle can be applied to the Expires header field in a 147 SMTP context, whether the message comes from a X.400 gateway as 148 initially intended in [RFC2156], or from a RFC821/SMTP MTA. 150 7. Acknowledgements 152 This document was informed by discussions with and/or contributions 153 from Jonathan Loriaux, Charles Sauthier and Simon Bressier. 155 8. IANA Considerations 157 IANA is requested to update an existing entry in the Permanent 158 Message Headers Field Names registry 159 (https://www.iana.org/assignments/message-headers/message- 160 headers.xhtml) 162 Header field name: Expires 164 Applicable protocol: mail 166 Status: standard 168 Author/Change controller: IETF 170 Specification document: this document 172 9. Normative References 174 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 175 Mapping between X.400 and RFC 822/MIME", RFC 2156, 176 DOI 10.17487/RFC2156, January 1998, 177 . 179 10. Informative References 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, 183 DOI 10.17487/RFC2119, March 1997, 184 . 186 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 187 Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 188 2005, . 190 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 191 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 192 May 2017, . 194 Authors' Addresses 196 Benjamin Billon 197 Splio 198 Email: bbillon@splio.com 200 John Levine 201 Standcore LLC 202 Email: standards@standcore.com