MBOX-Line: From dwhite at olp.net  Mon Jun 14 12:46:00 2010
To: imap-protocol@u.washington.edu
From: Dan White <dwhite@olp.net>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] Re: IMAP MOVE extension
In-Reply-To: <201006142135.58808.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006141248.11054.witold.krecicki@firma.o2.pl>
	<20100614192755.GC4182@dan.olp.net>
	<201006142135.58808.witold.krecicki@firma.o2.pl>
Message-ID: <20100614194600.GD4182@dan.olp.net>

On 14/06/10?21:35?+0200, Witold Kr?cicki wrote:
>On Monday 14 of June 2010 21:27:55 Dan White wrote:
>> On Mon, 14 Jun 2010 12:22:36 +0200 Witold Kr?cicki wrote:
>> 
>> In an ISP setting, I generally recommend to our users that they do not use
>> a Trash folder, since they tend to forget to clean it and then often open
>> trouble tickets when they're over quota and can't figure out why. But we
>> still give them the option of using it if they choose to.
>> 
>> We have a mix of POP3 and IMAP in our environment, but I'd guess that
>> there's probably a majority of our IMAP users who do not make use of the
>> Trash model (we decided to disable the use of Trash in our webmail client
>> by default).
> 
> A model in which messages are deleted from trash after several days is a 
> solution to that problem.

No argument with that. We actually do that on a voicemail server, but
choose not to (yet) on our ISP server. However, my point is that customers
rarely miss it. We get far fewer complaints from customers who have no
Trash folder, compared to those that do.

>> >> 2) I concur that people like the trash can metaphor, and would encourage
>> >> client authors to *use* IMAP's facilities to model same.
>> > 
>> > But they don't.
>> 
>> My client can probably do either, depending on how I configure it.
>> Thunderbird can do either depending on configuration
>> (mail.server.default.delete_model).  The Trash can is popular in many
>> scenarios, but it's not universal either.
> 
> But it is popular.

Again, no argument here.

>> >> a) MOVE is simpler for client authors. However, client authors would
>> >> still have to move messages without this extension, hence have to
>> >> provide multiple codepaths to achieve the same - really quite simple -
>> >> facility.
>> > 
>> > That's their choice, it's an EXTENSION hence they don't HAVE to use MOVE
>> > functionality.  Yet MOVE enables user to move messages even if they're at
>> > their quota limits, which is currently impossible with enforced quota
>> > limits.
>> 
>> As someone previously pointed out in this thread, setting a different quota
>> root on a user's Trash folder would make that possible. Even without that
>> work around, a more typical scenario involves the user making a decision
>> about which emails they can live without and having them delete those
>> emails.
> 
> You're thinking about power users. 'Regular Joe' wants trash folder. And he 
> doesn't understand why a simple 'move to trash' or 'move to another folder' 
> (which should be 'move') causes his quota to be exceeded.

Regular Joe may have never used a Trash folder, or care why it's there.
Power users *will* know if it's there.

"Move to <folder drop down list>" is a common function of our webmail
client and of many email clients. None of them (that I have used) depend on
an IMAP move command.

-- 
Dan White

