-
Notifications
You must be signed in to change notification settings - Fork 2
Frequently Asked Questions
Here are answers to some of the most frequently asked questions about OfflineIMAP
See the information on the Home page.
OfflineIMAP has a multithreaded sync, so it should have very nice performance.
OfflineIMAP versions 2.0 and above contain a multithreaded system. A good way to experiment is by setting maxsyncaccounts to 3 and maxconnections to 3 in each account clause.
This lets OfflineIMAP open up multiple connections simultaneously. That will let it process multiple folders and messages at once. In most cases, this will increase performance of the sync.
Don’t set the number too high. If you do that, things might actually slow down as your link gets saturated. Also, too many connections can cause mail servers to have excessive load. Administrators might take unkindly to this, and the server might bog down. There are many variables in the optimal setting; experimentation may help.
An informal benchmark yields these results for my setup:
- 10 minutes with MacOS X Mail.app “manual cache”
- 5 minutes with GNUS agent sync
- 20 seconds with OfflineIMAP 1.x
- 9 seconds with OfflineIMAP 2.x
- 3 seconds with OfflineIMAP 3.x “cold start”
- 2 seconds with OfflineIMAP 3.x “held connection”
It should run on most platforms supported by Python, which are quite a few. I do not support Windows myself, but some have made it work there.
These answers have been reported by OfflineIMAP users. I do not run OfflineIMAP on Windows myself, so I can’t directly address their accuracy.
The basic answer is that it’s possible and doesn’t require hacking OfflineIMAP source code. However, it’s not necessarily trivial. The information below is based in instructions submitted by Chris Walker.
First, you must run OfflineIMAP in the Cygwin environment. The Windows filesystem is not powerful enough to accomodate Maildir by itself.
Next, you’ll need to mount your Maildir directory in a special way. There is information for doing that at http://barnson.org/node/295. That site gives this example:
mount -f -s -b -o managed "d:/tmp/mail" "/home/of/mail"
That URL also has more details on making OfflineIMAP work with Windows.
Not directly. Maildir was the easiest to implement. I’m not planning to write mbox code for OfflineIMAP, though if someone sent me well-written mbox support and pledged to support it, I’d commit it to the tree.
However, OfflineIMAP can directly sync accounts on two different IMAP servers together. So you could install an IMAP server on your local machine that supports mbox, sync to it, and then instruct your mail readers to use the mboxes.
Or you could install whatever IMAP server you like on the local machine, and point your mail readers to that IMAP server on localhost.
OfflineIMAP does not currently provide this feature. However, if you create a new folder on the remote server, OfflineIMAP will detect this and create the corresponding folder locally automatically.
No. POP is not robust enough to do a completely reliable multi-machine sync like OfflineIMAP can do.
OfflineIMAP will never support POP.
Of course!
Just name them all in the accounts line in the general section of the configuration file, and add a per-account section for each one.
You can also optionally use the -a option when you run OfflineIMAP to request that it only operate upon a subset of the accounts for a particular run.
You do not need to. OfflineIMAP is smart enough to automatically figure out what folders are present on the IMAP server and synchronize them. You can use the folderfilter and nametrans configuration file options to request only certain folders and rename them as they come in if you like.
Use the folderfilter option.
Some mail readers, such as mutt, are not capable of automatically determining the names of your mailboxes. OfflineIMAP can help these programs by writing the names of the folders in a format you specify. See the example offlineimap.conf for details.
In general, OfflineIMAP works with any IMAP server that provides compatibility with the IMAP RFCs. Some servers provide imperfect compatibility that may be good enough for general clients. OfflineIMAP needs more features, specifically support for UIDs, in order to do its job accurately and completely.
Several users have reported problems with Microsoft Exchange servers in conjunction with OfflineIMAP. This generally seems to be related to the Exchange servers not properly following the IMAP standards.
Mark Biggers has posted some information to the OfflineIMAP mailing list about how he made it work.
Other users have indicated that older (5.5) releases of Exchange are so bad that they will likely not work at all.
I do not have access to Exchange servers for testing, so any problems with it, if they can even be solved at all, will require help from OfflineIMAP users to find and fix.
Any client that supports Maildir. Popular ones include mutt, Evolution and KMail. Thunderbird does not have maildir suppport.
With OfflineIMAP’s IMAP-to-IMAP syncing, this can be even wider; see the next question.
OfflineIMAP can work with Evolution. To do so, first configure your OfflineIMAP account to have sep = / in its configuration. Then, configure Evolution with the “Maildir-format mail directories” server type. For the path, you will need to specify the name of the top-level folder inside your OfflineIMAP storage location. You’re now set!
At this time, I believe that OfflineIMAP with Maildirs is not compatible with KMail. KMail cannot work in any mode other than to move all messages out of all folders immediately, which (besides being annoying and fundamentally broken) is incompatible with OfflineIMAP.
However, I have made KMail version 3 work well with OfflineIMAP by installing an IMAP server on my local machine, having OfflineIMAP sync to that, and pointing KMail at the same server.
Another way to see mails downloaded with offlineimap in KMail (KDE4) is to create a local folder (e.g. Backup) and then use “ln -s localfolders_in_offlineimaprc ~/.kde/share/apps/kmail/mail/.Backup.directory”. Maybe you have to rebuild the index of the new folder. Works well with KMail 1.11.4 (KDE4.x), offlineimap 6.1.2 and ArchLinux and sep = / in .offlineimaprc.
Other IMAP sync programs require you to do this. OfflineIMAP does not. You’ll get the best results without it, in fact, though turning it on won’t hurt anything.
The example offlineimap.conf file has this example. In your offlineimap.conf, you’ll list this:
[mbnames] enabled = yes filename = ~/Mutt/muttrc.mailboxes header = "mailboxes " peritem = "+%(accountname)s/%(foldername)s" sep = " " footer = "\n"
Then in your .muttrc:
source ~/Mutt/muttrc.mailboxes
You might also want to set:
set mbox_type=Maildir set folder=$HOME/Maildirpath
The OfflineIMAP manual has a more detailed example for doing this for multiple accounts.
OfflineIMAP has two relevant principles: 1) never modifying your messages in any way and 2) ensuring 100% reliable synchronizations. In order to do a reliable sync, OfflineIMAP must have a way to uniquely identify each e-mail. Three pieces of information are required to do this: your account name, the folder name, and the message UID. The account name can be calculated from the path in which your messages are. The folder name can usually be as well, BUT some mail clients move messages between folders by simply moving the file, leaving the name intact.
So, OfflineIMAP must store both a UID folder ID. The folder ID is necessary so OfflineIMAP can detect a message moved to a different folder. OfflineIMAP stores the UID (U= number) and an md5sum of the foldername (FMD5= number) to facilitate this.
This shell script will restart OfflineIMAP if it has crashed. Sorry, its written in Korn, so you’ll need ksh, pdksh, or mksh to run it.
#!/bin/ksh
# remove any old instances of this shell script or offlineimap
for pid in $(pgrep offlineimap)
do
if $pid -ne $$
then
kill $pid
fi
done
# wait for compiz (or whatever) to start and setup wifi
sleep 20
# If offlineimap exits, restart it
while true
do
( exec /usr/bin/offlineimap -u Noninteractive.Quiet )
sleep 60 # prevents extended failure conditions (network down) from spamming
done