Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

[email protected] wrote:

 >> Jeff wrote:
 >>
 >> I find it very desirable to have MTAs generate a bounce if
 >> the message is older than the Expired header.
 >
 > I do not. The problem with trying to do this at the MTA level
 > is that the preferences of the recipient cannot be properly taken
 > into account.
 >
 > If you want this sort of service at the transport level, use
 > the DELIVERBY extension, not an Expired: header. This is what it
 > is for. IMO Expired: should only be used as an MUA-level facility.

For our system,  I can easily see this as a desirable feature (new 
checkboxes) for the backend mail policy definitions. 

   [X]  Days to Expire Read Private mail:      7
   [X]  Days to Expire Unread Public or Private mail:  30
   [X]  Days to Expire External (sent) mail: 30
   [_]  Delete External user email once delivered (sent) by SMTP
   [X] Allow Personal Mail Deletion

   [X]  Support RFC xxx  Expire Flags for Received Mail
   [X]  Support RFC xxx  Expire Flags for UnReceived Mail

Anything that helps the operator make a decision would be useful.

As you know Ned,  expiration that is out of the control of the MUA 
(user) is already in practice.  The question/design issue would be, IMV, 
if an external sender-defined flag can be used to accelerate/trigger the 
existing backend practice.  Of course, it can not be used to defeat the 
existing practice.

-- 
HLS