[Top] [All Lists]

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

2008-07-24 10:12:03

Hector Santos wrote:

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.


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