Updated Use of the Expires Message Header Field
draft-billon-expires-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 "Replaced".
|
|
|---|---|---|---|
| Authors | Benjamin BILLON , John R. Levine | ||
| Last updated | 2021-12-14 | ||
| Replaced by | draft-ietf-mailmaint-expires | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
ARTART IETF Last Call review
(of
-06)
by Barry Leiba
Ready w/nits
|
||
| Stream | Stream state | (No stream defined) | |
| Associated None milestone |
|
||
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-billon-expires-00
Network Working Group B. Billon
Internet-Draft Splio
Intended status: Standards Track J. Levine
Expires: 17 June 2022 Standcore LLC
14 December 2021
Updated Use of the Expires Message Header Field
draft-billon-expires-00
Abstract
This document allows broader use of the Expires message header field.
Senders can then indicate when a message sent becomes valueless and
can safely be deleted.
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 17 June 2022.
Copyright Notice
Copyright (c) 2021 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 17 June 2022 [Page 1]
Internet-Draft expires December 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Header Field example . . . . . . . . . . . . . . . . . . . . 2
3. Security considerations . . . . . . . . . . . . . . . . . . . 3
3.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Implementation and Usage Consideration . . . . . . . . . . . 3
4.1. Advice to senders . . . . . . . . . . . . . . . . . . . . 3
5. Advice to Receivers (Mailbox providers, Webmails and MUAs) . 3
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . 4
9. Informative References . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
[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.
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
Billon & Levine Expires 17 June 2022 [Page 2]
Internet-Draft expires December 2021
There should be only one occurrence of the header field in a single
message. The presence of more than one Expires header would make
them void.
3. Security considerations
The expiration of a message's validity should lead to the deletion of
the message. In certain cases, such as emails being used as proof or
element of investigation, an early deletion may compromise the
intended investigation. For this reason, we want to avoid the header
field to be tempered with.
3.1. DKIM
Senders including the Expires header field MUST sign the message with
DKIM [RFC6376] and include the field in the h= tag.
Receivers MUST NOT consider the value provided in the Expires header
field if the DKIM check fails.
4. Implementation and Usage Consideration
4.1. Advice to senders
Senders SHOULD add the header field along with a relevant date and
time whenever applicable.
Commercial newsletters are good candidates, especially when including
time-limited offers.
Social notification and one-time-password emails SHOULD include the
Expires header field, with an expiration set within a few days at
most.
Payment receipts, bank statements, contracts and other emails that
should be kept or archived by the recipient SHOULD NOT include the
Expires header field.
5. Advice to Receivers (Mailbox providers, Webmails and MUAs)
Generally, no email should be automatically deleted solely based on
the value of the Expires header field.
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. Automation of email deletion based on the value of the
Expires header may be set by the end-user.
Billon & Levine Expires 17 June 2022 [Page 3]
Internet-Draft expires December 2021
Receivers can prevent deletion from happening if necessary.
Presence of the Expires header field MUST NOT be interpreted as a
sign of legitimacy.
6. Acknowledgements
This document was informed by discussions with and/or contributions
from Jonathan Loriaux, Charles Sauthier and Simon Bressier.
7. IANA Considerations
This document has no IANA actions.
8. 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,
<https://www.rfc-editor.org/info/rfc2156>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
9. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[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>.
Authors' Addresses
Benjamin Billon
Splio
Email: bbillon@splio.com
Billon & Levine Expires 17 June 2022 [Page 4]
Internet-Draft expires December 2021
John Levine
Standcore LLC
Email: standards@standcore.com
Billon & Levine Expires 17 June 2022 [Page 5]