Subject: Re: [Extra] SAVEDATE: how to handle mailboxes without support

From: Stephan Bosch <[email-masked]>
Date: Thu, 12 Apr 2018 09:51:23 +0200

Hi Bron,

Op 30-3-2018 om 4:46 schreef Bron Gondwana:
> This is the only outstanding issue for this draft.  I quite like the 
> idea proposed during IETF101, a boolean search key SAVEDATESUPPORTED 
> which can be used to create search queries that work for both 
> mailboxes that do and don't support SAVEDATE.

Yes, I like it too.

> There are two proposed ways to handle mailboxes where 
> SAVEDATESUPPORTED is false.  One option is that SAVED* searches always 
> return false as well:
>
> e.g.
>
> 1 SEARCH OR SAVEDSINCE 01-Jan-2018 AND NOT SAVEDATESUPPORTED SINCE 
> 01-Jan-2018
> -- find everything added to this mailbox since the start of the year, 
> falling back to INTERNALDATE only if SAVEDATESUPPORTED is false.

There is no "AND" in IMAP. :)

But other than that, I see what you mean.

> 2 SEARCH SAVEDBEFORE 01-Jan-2018
> -- find everything to purge that's been in this mailbox since before 
> this year, but only if SAVEDATE is supported so we never purge 
> anything that may have been old, but only moved here recently.

Right.

> The alternative proposal is that SAVED* keys act on INTERNALDATE 
> rather than SAVEDATE if SAVEDATESUPPORTED is false.  I can also work 
> with this, by using something like:
>
> 1 SEARCH SAVEDSINCE 01-Jan-2018
>
> 2 SEARCH SAVEDATESUPPORTED SAVEDBEFORE 01-Jan-2018
>
>
> Looking at these two options, I'm actually quite OK with either!  The 
> main concern whether people will purge too much mail, or not find 
> enough mail, depending which is which.

Yes, either would be fine. It is just a matter of having clear semantics 
and careful SEARCH query construction.

Does anybody have a real preference for either of these? Otherwise, I'll 
do what Dovecot is currently doing: which is the second option I believe 
(SAVEDATSUPPORTED is obviously not supported there yet).

Regards,

-- 

Stephan Bosch
Senior Developer

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kenttä
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 12 Apr 2018 17:58:08 +1000

On Thu, 12 Apr 2018, at 17:51, Stephan Bosch wrote:
>> This is the only outstanding issue for this draft.  I quite like the>> idea proposed during IETF101, a boolean search key SAVEDATESUPPORTED>> which can be used to create search queries that work for both
>> SAVEDATESUPPORTED is false.  One option is that SAVED*
>> searches always>> return false as well:
>> 
>> e.g.
>> 
>> -- find everything added to this mailbox since the start of the year,>> falling back to INTERNALDATE only if SAVEDATESUPPORTED is false.
> 

Yeah, I guess I meant:

1 SEARCH OR SAVEDSINCE 01-Jan-2018 (NOT SAVEDATESUPPORTED SINCE
01-Jan-2018)
>> -- find everything to purge that's been in this mailbox since before>> this year, but only if SAVEDATE is supported so we never purge
>> rather than SAVEDATE if SAVEDATESUPPORTED is false.  I can also work>> with this, by using something like:
>> 
>> Looking at these two options, I'm actually quite OK with either!  The>> main concern whether people will purge too much mail, or not find
> Yes, either would be fine. It is just a matter of having clear
> semantics> and careful SEARCH query construction.
> 
> Does anybody have a real preference for either of these?
> Otherwise, I'll> do what Dovecot is currently doing: which is the second option
> I believe> (SAVEDATSUPPORTED is obviously not supported there yet).

Existing behaviour seems perfectly fine to me.  If you're using SAVED*
searches you'll know about the spec one would hope.
And most servers will do one or the other... though Cyrus at least will
allow mailboxes to be upgraded individually, and if you're dealing with
an old format mailbox that has no space in the index for storing
SAVEDATE then we'll answer false to the supported query.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 12 Apr 2018 19:02:26 +1000

I see I was a little unclear here! I support choosing option 2 and
matching existing dovecot behaviour.

On Thu, 12 Apr 2018, at 17:58, Bron Gondwana wrote:
>>> This is the only outstanding issue for this draft.  I quite like the>>> idea proposed during IETF101, a boolean search key SAVEDATESUPPORTED>>> which can be used to create search queries that work for both
>>> SAVEDATESUPPORTED is false.  One option is that SAVED* searches
>>> always>>> return false as well:
>>> 
>>> e.g.
>>> 
>>> -- find everything added to this mailbox since the start of
>>> the year,>>> falling back to INTERNALDATE only if SAVEDATESUPPORTED is false.
>> 
> 01-Jan-2018)> 
>>> -- find everything to purge that's been in this mailbox since before>>> this year, but only if SAVEDATE is supported so we never purge
>>> rather than SAVEDATE if SAVEDATESUPPORTED is false.  I can also work>>> with this, by using something like:
>>> 
>>> Looking at these two options, I'm actually quite OK with
>>> either!  The>>> main concern whether people will purge too much mail, or not find
>> semantics>> and careful SEARCH query construction.
>> 
>> Otherwise, I'll>> do what Dovecot is currently doing: which is the second option I
>> believe>> (SAVEDATSUPPORTED is obviously not supported there yet).
> 
> searches you'll know about the spec one would hope.> 
> And most servers will do one or the other... though Cyrus at least
> will allow mailboxes to be upgraded individually, and if you're
> dealing with an old format mailbox that has no space in the index for
> storing SAVEDATE then we'll answer false to the supported query.> 
> Cheers,
> 
> Bron.
> 
> --
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 16 Apr 2018 22:08:06 +0200

> matching existing dovecot behaviour.

Ok, I will adjust the document accordingly.

>>>     always
>>>     either!  The
>> Existing behaviour seems perfectly fine to me.  If you're using 
>> SAVED* searches you'll know about the spec one would hope.
>>
>> storing SAVEDATE then we'll answer false to the supported query.
>>
>> Cheers,
>>
>> Bron.
>>
>> --
>> [email-masked] <mailto:[email-masked]>
> _______________________________________________
> Extra mailing list
> [email-masked]