From f6a119dce885eb354c4e046ac32b8e8abb11e3e2 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 25 Sep 1996 16:41:14 +0000 Subject: Gotcha. svn path=/trunk/; revision=139 --- NEWS | 54 ++++++------------------------------------------------ 1 file changed, 6 insertions(+), 48 deletions(-) (limited to 'NEWS') diff --git a/NEWS b/NEWS index 8b7c32b6..382962b9 100644 --- a/NEWS +++ b/NEWS @@ -1,51 +1,9 @@ - NEWS - -To-do list: - -1. The IMAP support is naive. Chris Newman, one of the IMAP maintainers, -criticized it as follows: -------------------------------- CUT HERE ----------------------------------- -On Wed, 18 Sep 1996, Eric S. Raymond wrote: -> 1. I do one one SELECT, at the beginning of the fetch. -> -> 2. I assume that I can pick an upper bound on message numbers from the EXISTS -> reponse. - -Correct. - -> 3. If there is an UNSEEN nnn trailer on the OK response to SELECT, I assume -> that the unseen messages have message numbers which are the nnn consecutive -> integers up to and including the upper bound. -> -> 4. Otherwise, if the response included RECENT nnn, I assume that the unseen -> messages have message numbers which are the nnn consecutive integers up to -> and including the upper bound. - -These will only work if your client is the only client that accesses the -INBOX. There is no requirement that the UNSEEN and RECENT messages are at -the end of the folder in general. - -If you want to present all UNSEEN messages and flag all the messages you -download as SEEN, you could do a SEARCH UNSEEN and just fetch those -messages. - -However, the proper thing to do if you want to present the messages when -disconnected from the server is to use UIDs. To do this, you remember the -highest UID you have (you can initialize to 0), and fetch everything with -a higher UID. Ideally, you shouldn't cause the SEEN flag to be set until -the user has actually seen the message. This requires STORE +FLAGS SEEN -for those messages which have been seen since the last update. - -The key thing to remember is that in IMAP the server holds the -authoratative list of messages and the client just holds a cache. This is -a very different model from POP. -------------------------------- CUT HERE ----------------------------------- -If we ever decide that concurrent runs need to work safely, this will have -to be fixed. - -2. Support IMAP4 extensions for secure challenge-response. - -3. Option to enable EMACS-like user folder versioning on each run. + To-do list: + +Support IMAP4 extensions for secure challenge-response, once they're actually +standardized. + + Release Notes: fetchmail-1.0 (Mon Sep 23 19:54:01 EDT 1996): -- cgit v1.2.3