[Top] [All Lists]

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

2008-07-23 16:31:43

ned+ietf-822(_at_)mrochek(_dot_)com 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.


<Prev in Thread] Current Thread [Next in Thread>