Re: [fetchmail-devel] [fetchmail-users] "retained" in fetchmail log

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

Am 01.03.2013 08:23, schrieb Pierre Frenkiel:
> On Thu, 28 Feb 2013, Matthias Andree wrote:
> 
>> Arguably, if fetchmail knows that _all other_ messages have been
>> deleted, it could delete this folder internal data message because there
>> is no sensible mailbox state left.
>>
>> Arguably, the server software could also hide this special message so
>> that clients do not need to bother with server's idiosyncrasies.
>>
>   Actually, when I went to the server (via webmail) I saw that
>   the X-IMAP message was the only one remaining. IMHO, fetchmail
>   should know that also.

Greetings,

I have revisited the UWIMAP FAQ, and found items 6.14, 6.15 and 7.44 of
interest:

<http://www.washington.edu/imap/IMAP-FAQs/index.html#6.14>

I am now considering what to do with the next somewhat-incompatible
fetchmail release.

It would appear that the whole story developed out of this qpopper <->
uwimapd incompatibility, where qpopper 2.53 and older exposed the folder
internal data, whereas UW's ipop3d would not.

qpopper 2.53 and older should have long since been phased out, qpopper
3.0 (released in 2000, 13 years ago) was changed to fix that
incompatibility, and the recommendation is that versions older than 3.0
not be used;  qpopper 4.0 would also improve server-side performance (or
so the release notes claim) by caching a mailbox/message index.


Now, what am I to do with a future fetchmail 7.0 release?

I see these alternatives:

A1 - the obvious option would be to add a "noretain" keyword that would
tell fetchmail to never retain messages.

A2 - the less obvious option I have suggested, and that is to require
that servers do not expose their internals to clients, and remove the
kludge code in fetchmail for good (although it is tiny enough to not
care about code size).

A3 - I might also, instead of A1, default this code to off and add a
"kludge-retain-folder-internal-data" option, which would be somewhat
quieter than in fetchmail 6.3.X.

Opinions?
(beware: reply-to: fet...@li... set,
you must be subscribed there if you want to reply).

Best regards
Matthias Andree