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

Hector Santos wrote:
> Keith,
>
> I was referring to widely practiced Standard Email Compliance Policies 
> that include archiving, expiration, mining, etc following and/or meeting 
> required data retention regulations outside the considerations of user 
> rights.
offhand, I don't see how an expires header field generated by a sender, 
especially one outside a recipient's enterprise, should affect this sort 
of data archiving at all.
> Nothing insane, irresponsible or illegal about them. 
we'll probably just have to disagree about the insane part.  but you 
were referring to something different than I was.
> While you may not 
> feel is our job to bless the practice, I'm sure others will take all 
> these related issues into account. You made it quite clear your view 
> point;  backends MUST not deal with this header and if they do only with 
> user permission.  Well, the devil is in the details; e.g., if user 
> permission is provided (assuming it is even offered at all),  it can not 
> defeat what may be already in place.   It can only serve to accelerate 
> the expired classification.  Not extend it  - unless of course an 
> implementation wishes to consider that logic.
and if the sender is allowed to accelerate the expired classification 
this can result in the sender being allowed to destroy evidence that 
might otherwise be retained on the recipient's system?  right.
Keith