Re: [Fetchmail-users] Using Fetchmail with IMAP

[Matthias A. <mat...@gm...>]

Am 11.12.2017 um 18:59 schrieb Kamil Jońca:
> kj...@o2... (Kamil Jońca) writes:
>
>> kj...@o2... (Kamil Jońca) writes:
>>
>>> Matthias Andree <mat...@gm...> writes:
>>>
>>> [...]
>>>> Unfortunately, fetchmail 6.3.26 cannot currently work decently in this
>>>> situation because it lacks UID + UIDVALIDITY support. There were past
>>>> contributions to add UID support but without UIDVALIDITY; so they were
>>>> worthless. Such code still needs to be written I'm afraid.
>>>>
>>> I am interested in writing IMAP UID code, and below my thoughts:
>>> [...]
>> It is my initial patch to have uid/uidvalidity support.
>> - it uses its own file to keep uid data for imap (~/.fetchids-imap)
>> - code for read / write imap uid lists was shamelessly plagiarized and
>> then changed.
>> - I have no idea how to deal with IMAP2 - it looks, that this protocol
>> have no UID concept
>> - I worked with debian's fetchmail-6.3.26 varsion as a base
>> - it was only rougly tested, especially there were no testing with 
> Attachement has been deleted. My patch is at
> https://drive.google.com/open?id=1UkPJEnvhOfKpJigTCKPpJBcR3ZBSugzM
> (it also have correction for "INBOX" mailbox)
> KJ
>
Hello Kamil,

thanks for taking the initiative. I've been meaning to respond earlier,
but real live has interfered, and unfortunately I wasn't able to tell
you in time that this should either be against the "master" branch (if
intrusive) or the "legacy_64" branch (if just an extension isolated well
from the rest) because 6.3.26 is basically a dead end, and I have merged
a patch by Rainer Weikusat to switch the slow (O(n^2)) POP3 UID list
handling to something faster. OTOH as long as IMAP UIDs are integers,
and continuous runs can be compressed (for C++ I think Boost has a
library) those POP3 UIDs have a different requirement set.

That said, I think it looks good as a proof of concept and with a few
touch-ups, and someone - possibly me - contributing a better IMAP
response parser that we can avoid matching empiric fixed strings, which
might break when some freemailer develops a different dialect of
IMAP4r1, and make the code more robust and portable. I am not asking you
to fix the IMAP parser though.

So, if you want to play with things and are happy to use Git, I propose
that you clone out from https://gitlab.com/fetchmail/fetchmail and
create a new kj-imap-uids branch there branching off RELEASE_6-3-26, and
then rebase onto either legacy_64 or master.  The interface changes you
are doing might make me wonder about "master" which is open to more
intrusive changes than legacy_64 which cannot break interfaces without
very good reasons, but legacy_64 seems to be OK since the changes seem
reasonable from skimming the patch quickly.

Regards,
Matthias