Re: [Fetchmail-devel] IMAP and UIDs

[Peter G. <pg...@gm...>]

Nevermind about storing lists for UIDs. I had forgotten about UIDNEXT
and ranged fetches.

So I think the minimum required state for each folder is simply the
last seen value of UIDNEXT. Given that this is quite a bit different
than the lists of UIDs that are being tracked in fetchids, we may
indeed want a separate file for this stuff. I suppose we could live
alongside the existing fetchids scheme by encoding these values as a
fake UID. In this case, the fetchids file would contain entries like
this the following (with a POP account to start things off to show
contrast):

    pg...@po... some-pop-uid-1
    pg...@po... some-pop-uid-94
    [...]
    pg...@gm... some-folder/1234567890/14
    pg...@gm... some-folder/1234567890/17
    [...]

Peter

On Thu, Aug 25, 2016 at 9:34 PM, Peter Griess <pg...@gm...> wrote:
> Hi,
>
> I'm thinking of taking a stab at the "Let IMAP code use UID and
> UIDVALIDITY rather than relying on flags that everyone can alter" bug
> since relying on the \Seen state is hurting my multi-client workflow.
>
> I have a few questions before I get started
>
> 1. Do we need to tackle UIDVALIDITY storage and validation as part of
> this? Since client-side handling UIDVALIDITY changes is had to do
> correctly, most (all?) IMAP servers don't do this unless they
> absolutely have to (e.g. there has been some sort of corruption in
> their underlying storage layer). If we can punt on UIDVALIDITY, we can
> store IMAP UIDs similarly to how we handle POP UIDs. Any advice here?
>
> 2. POP UIDs are alphanumeric strings. IMAP UIDs are unsigned 32-bit
> integers. In order to re-use as much of the existing idlist code as
> possible, I was thinking of storing UIDs as strings, e.g. via
> sprintf(id, "%lu", uid). Not my favorite solution but it should be
> less invasive than other ideas (e.g. making 'idlist.id' a union).
>
> 3. For the configuration impact of this, allowing --uidl to affect
> IMAP sessions would be the natural choice except that it may have
> unexpected consequences for users who were relying on that being a
> no-op. In this case the consequence would be that they would have an
> idfile get populated. I think this is probably okay as long as we
> preserve the existing behavior that marks fetched messages as seen. I
> think we should add a new --leave-unseen flag that allows uses to
> opt-in to marking messages as un-seen after fetching.
>
> Thanks,
> Peter