On 7/30/08 at 9:56 AM -0400, Keith Moore wrote:
>Even if we say that mail transport and message stores MUST NOT
>delete messages on the basis of this new field without recipient
>consent, implementors of such products will have a hard time
>resisting the temptation to add such a feature which seems obviously
>useful to them.
So, I believe there is a saving grace here, and that we will be able
to go ahead and use "Expires:" instead of
"I-Dont-think-you-want-to-read-this-after:"...
If, e.g., Microsoft were to implement message deletion based on the
"Expires:" header in, e.g., Exchange, they would immediately be sued
or otherwise have their heads handed to them. The reason is that they
will instantly cause companies to be in violation of all sorts of
corporate compliance laws and discovery orders. They simply can't do
this. The power of corporate money is much greater than user
complaints. So I don't think the "risk of idiocy" profile for
"Expires:" is nearly as bad as other features we've seen abused in
the past.
And by the same token, in many cases once the mandated retention period is
past, in order to limit what's discoverable many companies have strict
policites calling for forced deletion of most if not all email. I doubt it
makes sense to have such mechanisms consider an Expires: field, but if a case
existed where it did it's safe to say it will work in whatever way is deemed to
miminize exposure to lawsuits, irrespective of anything that's said in an RFC.
Now, will some web mail folks who already have draconian mail
deletion policies use "Expires:" to start deleting that mail
preferentially? Maybe not, because they have better things to do than
to write code to search for "Expires:" and would rather just delete
after some hard date. If they do, then as a user, I think I'd prefer
them to preferentially delete "expired" messages rather than others.
Very good point.
Either way, I think the damage potential here is minimal, and the
gain, though also small, is reasonable for folks who want to use it.
+1
Ned