Internet DRAFT - draft-billon-expires
draft-billon-expires
Network Working Group B. Billon
Internet-Draft Splio
Intended status: Standards Track J. Levine
Expires: 12 November 2023 Standcore LLC
11 May 2023
Updated Use of the Expires Message Header Field
draft-billon-expires-09
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 12 November 2023.
Copyright Notice
Copyright (c) 2023 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 12 November 2023 [Page 1]
Internet-Draft expires May 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Defining Expiration . . . . . . . . . . . . . . . . . . . . . 3
3. Header Field definition . . . . . . . . . . . . . . . . . . . 3
4. Advice to Message Creators . . . . . . . . . . . . . . . . . 4
5. Advice to Message Readers . . . . . . . . . . . . . . . . . . 4
6. Interoperability Considerations . . . . . . . . . . . . . . . 4
7. Security considerations . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 5
11. Informative References . . . . . . . . . . . . . . . . . . . 6
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 12 November 2023 [Page 2]
Internet-Draft expires May 2023
2. Defining Expiration
[RFC2156] defined a field called "Expires", which replaced "Expiry-
Date" introduced in [RFC1327]. It did not define this 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 migration into email has been largely organic,
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 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.
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.
Billon & Levine Expires 12 November 2023 [Page 3]
Internet-Draft expires May 2023
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.
5. Advice to Message Readers
Message readers, such as mailbox providers, web mail and MUAs could
de-emphasize the display of expired messages or determine not do
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 may exist
implementations that use this header field name in a way that does
not comport with this specification. Though such implementations are
not known to the IETF at this time, there is a possible risk of
confusion.
There are some known problems with interpretation of email date-times
in the future. The specifications for Internet message format are
currently under revision and may or may not address this. Message
Creators should make themselves aware of these issues if accuracy of
expiration is a concern.
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
Billon & Levine Expires 12 November 2023 [Page 4]
Internet-Draft expires May 2023
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.
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>.
Billon & Levine Expires 12 November 2023 [Page 5]
Internet-Draft expires May 2023
[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>.
[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 12 November 2023 [Page 6]
