Summary

  • draft-ietf-mailmaint-expires-06 broadens use of the email Expires header but deliberately leaves “loses its validity” imprecise; a creator's date is a signal, not a verified fact.
  • Mail software must not reject or discard solely because of the field and should not delete without deliberate mailbox-owner configuration. Display, storage, evidence and final purge are separate states.
  • The sender may benefit from urgency, invisibility or persistence. Safe automation authenticates the claim, preserves local authority and records the action without turning a header into a remote deletion command.

The message that expired before it arrived

Imagine an abuse report reaching a security mailbox after a weekend queue delay. Its creator put yesterday's date in Expires. The incident is still active, the attachment still matters and the receiving team has not read it. A client that paints the row grey has made a presentation choice. A gateway that rejects it has destroyed delivery. An archive that purges it has erased evidence. Those are not three ways to implement the same instruction.

The Mail Maintenance working group's revision 06 proposes broader Internet-mail use of a field inherited from X.400 mappings. Its syntax is modest: one date-time, and no more than one field. Its semantics are intentionally bounded. After that instant the creator considers the message to have “lost its validity.” The draft says there is no consensus for a more precise normative definition.

That absence is the design boundary. Validity might mean an offer closed, an event passed, a one-time code became useless or a periodic report was superseded. It does not establish that the message was delivered, read, unwanted, fraudulent, legally disposable or safe to remove from every copy.

The document is an active Internet-Draft in the RFC Editor queue, intended for Proposed Standard. It is not yet a published RFC, and its process position is not a deployment census.

One timestamp, at least five clocks

The header carries the creator's chosen instant. The receiving system also has the message's origination date, transport timestamps, arrival time, first-display time and local deletion time. The business event may have its own deadline. None is automatically equal.

A sale can expire at midnight in one jurisdiction while the message crosses another time zone. A flight disruption notice can be operationally important after the departure time because it explains a refund. A security alert can be stale as advice yet essential as incident history. A malformed field can fail parsing without making the bytes disposable.

The narrow field therefore should remain narrow. Store the raw value, the parsed instant or parse failure, and the local clock context. Do not let a single normalized label—“expired”—erase which clock, claim and decision produced it.

The draft keeps the sender away from the shredder

The most important requirements appear in the advice to readers. Mail software must not reject or discard a message solely because of Expires. It should not delete a past-dated message unless the mailbox owner deliberately configured that behavior.

Those verbs describe different control surfaces. Rejecting prevents acceptance. Discarding accepts and then makes the message disappear. Hiding changes the reader's view. Moving changes a folder or label. Deleting changes the primary store. Purging may make recovery impossible. Journals, backups and legal holds can remain even after a mailbox copy is gone.

An implementation that reports only “expired action completed” conceals the outcome that matters. The receipt needs to say which component acted, under whose rule, whether the action was reversible, and which copies remained.

The field can still be useful. A mailbox may group expired promotions, de-emphasize old event notices or offer a one-click review queue. The protocol supplies a comparable hint. The recipient supplies authority.

Authentication does not make the date binding

DKIM can help establish that a domain took responsibility for signed message fields. It cannot prove that a date is accurate, benign or entitled to control recipient storage. Authentication answers who vouched for bytes; it does not answer whether the recipient should obey the claim.

That distinction matters because the incentive is not neutral. The draft notes three manipulations. A spammer can backdate mail so it is hidden before users report it, contaminating adaptive-filter feedback. A sender can choose an imminent time to manufacture urgency while making later complaint harder. A distant-future date can seek persistent inbox prominence.

The same party that creates the message chooses the date. A destructive interpretation would let that party influence the survival of evidence about its own conduct. Even a perfectly authenticated sender should not inherit the mailbox owner's deletion power.

Presentation, retention and evidence need separate ledgers

A safe system can model four layers.

First is the declaration: raw Expires, parse status and authenticated creator context. Second is presentation: visible, dimmed, grouped, hidden from the default view. Third is retention: live mailbox, reversible holding area, archive, backup or final purge. Fourth is evidentiary use: complaint, security case, transaction record, contractual notice or legal hold.

Movement at one layer should not silently imply movement at another. A message hidden from the inbox can remain searchable. A mailbox deletion can leave a journal copy. A past date can be overridden by an incident hold. A final purge should be attributable to a local policy, not narrated as something “the email requested.”

For audit, retain a bounded receipt: message identifier or digest; received time; raw and parsed expiry; creator and signing evidence; local rule version; mailbox-owner consent; presentation action; storage action; recovery deadline; and final purge result. This is an operating proposal, not a new protocol requirement.

Small interoperability, local decisions

The field illustrates a useful form of Minimum Initial Specification. Interoperability needs a stable name, syntax and restrained meaning. It does not need a universal deletion policy. Providers and users can adopt different handling profiles without turning non-adoption into invalid behavior.

Running code supplies the evidence that the header cannot: did the gateway accept the message, did the client hide it, did the archive preserve it, and could an operator restore it? Publication, registration and authentication remain above those outcomes.

The standards lineage is equally bounded. RFC 1327 introduced Expiry-Date; RFC 2156 mapped it to Expires; RFC 4021 registered it as not for general use. Revision 06 would broaden use. History explains the field. It does not grant the author ongoing authority over the recipient's record.

Sources

  1. Expires draft revision 06 text
  2. Expires draft revision 06 HTML
  3. Datatracker — revision 06
  4. Datatracker history
  5. RFC 1327
  6. RFC 2156
  7. RFC 4021
  8. RFC 5322
  9. RFC 5536
  10. RFC 5598
  11. RFC 6376 — DKIM
  12. RFC 7942 — Implementation Status
  13. IANA Message Headers registry
  14. Lu Heng — Minimum Initial Specification
  15. Lu Heng — On Reality Layers
  16. Lu Heng — Running Code Primary