PARTIALLY REMOVING MAXAGE (was: [PATCH v4] make maxage use UIDs to avoid timezone issues)

[Janna Martl]

On Fri, Mar 27, 2015 at 02:54:41PM +0100, Nicolas Sebrecht wrote:
>>                                           (3) it doesn't even always
>> work -- even after sorting, I still found a pair of local messages whose
>> remote counterparts weren't in the same order (?).
>
>And here I continue about my point above.
>
>I'm not surprised. As already discussed before, IMAP servers are
>supposed to assign ascending UIDs to upcoming mails. Keeping the order
>is not a pre-requisite nor is it defined in the RFCs. So, we would be
>wrong to assume it's a valid design.

I'm confused; the IMAP spec says:

>1) Unique identifiers MUST be strictly ascending in the
>   mailbox at all times.  If the physical message store is
>   re-ordered by a non-IMAP agent, this requires that the
>   unique identifiers in the mailbox be regenerated, since
>   the former unique identifiers are no longer strictly
>   ascending as a result of the re-ordering.

and you told me that this is not the kind of thing that Gmail messes up.

>As a consequence to all of these, it appears that applying maxage in the
>IMAP/IMAP or IMAP/Gmail cases is WRONG. We are far beyond implementation
>issues. It's BROKEN BY DESIGN. We should NOT have supported this thing at
>all in the first place.
>
>
>Unless someone PROVES me that I'm wrong, I'm in favour to forbid the
>maxage feature outside the case of a local Maildir.

I have a feeling that people are more interested in using the IMAP-IMAP
thing to copy the contents of one account to a new account. I wonder if
we could only support using maxage in this case, i.e. when one of the
accounts is empty. That would take away most of the edge cases, and if
the messages show up in the other account slightly out of order, it's no
big deal; it could have happened naturally, and that's exactly what the
min(uid) thing is good at dealing with in the IMAP-Maildir case.


-- J.M.