Hi, On Fri, 10 May 2002 09:36:59 +0200, Pawel Salek <[EMAIL PROTECTED]> wrote... > Hi, > > On 2002.05.10 04:26 Mark Keasling wrote: > > On Thu, 9 May 2002 11:15:42 -0700 (PDT), Mark Crispin > > <[EMAIL PROTECTED]> wrote... > >> You are better off using the natural native IMAP delete-expunge model > >> internally, and make "trash" be a user interface concept rather than > >> what happens internally. That is what all good client programs do. > >> Only very badly designed and written clients actually create a > >> mailbox called "trash" and copy messages to it. > > > > Mark, I haven't had my morning coffee yet so I'm still an incoherent > > ogre. > > > > I'd very much like to agree with your assertion that the natural native > > IMAP delete-expunge model (NNIDEM) is totally sufficient and write a > > good client program. However, the NNIDEM does not meet my superior's > > expectations and requirements as it only provides the Trash for the > > currently selected folder and not the Trash for all of the folders on > > the server. > > My *personal* point of view is that IMAP is Internet Message Access > Protocol, not an Easy Superior's Satisfaction Protocol. IMAP provides > you with a flexible set of command allowing you to manipulate remote > mailboxes, without adding any user interface paradigm on top of it. This > keeps options open for those who do not want to have trash folder, and > for those who do.
Many years ago my superiors selected IMAP (it was IMAP2 then) as the protocol of choice. IMAP's closest competition at that time was some unwieldy system based on POP. > > My boss unlike some people does not like having deleted messages > > interspersed with his other mail. He wants it to go away as soon as > > its deleted. Once my boss has deleted a message, he expects to find > > it in the "Trash" folder without having to remember which folder it > > was in previously and selecting that folder to get at its trash. This > > is the inevitable result of providing a "Trash" folder virtual or > > otherwise. > > Nothing's stops you from implementing this within Internet Message > Access Protocol. You can always hide in your client messages marked as > deleted, and copy them to Trash folder, if you find it attractive. You are absolutely correct. Attractiveness or even efficiency has nothing to do with anything. The product must work as designed. The only freedom is in the details of implementation. If the design requirements specify that a message must be appended to the "Trash" mailbox and removed from the current folder during the message delete operation, that is what must happen. > > The other expectation is that the Trash can be allowed "decompose" so > > that once a messsage is been deleted and placed in the trash, it can be > > safely forgotten as it will be expunged after a configurable amount of > > time or it matches some user or system administrator defined > > criteria. Using the NNIDEM, > > the client has no standard way to determine when the deleted flag was > > set and so can not automatically determine if the deleted message > > should be expunged after a certain amount of time (1 day, 1 week, 1 > > month...). > > You can always add a X-Deleted-On: header. Setting the internal date to the current time on append to Trash is more efficient and slightly more interoperable and already available. The X-Deleted-On header is distasteful as it provides a handle for undesirable mucking about in mailboxes and is not supported by other clients. > 2. I, for one, would not like administrators mess with mail e-mail, no > matter if I marked it deleted or not. I don't like administrators messing with my mail either; but, I don't live in that universe. At least the messing is limited to messages that I've already determined to be unnecessary by placing them in a designated location. > > The main reason for administered Trash is that once a message is in the > > Trash it is usually forgotten and the Trash becomes a diskfill. This > > occurs regardless of whether the deleted messages remain in original > > folder or have been moved to a Trash folder. > > Some mail clients have an "expunge on exit" option. This is not a > protocol problem, it is client implementation problem. Some also have an expunge on open. It is not a problem if the user can configure it as she likes or that is what our customer is requiring and users are aware of the behavior. > > While automatically expunging deleted messages is not exactly a nice > > thing to do; it is a capability that apparently system administrators > > want. > > 1. Which system administrators? The ones I have to deal with. They like the idea of having trash on which they can set limits such as number of messages, duration of existance, expunge timing, etc. System administrators like to control things so given the above capabilities most are very happy. Not having the capability to reclaim disk space used by deleted messages in the trash would mean they would take an interest in removing deleted messages in all of the user's folders. > 2. What exactly stops you from using EXPUNGE on all the folders? Nothing. Typically messages are appended to the Trash, the deleted flag set on the messages and the mailbox is expunged. Thats how the move to trash paradigm typically works. The mail systems which we produce are for corporate use and the corporation that is using the mail system has the right to make whatever mail usage policies they desire. My job is implementing those policies where possible not passing judgement on them. > > My arguments that IMAP has a nice NNIDEM that should be used instead > > of a Trash folder have gone unheeded. Having deleted messages moved > > to a real Trash > > folder provides system administrators with a single point of access > > when the disk on the mail server goes critical. Most users don't > > complain if the Trash unexpectedly disappears; however, would complain > > if all of the deleted messages in all of their folders were to > > disappear. > > What is the difference between deleted messages in Trash and deleted > messages in other folders? I am not sure if I understand... Out of sight is out of mind. There is an emotional difference. You aren't as attached to messages that you have thrown in the trash as you are to the messages in the folder even though they may have the deleted flag set. In either case you want to be able to retrieve a deleted message for a short period of time in the unlikely event that it was deleted accidentally. It is like the paper you just threw into the trash can and the one on your desk that you intend to thow away when you get around to cleaning up. If the janitor came and emptied the trash, do you complain? Probably not, unless he came to empty your trash every few minutes. If the janitor came and cleaned your desk, do you complain? Most definitely. If you do not like the janitor, how about if your co-worker came and dumped the coffee grounds into the trash can on top of your paper? You don't know how long you'll be able to safely retrieve the paper you put in the trash can; but, you expect to be able to for some period of time. A mail system that has a trash mailbox which works in a similar fashion meets the expectations of most ordinary not-particularly computer literate office people. > > Your insistence that NNIDEM is good and everything else is bad is > > beginning to sound like you are trying to purvey something that even > > though it has great technical merit still doesn't sell. It is my intent to provide a client which works or is configurable to work in which ever message deletion scheme a user is most familiar with; however, there are many limitations such as design, administration and customer requirements that must also be taken into consideration. As such, it is denigrating when people make "my way is good and any other way is bad" assertions. Regards, Mark Keasling <[EMAIL PROTECTED]>
