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.
In the case of compliance archiving, I agree. Just because a message expires
at some point doesn't change the fact that it was sent or received.
More generally, these sorts of hints may alter user behavior in various ways,
but what the user ended up doing is what counts.
Operational archiving and cleanup is another matter, however. The minute you
start talking about schemes that move messages to secondary storage, or expire
them after some period of time, you enter a realm where it makes quite a bit of
sense for operational policies to consider expiration dates.
> 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.
Well, anyone who thinks this stuff is all sweetness and light really ought to
try reading the actual laws in various jurisdictions first. (SOX is an
excellent starting point.) Insane is too kind, actually, because that label
effectively absolves the authors of this dreck of responsibility for it.
Incompetent and unaware of technical realities comes a lot closer to the mark.
Mind you, I have no issue at all with the intent of these laws. The devil is
all in the details.
> 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.
Exactly. I suppose expiration dates might be relevant in some instances in that
setting one might speak to the sender's intent in some way, but it makes no
sense for compliance archiving to honor such a field.
Ned