Summary

  • RFC 10080 extends the email use of the Expires header beyond messages translated from X.400.
  • Mail systems must not reject or discard a message solely because of that field; mailbox owners retain control over deletion.

A sender can now put a date on an email and call it the moment the message loses validity. That sounds like a self-destruct button. It is not one. RFC 10080 gives the date meaning, then leaves the inbox holding the controls.

The change is small and unusually revealing. RFC 4021 registered Expires for mail but described it as “not for general use,” tied to the X.400 mapping standardized in RFC 2156. RFC 10080 opens the field to Internet email generally. A commercial offer, an event notice or a periodic announcement can now carry the date its creator says it stops being valid.

The message creator must include no more than one Expires field. The standard defines its syntax as a date and time. It does not prescribe one universal consequence when the clock passes that value. Mailbox providers and mail user agents may push an expired item down the screen, hide it, or let the reader choose how expired mail is handled.

That split is the story. The sender supplies a claim about relevance; the receiving service chooses the interface and retention behavior. RFC 10080 says mail software must not reject or discard a message solely because of the field. It also says software should not delete an expired message unless the mailbox owner deliberately configured that action. The field can affect attention. It cannot seize the trash can.

The distinction matters because email is not just a delivery pipe. It is also a record store. A message can be stale as an offer and still matter as proof of what was promised, when it was sent, or what a customer was asked to do. RFC 10080 leaves that decision with recipients and their configured systems, not with the marketer who authored the date.

The standard also names the abuse case. A sender can choose any date. A spammer might mark a message as already expired in the hope that the recipient never sees or reports it. Another sender might set a near-future date to make a request feel urgent and harder to retrieve later. An expiry value is therefore input to a reader’s display policy, not a trustworthy verdict about the message.

There is a long trail behind the field: X.400 mail mapping, the IANA header registry, and the separate Netnews Expires header, whose syntax is similar but stricter. Netnews already treated expiry as a poster’s judgment that an article had lost relevance, without requiring removal. RFC 10080 extends the idea to Internet email while explicitly protecting recipient control.

The practical question for a mailbox operator is not whether the date passed. It is which actions the owner has authorized the software to take. A sensible implementation can make an expired message less prominent, explain why, and keep it available unless the owner’s own rule says otherwise. That preserves the sender’s useful context without letting the sender write a retention policy for someone else’s inbox.

Sources: RFC 10080; RFC 4021; RFC 2156; RFC 5536; IANA Message Headers registry.