[fetchmail-devel] Re: [fetchmail-users] Re: RETR with UIDL

[Jakob H. <jh...@pl...>]

Matthias Andree wrote:

> UIDL is a pretty standard MUA (used by major MUAs) mechanism for "keep
> messages on server" setups, and it's very likely I'll make UIDL default
> in future versions.

Sure, even OE supports it. But still, the default operation of all
client I know is "download and delete", so UIDL is not used. The major
use of fetchmail is being some kind of MUA "proxy" (not in technical
sense), so it should (by default) behave like a (default) MUA.

> I hope we can also add the often-requested "delete after N days" that
> ESR refused (probably because he was scared of the implications with the
> long-winding UID code), but I'm not sure if time permits that for 6.4.X.

Yet another MUA feature. :)

How are you going to do this? Adding a third column to the fetchids file?

>> available on the server). The magic fetchmail does is nice and works in
>> most cases, but final control should be left to the user.
> 
> The user should not need to care about protocol details before he runs

He should not, but often enough he has to. I prefer to have full control
instead of having to work around some program's magic. But I understand
that my view is surely not the same as some usual user's. I hope it's
possible to satisfy both user groups.

> Server-side tracking is a constant source of troubles with respect to
> interrupted connections, software faults, aborts, reboots, any other
> things, and relying on POP3 server state beyond UIDL just doesn't work
> well, so everything will be switched to client-side tracking.

Not that I care much about that, but server-vs-client side tracking is
not only an implementional difference, but also a functional one, so I'd
be reluctant to rip out SST. Some broken servers should not be a reason
to abandon a feature.

> (insecure, removed with RFC-1460 in 1993), "LAST" (removed with RFC-1725

Usually I agree to get rid of old stuff, most of the time they are
kludges with incosistent behaviour and are replaced by a superior
mechanism. But that's not true for LAST, which has no 100% (in POP3).
And it's still supported by modern servers like Dovecot.

> talking RFC-1939 (POP3)/1734 (AUTH)/2449 (TLS)/2222 (SASL).

But things like ntlm/msn authentication and pop3s/imaps are still supported?