<DKIM> Re: <DKIM> Re: <DKIM> unified inbox in local repo

[J. Tull]

On +0200, Nicolas Sebrecht wrote:
> On Sat, Jul 28, 2018 at 08:44:25AM +0000, J. Tull wrote:
[ ... ]
> >                                                         If not would my
> > request require a lot of efforts?
> 
> I can't say. I'm not sure what you have in mind.
> 
> The best I can think of is the X-Offlineimap header trick that sounds
> the nearest to your purpose. You might like to start by studying this
> mechanism. This allows tracking the emails when UIDPLUS is not
> available (likely rare these days BTW).
> 
> offlineimap is designed to rely on UID because that's what IMAP provides
> to work on the emails remotely. Working on any other parameter would
> require to request the remote servers with additional requests. I'm
> pretty sure there would be no other choice and this will strongly slow
> down the sync process.
> 
> There's no object of "email" in the code. Basically, int values for the
> UIDs are passed everywhere (sometimes in tuples alongside other values
> like flags). This could be the most serious obstacle to get the things
> done because there might be a lot of code to update.
> 
> Finally, syncing is not easy. This looks like easy but it's not. Even
> when working with UIDs. At some point in time we might realize the
> purpose is broken by design. This already happened in the past for a
> feature not relying on UIDS _1.
> 
> Hope this helps.
> 
> 
> _1: http://www.offlineimap.org/devel/2015/04/14/why-we-changed-maxage.html
> 
> -- 
> Nicolas Sebrecht

ok, this is indeed more helpful. I read your article on maxage and
indeed it sounds like imap is broken by design. But the failure exposed
is not the problem to my request. My request is about getting
information such as Message-ID, subject, date and do the comparison of
some or all these values for each email entry on remote and locally to
know whether it should be downloaded. In my case i've faced only once a
failure with message-ID, so i think it will be fine without date and
subject. But still it would be good to have these values too optionally
to strenghten the comparison process as needed.