This looks pretty close to what we need

[Joshua Baer]

http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15

~Josh

[Matt Bowman]

Here's what we had on the initial push (1/2009):

Abstract

The expiration date header field is a structured field to be added to
commercial email messages. The field will contain an expiration date
in ISO 8601 format that defines when the email, if unopened, MAY be
removed by the MUA.

There already exists a header defined in [RFC4021] called Expires, but
there is no formal definition regarding how it should be handled by
the MUA. This document intends to outline the default handling of
messages that include the Expires header.

By including this header in email messages, the MUA can assist the
user in keeping his or her inbox clean. This processing of the
message could take the form of archiving, moving to the trash, or
permanently deleting it if the user never opened it. The intent of the
RFC is to clarify and standardize the process a MUA uses when this
header is specified.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.


1. Introduction

This is a proposal for additional header fields to be added to email
messages sent by companies in CRM mailings like newsletters and
special offers.

The implementation of this header will be optional. However,
significant convenience can be gained by including them. Many
companies, especially those that wish to remain in contact with their
customers through email messages, MAY choose to implement the field.
By implementing the header, companies that send newsletters or special
offers to their customers will not have to worry about their
customers’ inboxes getting filled with out of date, unread email
messages. The email address owner will also benefit from this header
because it will significantly reduce the number of email messages they
need to sort through in the event that they haven’t checked their
inbox in a few days.

2. The Command Syntax

The expiration header fields are subject to the encoding and character
restrictions for mail headers as described in [RFC822]. Additionally,
the URL content is further restricted to the set of URL safe
characters [RFC1738].
The contents of the list header fields mostly consist of angle-bracket
('<', '>') enclosed URLs, with internal whitespace being ignored.
MTAs MUST NOT insert whitespace within the brackets, but client
applications should treat any whitespace, that might be inserted by
poorly behaved MTAs, as characters to ignore.

A list of multiple expiration dates MUST NOT be specified.


On Jan 17, 10:53 pm, Joshua Baer <joshuab...@otherinbox.com> wrote:
> http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15
>
> ~Josh