Brian Candler wrote:
On Thu, May 20, 2004 at 02:42:19PM -0700, Clint Sharp wrote:
As I read it, the 'CAN change' gives permission for the IMAP server to
recover from a loss-of-state condition (e.g. the file containing the UIDs is
deleted from some reason).
However the IMAP RFCs have been plagued with ambiguities, and even after
several revisions still are...
The comment about disconnected operation makes it pretty clear that the
intention is that UIDs should be persistent between sessions though. If they
are renumbered every time, then effectively they look like completely new
messages each time.
That's correct. This was the case after an expunge on UW for me,
however, I realize now it was because of mail.txt format. Should have
realized that during testing (however, I converted to mail.txt format on
that box so long ago I had forgotten about it). Doing the same on a
test account on the same box in mbox format reveals that a standard UW
Imap mailbox supports offline operation just fine.
Ah, then UW IMAP doesn't support disconnected operation.
You say you've tried one other IMAP server (Exchange), and it does implement
this properly. I can tell you that courier-imap does too. I would imagine
that actually most IMAP servers support this mode of operation.
Probably so. I just botched the test environment, which is obvious to
me now.
Well, IMAP has more than one mechanism defined to detect this:
- The \Seen flag
- The UID mechanism
I personally don't see a need for a third, as it violates the spirit of the
protocol (i.e. the protocol designers put those features in for a purpose).
Perhaps if fetchmail had a 'plug-in' type architecture then unusual or
specialised configurations like this could be more easily supported.
POP3 supports three, although it seems to be working around protocol
limitations. I'd probably stick with a hashed-headers method, as I'm
99.9% certain this will eliminate duplicate mail (after having problems
with using IMAP's UIDs I actually implemented a version of what Matthias
has been suggesting for several months on this list). However, like I
said earlier I'm going to implement a version using IMAP UIDs as well.
I also need to move some of the copy and paste code I did in imap.c to
more generic functions, so we're not maintaining two versions of it
(pop3.c and imap.c). That should probably be ready sometime next week.
If you were asking me (no one is, but I'll offer my opinion anyways),
IMAP \Seen tracking is the wrong way for fetchmail to determine whether
it has seen a message. I think by default people would prefer to not
have their mailbox visibly affected by fetchmail with the keep flag set
in IMAP (I know I was expecting it not to, which is why I added this
patch). With IMAP UID support all the former concerns with bandwidth
etc would be eliminated and I'd think that the \Seen flag method should
be deprecated at that point (this is only valid if keep is set).
Clint
Regards,
Brian.