]> Splio

bbillon@splio.com

Standcore LLC

standards@standcore.com

ART mailmaint email 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 can use this information to handle an expired message differently.

Introduction defined a mapping of header fields between the formats specified in X.400 and . 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. registered the field with IANA but stated that it is "not for general use." 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. Netnews articles have an "Expires" header with a similar, slightly more strict, syntax and similar meaning. The date and time of expiration can be used by the mailbox provider or the MUA (Mail User Agent) to de-emphasize certain messages, or not display them at all, to unclutter the user's mailbox. A Message Creator is an agent that generates messages for delivery. In the parlance of , this is an Author or Originator. A Message Reader is either an agent consuming a message or an agent storing a message. In the parlance of , this is a Message Store or a Message User Agent.

Requirements Language 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.

Defining Expiration defined a field called "Expires", which replaced "Expiry-Date" introduced in . It did not define the term further, except to say that no automatic handling past that date can be expected. defined "Expires" for Netnews as a date and time beyond which the poster considers the article no longer relevant and thus suitable for removal; however, it 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 email 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.

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: Example: Expires: Wed, 3 Dec 2025 17:22:57 +0000

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. Message creators MUST NOT include more than one "Expires" header field in a message.

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. Mail software MUST NOT discard or reject a message based solely on the content of this header field, if present, and SHOULD NOT delete messages bearing an "Expires" field with a date and time in the past unless deliberately configured to do so by the mailbox owner.

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 authors have never seen such a message, there is a theoretical risk of confusion.

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 an expiry date in the past, in the hope that recipients would not see or report the mail, and that 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 for determining how to display a message to a user, it is unlikely to be useful for determining whether the message is wanted or is fraudulent.

IANA Considerations IANA has updated an existing entry in the "Permanent Message Headers Field Names" registry.

Header Field Name:

Expires

Protocol:

mail

Status:

standard

Author/Change Controller:

IETF

Trace:

no

Reference:

RFC 10080

References Normative References Informative References

Acknowledgements This document was informed by discussions with and/or contributions from , , , , and .