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

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

Jakob Hirsch schrieb am 2006-03-06:

> > 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?

Probably, although this might become a tagged format so it's extensible.
The current UID implementation is very inefficient and needs to be
revised.

> > 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.

Magic only if nothing is configured explicitly.

> > 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.

fetchmail's foremost task is to fetch every message, exactly once. This
cannot be achieved with server-side tracking.

> > (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.

LAST is a nonstandard extension. Perhaps I'll keep it in as fallback for
--keep on servers that don't talk UIDL, but IF it keeps in, only as last
resort.

> > talking RFC-1939 (POP3)/1734 (AUTH)/2449 (TLS)/2222 (SASL).
> 
> But things like ntlm/msn authentication and pop3s/imaps are still supported?

Probably yes, modulo the NTLM bugs that got reported.

-- 
Matthias Andree