Updated Use of the Expires Message Header Field

Introduction 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 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 when, and only when, they appear in all capitals, as shown here.

Header Field definition The header field definition remains the same as in and . It indicates the time at which a message loses its validity. Using the ABNF from , 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.

Advice to Message Creators Message creators 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 time. This could apply to commercial newsletters that include time-limited offers, event announcements, social notifications, and periodic announcement messages.

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.

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

Acknowledgements This document was informed by discussions with and/or contributions from Barry Leiba, Alexey Melnikov, Jonathan Loriaux, Charles Sauthier and Simon Bressier.

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