From: Matthias A. <mat...@gm...> - 2005-08-31 01:04:10
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Matthias Andree's mail on Tue, Aug 30, 2005 at 10:09:19AM +0200: >> > Here, I am assuming a setup like: >> > >> > poll server >> > protocol imap # or "pop3 no uidl" >> > fetchall >> > limit 1000000 >> > flush # this has been put to delete oversized only >> > >> > Without the 'flush' option, mails which are read through another email >> > client also get downloaded without problems. With the 'flush' option, >> > such apparently read mails get deleted. >> >> Yup. There's also a difference between "flush" and "nokeep". I believe >> if it's not deliberate, then it's at least useful enough to warrant >> further documentation. > > I think there is some misunderstanding here. The change made in r4173 > is reintroducing a bug which had been removed and encouraging users to > use the 'flush' option without documenting that even mails under > 'limit' can get lost permanently. > > The 'flush' option is dangerous because it can delete mails which have > never been downloaded previously by fetchmail. > The 'flush' option is supposed to delete previously downloaded mail. > fetchmail thinks a mail has been previously downloaded if its \Seen > flag is set. Thus, the 'flush' option will delete all \Seen mails. I don't think there is a misunderstanding. I am well aware that --flush is dangerous, and I think it can bear some more explicit wording that it is. Perhaps I see the problem smaller than it currently is because I don't subscribe to ESR's pushing people towards IMAP, and I am only using fetchmail for POP3. I do need fetchmail-side tracking of seen mail for fetchmail, but I don't see this happen in 6.3.0. > However, when a user uses another email client to check the users' > remote mailbox, the \Seen flag gets set here too. In this case, the > mails which have been viewed remotely but not downloaded yet too will > get deleted. In short, the 'flush' option will in this case delete > mails which have not been downloaded even once. Right. > In r4173, the 'flush' option is being connected to the 'limit' option. > But, the point is if a user add 'flush' to the rc file (or, on the > command line) just to delete oversized mails, mails seen through other > email clients can get deleted without any warning. > > [The above comments are applicable only when uidl is off. Obviously, > when uidl is used, fetchmail does not use the server side \Seen flag > at all.] Unfortunately, these preclude one another. The UIDL option only works for POP3 which does not know \Seen flags, IMAP on the other hand does not support UIDL at all. We seem to agree that we both want fetchmail to track, on its inbound side, which messages it has fetched and which it has not. So for the time being, until we fix IMAP to use client-side tracking and get rid of all server-side tracking junk in POP3 and IMAP, we should just document this problem in the --flush section, and put a pointer into the BUGS section. Current wording, in roff man(7) format: .TP .B \-F | \-\-flush POP3/IMAP only. This is a dangerous option and can cause mail loss when used improperly. It deletes old (seen) messages from the mailserver before retrieving new messages. Warning: This can cause mail loss if you check your mail with other clients than fetchmail, and cause fetchmail to delete a message it had never fetched before. Similarly, if your local MTA hangs and fetchmail is aborted, the next time you run fetchmail, it will delete mail that was never delivered to you. You should probably not use this option in your configuration file. What you probably want is the default setting: if you don't specify '-k', then fetchmail will automatically delete messages after successful delivery. This option does not work with ETRN and ODMR. -- Matthias Andree |