Summary

  • The IESG approved draft-ietf-mailmaint-expires-06 as a Proposed Standard on 8 May 2026. The field lets a message creator state a date after which a message loses validity, while deliberately leaving the operational meaning narrow.
  • Mail software must not reject or discard a message solely because of Expires, and should not delete a past-dated message unless the mailbox owner deliberately configured that result. Presentation, policy, deletion marking and permanent removal remain separate acts.

A clock attached by the sender

Email already contains many dates, but they answer different questions. A Date field records when the message creator says the message was composed. Transit fields can document handling. A mailbox can record delivery, indexing and last-access times. Expires adds another statement: after a specified RFC 5322 date-time, the creator considers the message no longer valid.

The use cases are ordinary. A discount ends. An event has passed. A social notification is no longer current. A periodic announcement has been superseded. In each case, a reader may gain something by moving stale material out of the immediate field of attention.

The field’s simplicity is also its limit. Revision 06 says a creator must not include more than one Expires field, but it does not define one universal consequence for reaching the date. The working group could agree on “loses its validity.” It could not safely equate that phrase with delete, conceal, reject, recall or disregard.

That restraint matters because the timestamp enters the mailbox as a sender assertion. The party that benefits from an offer disappearing may be the party that chose its expiry. The institution named in an event notice may prefer that an obsolete instruction fades from view. A platform may want an old alert demoted. None of those preferences automatically expresses the interests of the recipient who stores the evidence.

Approval without invented precision

The IESG announced approval at 22:11 UTC on 8 May 2026. The document is a product of the Mail Maintenance Working Group and is intended for the Standards Track as a Proposed Standard. At the evidence freeze for this article, the Datatracker showed revision 06 in the RFC Editor queue, awaiting its first editor, with the IANA action at RFC-Ed-Ack.

IANA’s Message Headers registry already lists the mail form of Expires as standard and points to the Internet-Draft. A separate Netnews entry remains distinct. That distinction is useful: a familiar field name does not make semantics portable from one message environment into another.

The specification has a long lineage. Earlier registrations and X.400 mappings recorded an expiry field, while deployed software developed different behavior around it. The new work does not pretend that history produced a precise, universal command. It sets a minimum common meaning and puts hard limits around unsafe default behavior.

This is standards work at its strongest. Coordination does not require every implementation to make the same product choice. It requires implementations to agree on the interoperable signal and on what that signal cannot authorize by itself.

The reader still owns the decision

The document uses the mail-architecture terms Message Creator and Message Reader. A reader may be a storage agent or a user agent. It can use expiry information to de-emphasize a message, choose not to display it in a default view, or offer cleanup rules controlled by the user.

But two guardrails follow. An implementation must not reject or discard a message solely because its Expires date has passed. It should not delete a past-dated message unless the mailbox owner deliberately configured that behavior.

The difference between “may de-emphasize” and “may delete” is not cosmetic. Visibility is a reversible presentation decision. Deletion changes the evidence available to the owner. Permanent removal may be irreversible. A sender-supplied date can be an input to the first decision without becoming delegated authority for the last.

IMAP4rev2 makes the separation concrete. A message is marked with \Deleted; EXPUNGE permanently removes messages carrying that flag, while UID EXPUNGE can narrow the operation to selected UIDs. Other storage systems may implement removal differently, but the architectural sequence remains observable: parse a date, apply a view or policy, mark state, and remove bytes. Treating those events as one opaque “expiry” destroys the audit trail.

Authentication does not enlarge the instruction

A DKIM signature can give a verifier evidence that a signing domain accepted some responsibility for selected signed material. If Expires is covered, a later modification may be detectable within DKIM’s own conditions. That is valuable provenance.

It does not prove that the date is reasonable, truthful or aligned with the mailbox owner’s purpose. More importantly, it does not grant the signing domain control over recipient retention. Authenticating who made a claim cannot enlarge the claim’s authority.

The same boundary is familiar elsewhere in Internet infrastructure. A registry entry, routing attribute or signed object may establish one fact within a defined system. Operational power does not follow merely because the fact is machine-readable or cryptographically attributable. Evidence and permission are different layers.

The Expires field makes that distinction unusually visible because its syntax looks actionable. A timestamp invites automation. The standard’s discipline is to allow automation while keeping the source of authority explicit.

An attacker can choose the date too

The threat analysis does not assume benign senders. A creator may choose a date in the distant past, the near future or far ahead. A reader that knows nothing else cannot conclude that the value is accurate or helpful.

A past date could be used to make spam less visible before a user reports it. A near-future date could make a complaint or disputed instruction harder to locate after someone acts. A distant-future date could seek persistent prominence. The field is therefore unlikely to decide whether a message is wanted or fraudulent.

These are not reasons to ignore expiry data. They are reasons to preserve context. A reader can combine the date with authentication results, sender history, mailbox-owner preferences and message class. It can display that an item is past the sender’s stated validity period without pretending that the system has discovered an objective truth.

The right label is important. “Expired according to the message” describes evidence. “Safe to delete” announces a decision. Moving between them requires a local rule owned by the party that bears the loss.

Sources