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.
--
HLS