Re: [fetchmail-devel] [PATCH] handle imap EXPUNGE better

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

Sunil Shetye <sh...@bo...> writes:

> A good imap server can handle two email clients accessing the same
> mailbox and reports the mails deleted by one email client correctly to
> the other email client.
>
> However, fetchmail cannot handle this unexpected deletion of mails.
> This is because fetchmail caches which mails are new and the size of
> those new mails. This caching is required to give a better
> performance, but leads to unexpected results when another email client
> is writing to the same mailbox:
>
> - An old mail could be delivered instead of a recent mail.
>
> - fetchmail passes the wrong size to the SMTP server in the MAIL FROM:
>   command. If the SMTP server has size restrictions, a wrong mail will
>   get rejected!
>
> - "fetchmail -vv" reports that there is a mismatch in the expected and
>   received message sizes.
>
> This patch causes fetchmail to quit the poll if there is a mismatch in
> the count of mails being deleted.

Well, OK. We'll take this as a safety measure, but I maintain that the
real solution is to properly cache the mailbox state and update it as
untagged responses come in.

I've merged the patch onto branches/BRANCH_6-3 for the nonce, and will
update the trunk from there after the 6.3.3 release.

> This patch also handles servers which do not report RECENT on EXPUNGE
>in a better way. Now, recentcount is counted down on EXPUNGE of each
>mail along with count. This way, recentcount need not be reset to zero
>if the server does not give a new report of RECENT mails.
>
> This patch has been tested by running two fetchmails on the same
> mailbox!

Sunil Shetye <sh...@bo...> writes:

>> It would be better to update the cache properly (watching out for
>> eventual iterator variables that need to be decremented, too) and
>> continue. From our own cached flags we should be able to deduce if the
>> expunged message was recent or not. If we don't know and the server
>> expunged a different mail.
>> 
>> Now, before you go delve into the code and hack away, take a step back
>> from the blackboard to see the whole picture: the RECENT flags are just
>> crap if several clients are accessing the mailbox. What happens to the
>> RECENT count if we reselect the mailbox? Can we actually use it? Do we
>> need to check \Seen flags instead, for lack of UID support in IMAP?
>
> I plan to implement the recentcount as a difference between EXISTS
> count at end and beginning of poll. I can work on that only after this
> patch is accepted. At that time, your point will also get implemented.

Sounds good.

> fetchmail uses the RECENT only to decide
> a) whether to repoll at the end of mailbox poll
> b) whether to come out of IDLE (or NOOP look) while waiting for new
> mail.

> The UID code is not going to help here as this would require getting
> the full list of UIDs at the end of mailbox poll (and every minute,
> with "idle"). The RECENT code is much cleaner as imap servers reports
> the RECENT count consistently and correctly.
>
> The RECENT count is not being used to decide which mails are new. It
> is only being used at the end of the poll or while idling for new
> mail.

OK.

-- 
Matthias Andree