I feel it is very useful to extend the use of the "Expires" header beyond X.400 gateway mapping, and into any email.

I do have a couple of questions/comments, for your consideration:

First, maybe a nit or language nuance, but I note a difference between "validity" and "value" (or "valid" and "valuable".) Perhaps a misinterpretation from English-as-a-non-1st-language, but thought I'd mention it:

I find the reference to RFC4021 useful, as <https://www.rfc-editor.org/rfc/rfc4021.html#section-2.1.50> includes the textual description of the field and some historical context, whereas RFC2156 doesn't directly.
* RFC4021 says: "Time at which a message loses its validity."
* Which aligns with T-REC-F.400-199906-I, B.49: "date and time after which he considers the IP-message to be invalid."

However, draft-billon-expires-06 includes text like:
* "Message creators can then indicate when a message sent becomes valueless and can safely be deleted, while recipients would use the information to delete or ignore these valueless messages."
* "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 point of time."

A valid message might be valueless, whereas an invalid message can be valuable -- e.g., depending on the definition of "value". It might seem as redefining the meaning, changing from "invalid" to "valueless".

S2 of this document does say: "The header field definition and syntax remain the same as in [RFC4021], the time at which a message loses its validity."


The last sentence of the Introduction seems potentially contradictory to the advice in Section 5. Deleting is one potential action, but not the only one when user experience is the goal:
   or the MUA to indicate to the user that certain messages could be
   deleted, in an attempt to unclutter the user's mailbox and spare
   storage resources.
vs.
   The information provided in the header field is intended to be used
   as a signal that could be used to provide a feature or improved
   experience to the end-user. 


S5 says:
   Therefore, no email
   should be silently and automatically deleted solely based on the
   value of the Expires header field.
Is this a "no email should" or a "email SHOULD NOT"?


Organization: Would S6 be more useful as part of the Introduction, which is quite thin?


And nits:

S2.
OLD:
   If there is more than one Expires header field then message readers
   SHOULD act as if no Expires header field is present.
NEW:
   If there is more than one Expires header, field then message readers
   SHOULD act as if no Expires header field is present.

S5:
OLD:
5.  Advice to Message Readers (Mailbox providers, Webmails and MUAs)
NEW:
5.  Advice to Message Readers (Mailbox Providers, Webmails, and MUAs)

Many thanks for reading thus far! 

I hope these are useful and clear.

Carlos Pignataro.