79 lines
3.3 KiB
Plaintext
79 lines
3.3 KiB
Plaintext
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
|
|
|