MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 12:50:01 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] Re: IMAP MOVE extension
In-Reply-To: <20100614194600.GD4182@dan.olp.net>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006142135.58808.witold.krecicki@firma.o2.pl>
	<20100614194600.GD4182@dan.olp.net>
Message-ID: <201006142150.01600.witold.krecicki@firma.o2.pl>

On Monday 14 of June 2010 21:46:00 Dan White wrote:
> 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.
The number of users that are crying to our client support that they accidently 
deleted some important messages would probably go waay up if we wouldn't use 
deleting to trash folder by default
 
> "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.
Maybe because there's no IMAP move command?

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

