On Fri, 10 Oct 2003, Eric S. Raymond wrote:
Matthias Andree <ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de>:
Well, I decided to give this idea a new try anyways. If fetchmail sees
itself as mail transport rather than as MUA, it has no business checking
\Seen flags.
How do you figure that? Fetchmail's normal job is to pick up new mail,
download it, and pass it to a local MTA. What is the problem with
lookig at \Seen flags here?
Fetchmail, aiming to be an MTA, must be robust. Spam filters, other user
agents, all access the mailbox, and there is no reason (no technical, no
logical) to use fetchmail exclusively.
The protocols we use allow for bullet-proof tracking "have I seen this
mail": UIDL or UIDVALIDITY+UID. fetchmail needs to use them.
So, to solve this "problem", you want me to rely on a feature than no
POP3 servers have at all and some IMAP servers don't have. Um...no.
No. UIDL is mandatory, as is UID in IMAP.
This is not going to happen. You might win your point about UIDLs someday
if I decide I can trust that code, but this? No way.
What code? uid.c, you mean? Needs to be rewritten from scratch, with
clean interfaces. Oh, and rbtree (from Damian Ivereigh, on SourceForge,
LGPL) should be merged when that happens because linear lists are
snails.
I wonder on the "traffic" issue if fetchmail should keep a record of
UIDs from failed mail and set a steadily increasing fetch interval for
these that is clamped at 24hrs or 50 runs, whichever comes first.
And with this, you just damaged your chances of moving to
all-UIDLs-all-the-time. Design proposals that increase the amount of
persistent, fragile state that fetchmail has to track make me
break out in hives.
In how far is .fetchids fragile? With all that "saved lists" shuffling,
it indeed is unmaintainable in the shape it's in now.
The easy approach to make the stuff robust is split this up per account
and server and keep it in a ~/.fetchmail directory, and to make sure
it's never overwritten, but replaced atomically (write .new file, rename
into place).