Internet-Draft expires August 2024
Billon & Levine Expires 13 February 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-mailmaint-expires-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Billon
Splio
J. Levine
Standcore LLC

Updated Use of the Expires Message Header Field

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 13 February 2025.

Table of Contents

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.

2. Defining Expiration

[RFC2156] defined a field called "Expires", which replaced "Expiry-Date" introduced in [RFC1327]. It did not define the term 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 use in e-mail has been limited, 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 2024 17:22:57 +0000

Message creators MUST NOT include more than one Expires header field in a message.

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.

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 not 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 might have been implementations that used this header field name in an incompatible way. Though the IETF has never seen such a message, there is a theoretical risk of confusion.

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

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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4021>.
[RFC5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc5536>.
[RFC5598]
Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, , <https://www.rfc-editor.org/info/rfc5598>.

Authors' Addresses

Benjamin Billon
Splio
John Levine
Standcore LLC