> > They even went in and > > added some feature to auto purge the Trash folder after x days or whatever.
> > I wouldn't want to imagine the number of calls/emails my clients would send
> > when they find out a message they wanted trashed but saved got nuked.
That feature is called expire. If you customers would not tolerate it,
don't activate it. It is quite useful, though, and if I find time,
I will implement it for Exim/Maildir.
> Immediate deletion or deletion upon logout is probably a bit too much,
> but 7, 10, or 14 days is plenty of time to realize an error. The Trash
> folder is a convenience incase you make a mistake, it is not for
> storage.
That is one application. Another would be a mail archive where you
wish to store e.g. the last 12 months of mail. Any delivery could purge
mails older than that, even if you are on vacation.
Not accounting the Trash folder may have another reason: IMAP has no
"move" operation. Clients do not offer a move, just copy, for that reason
(at least I never saw move). Deleting mails with the chance to get
them back was supposed to be done by the deleted flag, but these days,
people are used to a Trash folder instead of a flag. If Trash would be
accounted, the client might fail to copy a mail in there and a dialog
might pop up:
"Moving mail to Trash failed for its size, delete it right now?"
People don't like that. Not accounting Trash avoids that problem, as
the copy will always work. Personally, I think that is a good reason
for an IMAP server at most not to account it when copying mail in there,
but doing so in any other situation. I don't see a reason why Exim as
a MTA should not account Trash.
Exim is full of those little options like maildir_tag and quota_size_regex,
so I guess most likely we will see another one to specify which
directories to ignore during quota calculation. That's fine with me.
