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

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

Jakob Hirsch <jh...@pl...> writes:

> Anyway, I really think fetchmail should by default simply retrieve all
> message, using standard MUA mechanisms: RETR and DELE; no TOP, UIDL or
> LAST. This makes sure that fetchmail works with as much servers as
> possible without any tweaking.

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.

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.

> If one wants 'keep', UIDL/RETR should be used, with fallback to
>LAST/RETR. And there should probably be an option to force one of UIDL
>or LAST (uidl/nouidl?) so the user can enfore client or server side
>tracking (with fetchmail bailing out if the requested option is not
>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
into a conflict so serious that fetchmail cannot resolve it on its own.

I share the view on RETR becoming default.

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.

I also think I'll be discontinuing obsolete commands such as "RPOP"
(insecure, removed with RFC-1460 in 1993), "LAST" (removed with RFC-1725
in 1994, inconsistent behavior with RSET) in 6.4.X.  fetchmail should be
talking RFC-1939 (POP3)/1734 (AUTH)/2449 (TLS)/2222 (SASL).

Massively slashing old protocols may cause me to call the next release
7.0.0 rather than 6.4.0 so people will be warned it's a major
upgrade. The exact roadmap for the next fetchmail release isn't fixed yet.

-- 
Matthias Andree