When users delete mail, I want it to be moved to Trash.
Erik Enge
eenge at prium.net
Mon Oct 21 15:49:09 EDT 2002
Rob Siemborski <rjs3 at andrew.cmu.edu> writes:
> Okay, I think you're trying to solve the problem the wrong way. If
> you need a record of every email that has ever passed through your
> company, can't you just have the MTA save a record of it without
> inconveinencing your users with managing their mail how they see fit?
I could, but that would introduce new hassles. I want the users to be
able to get to all their mail, by themselves, if they need to. If I
saved it like that, I would have to make that mail available through
some other protocol (one that one ensure that they could not delete it -
so IMAP and POP would be right out) - which is more administration
hassle.
No, I think I am trying to solve it correctly. Cyrus stores my data and
Cyrus is the one that will not allow me to manage that data they way I
see fit.
Besides, just think of the extra hardware resources I would need.
Storing double copies would require extra SCSI disks (and thus a new
casing) and I would have to change my backup schema. No, I shouldn't
have to store it all twice. It's stored just fine the way it is. I
just need to make users not able to remove it.
What about a site with 10.000 users and terrabytes of mail? Would you
suggest to them that they also save everything twice? And if not, and
if such a site would be interested in Cyrus, would the answer be "sorry,
can't help you"?
> This doesn't sound like a problem that Cyrus can or even should try to
> solve.
Why not? It must be something either I or you are overlooking. To me
this is as simple as: Cyrus will not allow me to manage the data it
stores the way I want it managed. You seem to be saying that this is
not a responsability of Cyrus.
Well, the reason something needs to be solved it because Cyrus won't let
me do this. Had it let me do this (enforce a no-delete policy) there
wouldn't be anything to solve. Cyrus introduces the problem so it
should be the one to fix it.
Erik.
More information about the Info-cyrus
mailing list