How about this: "The sender believes this message will be irrelevant
after the indicated date/time."
If memory serves, this matches the X.400 definition pretty closely. (Note that
the X.400 definition isn't something you'll find in any RFC - the various
X.400-related RFCs only define mappings, for the most part the specification of
X.400 field semantics is left to X.400 itself.)
"This field is primarily intended for use between senders and recipients
and their agents, rather than by message transport. It is suggested
that the default behavior of an MUA with respect to the expires header
field should be to display such a message in a distinguished way. For
example, the message could be displayed with gray text rather than
black, or in a different font than normal, or (in summaries) with an
image of an hourglass with the sand at the bottom."
"It is also suggested that MUAs allow setting of an expiration date as
an option when composing messages"
I wonder if it is worth saying something about how it is RECOMMENDED that the
user be allowed to pick from a calender or some other graphical tool rather
than always having to type in a date directly... OK, probably not.
"MUAs, Message Stores, and MTAs, MUST NOT delete a message on the basis
of an Expired header field unless given explicit instructions to do so
by the recipient."
"Mail Filters MUST NOT consider an expired header field as criteria to
be considered for deleting the message unless given explicit
instructions to do so by the recipient"
This text seems very reasonable to me.
behavior for mail-to-NetNews gateways should also be specified.
If someone wants to write it, sure, but I don't think defining this mapping is
a prerequisite to this specification being viable any more than I think a
mapping to MMS or any other serivce email is routinely gatewayed into is
required.
Ned