Complete.Org: Mailing Lists: Archives: offlineimap: April 2003:
Re: offlineimap / uw-imapd / mutt
Home

Re: offlineimap / uw-imapd / mutt

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Cowie <andrew@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Cc: offlineimap@xxxxxxxxxxxx
Subject: Re: offlineimap / uw-imapd / mutt
From: John Goerzen <jgoerzen@xxxxxxxxxxxx>
Date: Sun, 20 Apr 2003 20:49:22 -0500

On Mon, Apr 21, 2003 at 11:33:35AM +1000, Andrew Cowie wrote:
> > My recommendation is to avoid UW-IMAPd.  Others have reported this problem
> > before.
> 
> The trouble with a recommendation like that is that many people *can't*
> avoid whatever their upstream mail server is.

I know, and I've had to deal with these problems many times before.

Have you tried using mutt talking directly to the IMAP server like my other
less-intrusive option suggested?  A quick workaround could be right around
the corner :-)

My experience is that one can usually manage to make UW-IMAPd work with
OfflineIMAP by handling UW with a delicate gloved hand...

Anyway, the problem is, if the IMAP server can't handle UIDs properly, there
is absolutely nothing a tool like OfflineIMAP can do.  Nothing, that is, if
data integrity is considered important.

Mail readers that simply connect to the server on each session don't have
this problem, because they have no need to correlate statuses between
sessions.  So people running, say, Pine against a UW IMAPd server won't see
a problem at all, and as that's their target audience, they probably figure
it's good enough.

Programs like KMail keep a status cache, but since they're not correlating
anything, if the UID validity is broken, it just regenerates it at only a
cost to performance.

OfflineIMAP, however, uses the UID to match a remote message with a message
on a local machine.  The UID is the only reliable method of doing this.  And
incidentally, that is why OfflineIMAP can never support POP (POP provides no
equivolent of a UID).

If the UID is broken, OfflineIMAP could take a guess (perhaps based on
Message-ID), but it's just that -- a guess.  It could be confused by various
things (duplicate messages, messages with no Message-ID, etc), and the
result would be that there would be a risk of data loss or corruption.

So that is why I say OfflineIMAP can not provide a good workaround for a UID
problem.  A server that loses UID information is simply not compatible with
OfflineIMAP.

Fortunately, UW IMAP does not *always* lose UID information.  If you never
use any other client to access its repository directly, are careful about
how you treat it, etc., you can end up with a well-working OfflineIMAP-UW
sync.

But like I said, if the problem arises when you point mutt directly at the
mailbox, the easiest answer is "don't do that then."  It causes a condition
OfflineIMAP is fundamentally unable to work around.  So if you just access
the mailbox through UW IMAP -- mutt -f '{localhost}' -- it should work for
you.

-- John


[Prev in Thread] Current Thread [Next in Thread]