Here are answers to some of the most frequently asked questions about OfflineIMAP.
From its downloads page -- click on the Files tab above.
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:
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/view/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.
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 page was modelled after the MeatBall:InterMapTxt page.
In addition, an optional comment is allowed after the mapping.
This page is interpreted in a special way by Trac, in order to support
InterWiki links in a flexible and dynamic way.
prefix <space> URL [<space> # comment]
By using $1, $2, etc. within the URL, it is possible to create
InterWiki links which support multiple arguments, e.g. Trac:ticket:40.
The URL itself can be optionally followed by a comment,
which will subsequently be used for decorating the links
using that prefix.
New InterWiki links can be created by adding to that list, in real time.
Note however that deletions are also taken into account immediately,
so it may be better to use comments for disabling prefixes.
Also note that InterWiki prefixes are case insensitive.
PEP http://www.python.org/peps/pep-$1.html # Python Enhancement Proposal Trac-ML http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/ # Message $1 in Trac Mailing List trac-dev http://thread.gmane.org/gmane.comp.version-control.subversion.trac.devel/ # Message $1 in Trac Development Mailing List Mercurial http://www.selenic.com/mercurial/wiki/index.cgi/ # the wiki for the Mercurial distributed SCM RFC http://rfc.net/rfc$1.html # IETF's RFC $1 # # A arbitrary pick of InterWiki prefixes... # Acronym http://www.acronymfinder.com/af-query.asp?String=exact&Acronym= C2find http://c2.com/cgi/wiki?FindPage&value= Cache http://www.google.com/search?q=cache: CPAN http://search.cpan.org/perldoc? DebianBug http://bugs.debian.org/ DebianPackage http://packages.debian.org/ Dictionary http://www.dict.org/bin/Dict?Database=*&Form=Dict1&Strategy=*&Query= Google http://www.google.com/search?q= GoogleGroups http://groups.google.com/group/$1/msg/$2 # Message $2 in $1 Google Group JargonFile http://downlode.org/perl/jargon-redirect.cgi?term= MeatBall http://www.usemod.com/cgi-bin/mb.pl? MetaWiki http://sunir.org/apps/meta.pl? MetaWikiPedia http://meta.wikipedia.org/wiki/ MoinMoin http://moinmoin.wikiwikiweb.de/ WhoIs http://www.whois.sc/ Why http://clublet.com/c/c/why? c2Wiki http://c2.com/cgi/wiki? WikiPedia http://en.wikipedia.org/wiki/
Trac supports a convenient way to refer to resources of other Trac servers, from within the Wiki markup, since version 0.10.
An InterTrac link can be seen as a scoped TracLinks.
It is used for referring to a Trac resource
(Wiki page, changeset, ticket, ...) located in another
Trac environment.
Simply use the name of the other Trac environment as a prefix,
followed by a colon, ending with the resource located in the other environment.
<target_environment>:<TracLinks>
The other resource is specified using a regular TracLinks, of any flavor.
That target environment name is either the real name of the
environment, or an alias for it.
The aliases are defined in trac.ini (see below).
The prefix is case insensitive.
For convenience, there's also some alternative short-hand form,
where one can use an alias as an immediate prefix
for the identifier of a ticket, changeset or report:
(e.g. #T234, [T1508], [trac 1508], ...)
#!comment Besides the other environments run by the same server process (called _sibling_ environments), which are automatically detected, Support for sibling environments has been disabled. See http://thread.gmane.org/gmane.comp.version-control.subversion.trac.devel/157
It is necessary to setup a configuration for the InterTrac facility.
This configuration has to be done in the TracIni file, [intertrac] section.
... [intertrac] # -- Example of setting up an alias: t = trac # -- Link to an external Trac: trac.title = Edgewall's Trac for Trac trac.url = http://projects.edgewall.com/trac trac.compat = false
The .url is mandatory and is used for locating the other Trac.
This can be a relative URL in case that Trac environment is located
on the same server.
The .title information will be used for providing an useful tooltip
when moving the cursor over an InterTrac links.
.compat option can be used to activate or disabletrue by default. trac:wiki:InterTrac trac:wiki:InterTract:wiki:InterTrac t:wiki:InterTracT:wiki:InterTrac T:wiki:InterTractrac:ticket:234 trac:ticket:234trac:#234 trac:#234 #T234 #T234trac:changeset:1912 trac:changeset:1912[T1912] [T1912]trac.compat=false)
trac:log:@3300:3330 trac:log:@3300:3330 [trac 3300:3330] [trac 3300:3330]The generic form intertrac_prefix:module:id is translated
to the corresponding URL <remote>/module/id, shorthand links
are specific to some modules (e.g. !#T234 is processed by the
ticket module) and for the rest (intertrac_prefix:something),
we rely on the TracSearch#quickjump facility of the remote Trac.
I think that the trac prefix could even be set as a default in the [intertrac] TracIni section. --CB
----
See also: TracLinks, InterWiki
(since [milestone:0.10])
An InterWiki link can be used for referring to a Wiki page
located in another Wiki system, and by extension, to any object
located in any other Web application, provided a simple URL
mapping can be done.
At the extreme, InterWiki prefixes can even be used to simply introduce
links to new protocols, such as tsvn: used by TortoiseSvn.
<target_wiki>(:<identifier>)+
The link is composed by the targeted Wiki (or system) name,
followed by a colon (e.g. MeatBall:),
followed by a page specification in the target.
Note that, as for InterTrac prefixes, InterWiki prefixes are case insensitive.
The target Wiki URL is looked up in the InterMapTxt wiki page,
modelled after MeatBall:InterMapTxt.
In addition to traditional InterWiki links, where the target
is simply appended to the URL,
Trac supports parametric InterWiki URLs:
identifiers $1, $2, ... in the URL
will be replaced by corresponding arguments.
The argument list is formed by splitting the page identifier
using the ":" separator.
If the following is an excerpt of the InterMapTxt page:
h1. InterMapTxt = This is the place for defining InterWiki prefixes == Currently active prefixes: InterWiki This page is modelled after the MeatBall:InterMapTxt page. In addition, an optional comment is allowed after the mapping. ---- <pre> PEP http://www.python.org/peps/pep-$1.html # Python Enhancement Proposal $1 Trac-ML http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/$1 # Message $1 in Trac Mailing List tsvn tsvn: # Interact with TortoiseSvn ... MeatBall http://www.usemod.com/cgi-bin/mb.pl? MetaWiki http://sunir.org/apps/meta.pl? MetaWikiPedia http://meta.wikipedia.org/wiki/ MoinMoin http://moinmoin.wikiwikiweb.de/ ... </pre>Then,
MoinMoin:InterWikiMap should be rendered as MoinMoin:InterWikiMapTrac-ML:4346 should be rendered as Trac-ML:4346----
See also: InterTrac, InterMapTxt
This is just a page to practice and learn WikiFormatting.
Go ahead, edit it freely.
Not a whole lot here yet, I'm afraid, but see this list:
When you browse the repository, it's always possible to query the
Revision Log view corresponding to the path you're currently seeing.
This will display a list of the most recent changesets in which the
current path or any other path below it has been modified.
It's possible to set the revision at which the revision log should
start, using the View log starting at field. An empty value
or a value of head is taken to be the newest changeset.
It's also possible to specify the revision at which the log should
stop, using the back to field. By default, it's left empty,
which means the revision log will stop as soon as 100 revisions have
been listed.
Also, there are three modes of operation of the revision log.
By default, the revision log stops on copy, which means that
whenever an Add, Copy or Rename operation is detected,
no older revision will be shown. That's very convenient when working
with branches, as one only sees the history corresponding to what
has been done on the branch.
It's also possible to indicate that one wants to see what happened
before a Copy or Rename change, by selecting the
Follow copies mode. This will cross all copies or renames changes.
Each time the name of the path changes, there will be an additional
indentation level. That way, the changes on the different paths
are easily grouped together visually.
It's even possible to go past an Add change, in order to see
if there has been a Delete change on that path, before
that Add. This mode corresponds to the mode called
Show only adds, moves and deletes.
While quite useful at times, be aware that this operation is quite
resource intensive.
Finally, there's also a checkbox Show full log messages,
which controls whether the full content of the commit log message
should be displayed for each change, or only a shortened version of it.
For each revision log entry, there are 7 columns shown:
1. The first column contains a pair of radio buttons and should used
for selecting the old and the new revisions that will be
used for TracRevisionLog#viewingtheactualchanges.
2. A color code (similar to the one used for the TracChangeset#ChangesetHeader)
indicating kind of change.
Clicking on this column refreshes the revision log so that it restarts
with this change.
3. The Date at which the change was made.
4. The Revision number, displayed as @xyz.
This is a link to the TracBrowser, using that revision as the base line.
5. The Changeset number, displayed as [xyz].
This is a link to the TracChangeset view.
6. The Author of the change.
7. The Log Message, which contains either a summary or the full commit
log message, depending on the value of the Show full log messages
checkbox in the form above.
The View changes... buttons (placed above and below the list
of changes, on the left side) will show the set of differences
corresponding to the aggregated changes starting from the old
revision (first radio-button) to the new revision (second
radio-button), in the TracChangeset view.
Note that the old revision doesn't need to be actually
older than the new revision: it simply gives a base
for the diff. It's therefore entirely possible to easily
generate a reverse diff, for reverting what has been done
in the given range of revisions.
Finally, if the two revisions are identical, the corresponding
changeset will be shown (same effect as clicking on column 5).
At the bottom of the page, there's a ChangeLog link
that will show the range of revisions as currently shown,
but as a simple text, matching the usual conventions for
ChangeLog files.
The revision log also provides a RSS feed to monitor the changes.
To subscribe to a RSS feed for a file or directory, open its
revision log in the browser and click the orange 'XML' icon at the bottom
of the page. For more information on RSS support in Trac, see TracRss.
----
See also: TracBrowser, TracChangeset, TracGuide
OfflineIMAP is a tool to simplify your e-mail reading. With OfflineIMAP, you can read the same mailbox from multiple computers. You get a current copy of your messages on each computer, and changes you make one place will be visible on all other systems. For instance, you can delete a message on your home computer, and it will appear deleted on your work computer as well. OfflineIMAP is also useful if you want to use a mail reader that does not have IMAP support, has poor IMAP support, or does not provide disconnected operation.
OfflineIMAP works on pretty much any POSIX operating system, such as Linux, BSD operating systems, MacOS X, Solaris, etc.
OfflineIMAP is a Free Software project licensed under the GNU General Public License. You can download it for free, and you can modify it. In fact, you are encouraged to contribute to OfflineIMAP, and doing so is fast and easy.
For more information on OfflineIMAP's featureset, see the OfflineIMAP manual (link below).
Using This Site:
You can always download the source from the Downloads page and attach diffs. But it's far better, both for you and for me, if you use Git.
Please see our 5-Minute Git Guide. You can check out the OfflineIMAP repository with:
git clone git://git.complete.org/offlineimap
You can also help by adding information to this wiki.
You can access the OfflineIMAP mailing list archives at http://lists.complete.org/offlineimap@complete.org. There is also a web interface to subscribe and unsubscribe at http://www.complete.org/cgi-bin/lsg2.cgi.