Subject: [Extra] imap4rev2: disallow "RENAME INBOX"

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 08 Nov 2018 06:37:14 -0500

This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. 
 
This one came from me. I dislike the weirdness of "RENAME INBOX Archive-foo" because of its special behaviour regarding sub mailboxes, and the auto-recreation of the source mailbox, and all that jazz. 
 
Argument in favour of keeping it - it's easier for clients, which is part of the point of IMAP4rev2 - servers have already suffered through this the first time, and will need to keep IMAP4rev1 support for a while anyway probably. 
 
Arguments for and against in response to this please. Also arguments about the suggested middleground saying that clients "SHOULD NOT" use it, or something like that - with the flip side that servers MAY reject rename of INBOX. 
 We're particularly interested in "I use this, and want to keep it" from either servers that see their clients doing it, client authors, or even users! 
 
Cheers, 
 
Bron. 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 8 Nov 2018 16:02:29 +0200

> We're particularly interested in "I use this, and want to keep it" from either servers that see their clients doing it, client authors, or even users!

Dovecot has always been rejecting this when used with Maildir format (other formats allow it):

a rename inbox plop
a NO [CANNOT] Renaming INBOX isn't supported (0.001 + 0.000 secs).

I've never heard anyone complain about it.

I've a feeling Courier is rejecting it as well, but can't check now easily.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 08 Nov 2018 09:53:50 -0500

I'm tempted to see what Gmail does too. 
 
. OK [email-masked] authenticated (Success) 
. rename INBOX oldinbox 
. OK Success 
 
Well, what do you know. They implemented it! 
 
ha... 
 
. select oldinbox 
. move 1:* INBOX 
 
...  
 
. OK [COPYUID 2 1:15214 16312:31525] (Success) 
 
So it looks like it didn't reset the UID counter on the INBOX. I didn't get the UIDVALIDITY of the INBOX at the start to compare. 
 Bron. 
 
On Fri, Nov 9, 2018, at 01:02, Timo Sirainen wrote: 
> _______________________________________________ 
> Extra mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/extra 
>

---

From: Brandon Long <[email-masked]>
Date: Fri, 9 Nov 2018 11:25:47 -0800

hey, it was in the spec, we implemented it, just removing the inbox label
and adding another one, easy peasy, about the same as that move command.
The things we didn't implement were things that were much harder (substring
searching is probably the main one) or seemed silly and hard (\Recent).

yes, we didn't reset the UID counter, I guess we could do that and the
uidvalidity, but the initial impl didn't have a good way to change the
underlying uidvalidity, so easier to leave the uid space the same.

Brandon

On Thu, Nov 8, 2018 at 6:54 AM Bron Gondwana <[email-masked]> wrote:

> So it looks like it didn't reset the UID counter on the INBOX.  I didn't
> get the UIDVALIDITY of the INBOX at the start to compare.
>
> Bron.
>
> This one came from me.  I dislike the weirdness of "RENAME INBOX
> Archive-foo" because of its special behaviour regarding sub mailboxes, and
> the auto-recreation of the source mailbox, and all that jazz.
>
> Argument in favour of keeping it - it's easier for clients, which is part
> of the point of IMAP4rev2 - servers have already suffered through this the
> first time, and will need to keep IMAP4rev1 support for a while anyway
> probably.
>
> Arguments for and against in response to this please.  Also arguments
> about the suggested middleground saying that clients "SHOULD NOT" use it,
> or something like that - with the flip side that servers MAY reject rename
> of INBOX.
>
> We're particularly interested in "I use this, and want to keep it" from
> either servers that see their clients doing it, client authors, or even
> users!
>

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 20 Nov 2018 14:00:07 -0800

On 9 Nov 2018, at 11:25, Brandon Long wrote:
> searching is probably the main one)

A very good point. For IMAP4rev2, can we loosen the specified 
requirements for searching? At a minimum, I'd like to see word-based 
searching for message content to be considered valid by the standard 
(that is, a search for "ood" won't necessarily match a message 
containing the word "good").

		- Chris

>> This is one of the open issues from imap4rev2 - which extensions 
>> should be
>> part of the mandatory baseline.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=oP5PJjpDZQDR4dtwrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=Dh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdIx7J0&e=
>>
>>
>> --
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=oP5PJjpDZQDR4dtwrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=Dh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdIx7J0&e=
>>

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=oP5PJjpDZQDR4dtwrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=Dh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdIx7J0&e=