.\" Automatically generated by Pandoc 2.9.2.1
.\"
.TH "interimap" "1" "July 2015" "" ""
.hy
.SH NAME
.PP
InterIMAP - Fast bidirectional synchronization for QRESYNC-capable IMAP
servers
.SH SYNOPSIS
.PP
\f[C]interimap\f[R] [\f[I]OPTION\f[R] \&...] [\f[I]COMMAND\f[R]]
[\f[I]MAILBOX\f[R] \&...]
.SH DESCRIPTION
.PP
\f[C]interimap\f[R] performs stateful synchronization between two
IMAP4rev1 servers.
Such synchronization is made possible by the \f[C]QRESYNC\f[R] IMAP
extension; for convenience reasons servers must also support the
\f[C]LIST-EXTENDED\f[R], \f[C]LIST-STATUS\f[R] (or \f[C]NOTIFY\f[R]) and
\f[C]UIDPLUS\f[R] IMAP extensions.
See also the \f[B]supported extensions\f[R] section below.
.PP
Stateful synchronization is only possible for mailboxes supporting
persistent message Unique Identifiers (UID) and persistent storage of
mod-sequences (MODSEQ); any non-compliant mailbox will cause
\f[C]interimap\f[R] to abort.
Furthermore, because UIDs are allocated not by the client but by the
server, \f[C]interimap\f[R] needs to keep track of associations between
local and remote UIDs for each mailbox.
The synchronization state of a mailbox consists of its \f[C]UIDNEXT\f[R]
and \f[C]HIGHESTMODSEQ\f[R] values on each server; it is then assumed
that each message with UID smaller than \f[C]UIDNEXT\f[R] have been
replicated to the other server, and that the metadata (such as flags) of
each message with MODSEQ at most \f[C]HIGHESTMODSEQ\f[R] have been
synchronized.
Conceptually, the synchronization algorithm is derived from RFC 4549
with the RFC 7162 (sec.\ 6) amendments, and works as follows:
.IP "1." 3
\f[C]SELECT\f[R] (on both servers) a mailbox the current
\f[C]UIDNEXT\f[R] or \f[C]HIGHESTMODSEQ\f[R] values of which differ from
the values found in the database (for either server).
Use the \f[C]QRESYNC\f[R] \f[C]SELECT\f[R] parameter from RFC 7162 to
list changes (vanished messages and flag updates) since
\f[C]HIGHESTMODSEQ\f[R] to messages with UID smaller than
\f[C]UIDNEXT\f[R].
.IP "2." 3
Propagate these changes onto the other server: get the corresponding
UIDs from the database, then:
.RS 4
.IP "a." 3
issue a \f[C]UID STORE\f[R] command, followed by \f[C]UID EXPUNGE\f[R],
to remove messages that have not already been deleted on both servers;
and
.IP "b." 3
issue some \f[C]UID STORE\f[R] commands to propagate flag updates (send
a single command for each flag list in order the reduce the number of
round trips).
.PP
(Conflicts may occur if the metadata of a message has been updated on
both servers with different flag lists; in that case,
\f[C]interimap\f[R] issues a warning and updates the message on each
server with the union of both flag lists.) Repeat this step if the
server sent some updates in the meantime.
Otherwise, update the \f[C]HIGHESTMODSEQ\f[R] value in the database.
.RE
.IP "3." 3
Process new messages (if the current \f[C]UIDNEXT\f[R] value of the
mailbox differs from the one found in the database) by issuing a
\f[C]UID FETCH\f[R] command; process each received message on-the-fly by
issuing an \f[C]APPEND\f[R] command with the message\[cq]s
\f[C]RFC822\f[R] body, \f[C]FLAGS\f[R] and \f[C]INTERNALDATE\f[R].
Repeat this step if the server received new messages in the meantime.
Otherwise, update the \f[C]UIDNEXT\f[R] value in the database.
Go back to step 2 if the server sent some metadata (such as flag)
updates in the meantime.
.IP "4." 3
Go back to step 1 to proceed with the next unsynchronized mailbox.
.SH COMMANDS
.PP
By default, \f[C]interimap\f[R] synchronizes each mailbox listed by the
\f[C]LIST \[dq]\[dq] \[dq]*\[dq]\f[R] IMAP command; the
\f[I]list-mailbox\f[R], \f[I]list-select-opts\f[R] and
\f[I]ignore-mailbox\f[R] options from the configuration file can be used
to shrink that list and save bandwidth.
However if some extra argument are provided on the command line,
\f[C]interimap\f[R] ignores these options and synchronizes the given
\f[I]MAILBOX\f[R]es instead.
Note that each \f[I]MAILBOX\f[R] is taken \[lq]as is\[rq]; in
particular, it must be UTF-7 encoded, unquoted, and the list wildcards
`*' and `%' are passed verbatim to the IMAP server.
If the local and remote hierarchy delimiter differ, then within the
\f[I]MAILBOX\f[R] names the \f[I]local\f[R] delimiter should be used (it
is transparently substituted for remote commands and responses).
.PP
If the synchronization was interrupted during a previous run while some
messages were being replicated (but before the \f[C]UIDNEXT\f[R] or
\f[C]HIGHESTMODSEQ\f[R] values have been updated), \f[C]interimap\f[R]
performs a \[lq]full synchronization\[rq] on theses messages:
downloading the whole UID and flag lists on each servers allows
\f[C]interimap\f[R] to detect messages that have been removed or for
which their flags have changed in the meantime.
Finally, after propagating the offline changes for these messages,
\f[C]interimap\f[R] resumes the synchronization for the rest of the
mailbox.
.PP
Specifying one of the commands below makes \f[C]interimap\f[R] perform
an action other than the default \f[C]QRESYNC\f[R]-based
synchronization.
.TP
\f[B]\f[CB]--repair\f[B]\f[R] [\f[I]MAILBOX\f[R] \&...]
List the database anomalies and try to repair them.
(Consider only the given \f[I]MAILBOX\f[R]es if non-optional arguments
are provided.) This is done by performing a so-called \[lq]full
synchronization\[rq], namely: 1/ download all UIDs along with their flag
list both from the local and remote servers; 2/ ensure that each entry
in the database corresponds to an existing UID; and 3/ ensure that both
flag lists match.
Any message found on a server but not in the database is replicated on
the other server (which in the worst case, might yield a message
duplicate).
Flag conflicts are solved by updating each message to the union of both
lists.
.TP
\f[B]\f[CB]--delete\f[B]\f[R] \f[I]MAILBOX\f[R] [\f[I]MAILBOX\f[R] \&...]
Delete the given \f[I]MAILBOX\f[R]es on each target (by default each
server plus the database, unless \f[C]--target\f[R] specifies otherwise)
where it exists.
Note that per the IMAP4rev1 standard deletion is not recursive.
Thus \f[I]MAILBOX\f[R]\[cq]s children are not deleted.
.TP
\f[B]\f[CB]--rename\f[B]\f[R] \f[I]SOURCE\f[R] \f[I]DEST\f[R]
Rename the mailbox \f[I]SOURCE\f[R] to \f[I]DEST\f[R] on each target (by
default each server plus the database, unless \f[C]--target\f[R]
specifies otherwise) where it exists.
\f[C]interimap\f[R] aborts if \f[I]DEST\f[R] already exists on either
target.
Note that per the IMAP4rev1 standard renaming is recursive.
Thus \f[I]SOURCE\f[R]\[cq]s children are moved to become
\f[I]DEST\f[R]\[cq]s children instead.
.SH OPTIONS
.TP
\f[B]\f[CB]--config=\f[B]\f[R]\f[I]FILE\f[R]
Specify an alternate configuration file.
Relative paths start from \f[I]$XDG_CONFIG_HOME/interimap\f[R], or
\f[I]\[ti]/.config/interimap\f[R] if the \f[C]XDG_CONFIG_HOME\f[R]
environment variable is unset.
.TP
\f[B]\f[CB]--target={local,remote,database}\f[B]\f[R]
Limit the scope of a \f[C]--delete\f[R] or \f[C]--rename\f[R] command to
the given target.
Can be repeated to act on multiple targets.
By default all three targets are considered.
.TP
\f[B]\f[CB]--watch\f[B]\f[R][\f[B]\f[CB]=\f[B]\f[R]\f[I]seconds\f[R]]
Don\[cq]t exit after a successful synchronization.
Instead, keep synchronizing forever.
Sleep for the given number of \f[I]seconds\f[R] (by default 1 minute if
\f[C]--notify\f[R] is unset, and 15 minutes if \f[C]--notify\f[R] is
set) between two synchronizations.
Setting this options enables \f[C]SO_KEEPALIVE\f[R] on the socket for
\f[I]type\f[R]s other than \f[C]tunnel\f[R].
.TP
\f[B]\f[CB]--notify\f[B]\f[R]
Whether to use the IMAP \f[C]NOTIFY\f[R] extension to instruct the
server to automatically send updates to the client.
(Both local and remote servers must support RFC 5465 for this to work.)
This greatly reduces IMAP traffic since \f[C]interimap\f[R] can rely on
server notifications instead of manually polling for updates.
If the connection remains idle for 15 minutes (configurable with
\f[C]--watch\f[R]), then \f[C]interimap\f[R] sends a \f[C]NOOP\f[R]
command to avoid being logged out for inactivity.
.TP
\f[B]\f[CB]-q\f[B]\f[R], \f[B]\f[CB]--quiet\f[B]\f[R]
Try to be quiet.
.TP
\f[B]\f[CB]--debug\f[B]\f[R]
Turn on debug mode.
Debug messages, which includes all IMAP traffic besides literals, are
written to the given \f[I]logfile\f[R].
The \f[C]LOGIN\f[R] and \f[C]AUTHENTICATE\f[R] commands are however
redacted (in order to avoid disclosing authentication credentials)
unless the \f[C]--debug\f[R] flag is set multiple times.
.TP
\f[B]\f[CB]-h\f[B]\f[R], \f[B]\f[CB]--help\f[B]\f[R]
Output a brief help and exit.
.TP
\f[B]\f[CB]--version\f[B]\f[R]
Show the version number and exit.
.SH CONFIGURATION FILE
.PP
Unless told otherwise by the \f[C]--config=FILE\f[R] command-line
option, \f[C]interimap\f[R] reads its configuration from
\f[I]$XDG_CONFIG_HOME/interimap/config\f[R] (or
\f[I]\[ti]/.config/interimap/config\f[R] if the
\f[C]XDG_CONFIG_HOME\f[R] environment variable is unset) as an INI file.
The syntax of the configuration file is a series of
\f[C]OPTION=VALUE\f[R] lines organized under some \f[C][SECTION]\f[R];
lines starting with a `#' or `;' character are ignored as comments.
The \f[C][local]\f[R] and \f[C][remote]\f[R] sections define the two
IMAP servers to synchronize.
Valid options are:
.TP
\f[I]database\f[R]
SQLite version 3 database file to use to keep track of associations
between local and remote UIDs, as well as the \f[C]UIDVALIDITY\f[R],
\f[C]UIDNEXT\f[R] and \f[C]HIGHESTMODSEQ\f[R] of each known mailbox on
both servers.
Relative paths start from \f[I]$XDG_DATA_HOME/interimap\f[R], or
\f[I]\[ti]/.local/share/interimap\f[R] if the \f[C]XDG_DATA_HOME\f[R]
environment variable is unset.
This option is only available in the default section.
(Default: \f[C]HOST.db\f[R], where \f[I]HOST\f[R] is taken from the
\f[C][remote]\f[R] or \f[C][local]\f[R] sections, in that order.)
.TP
\f[I]list-reference\f[R]
An optional \[lq]reference name\[rq] to use for the initial
\f[C]LIST\f[R] command, indicating the context in which the
\f[I]MAILBOX\f[R]es are interpreted.
For instance, by specifying \f[C]list-reference=perso/\f[R] in the
\f[C][local]\f[R] section, \f[I]MAILBOX\f[R] names are interpreted
relative to \f[C]perso/\f[R] on the local server; in other words the
remote mailbox hierarchy is mapped to the \f[C]perso/\f[R] sub-hierarchy
on the local server.
This is useful for synchronizing multiple remote servers against
different namespaces belonging to the same local IMAP server (using a
different \f[C]interimap\f[R] instance for each local namespace \[<>]
remote synchronization).
.RS
.PP
(Note that if the reference name is not a level of mailbox hierarchy
and/or does not end with the hierarchy delimiter, by RFC 3501 its
interpretation by the IMAP server is implementation-dependent.)
.RE
.TP
\f[I]list-mailbox\f[R]
A space separated list of mailbox patterns to use when issuing the
initial \f[C]LIST\f[R] command (overridden by the \f[I]MAILBOX\f[R]es
given as command-line arguments).
Names containing special characters such as spaces or brackets need to
be enclosed in double quotes.
Within double quotes C-style backslash escape sequences can be used
(`\[rs]t' for an horizontal tab, `\[rs]n' for a new line, `\[rs]\[rs]'
for a backslash, etc.), as well as hexadecimal escape sequences
`\[rs]xHH'.
Furthermore, non-ASCII names must be UTF-7 encoded.
Two wildcards are available, and passed verbatim to the IMAP server: a
`*' character matches zero or more characters, while a `%' character
matches zero or more characters up to the hierarchy delimiter.
Hard-coding the hierarchy delimiter in this setting is not advised
because the server might silently change it at some point.
A null character should be used instead.
For instance, if \f[I]list-mailbox\f[R] is set
\f[C]\[dq]foo\[rs]x00bar\[dq]\f[R] then, assuming the hierarchy
delimiter is `/', only the mailbox named \f[C]foo/bar\f[R] is considered
for synchronization.
.RS
.PP
This option is only available in the default section.
(The default pattern, \f[C]*\f[R], matches all visible mailboxes on the
server.)
.RE
.TP
\f[I]list-select-opts\f[R]
An optional space separated list of selectors for the initial
\f[C]LIST\f[R] command.
(Requires a server supporting the \f[C]LIST-EXTENDED\f[R] IMAP
extension.) Useful values are \f[C]SUBSCRIBED\f[R] (to list only
subscribed mailboxes), \f[C]REMOTE\f[R] (to also list remote mailboxes
on a server supporting mailbox referrals), and \f[C]RECURSIVEMATCH\f[R]
(to list parent mailboxes with children matching one of the above
\f[I]list-mailbox\f[R] patterns).
This option is only available in the default section.
.TP
\f[I]ignore-mailbox\f[R]
An optional Perl Compatible Regular Expressions (PCRE) covering
mailboxes to exclude: any (UTF-7 encoded and unquoted) mailbox listed in
the initial \f[C]LIST\f[R] responses is ignored if it matches the given
expression after trimming the reference names and substituting the
hierarchy delimiter with the null character.
For instance, specifying \f[C]\[ha]virtual(?:\[rs]x00|$)\f[R] excludes
the mailbox named \[lq]virtual\[rq] as well as its descendants.
Note that the \f[I]MAILBOX\f[R]es given as command-line arguments bypass
the check and are always considered for synchronization.
This option is only available in the default section.
.TP
\f[I]logfile\f[R]
A file name to use to log debug and informational messages.
(By default these messages are written to the error output.) This option
is only available in the default section.
.TP
\f[I]log-prefix\f[R]
A \f[C]printf\f[R](3)-like format string to use as prefix for each log
message.
Interpreted sequences are \f[C]%n\f[R] and \f[C]%m\f[R], expanding
respectively to the component name (\f[I]local\f[R]/\f[I]remote\f[R])
and to the name of the mailbox relevant for the log entry.
Conditions on a specifier \f[C]%X\f[R] can be obtained with
\f[C]%?X?then?\f[R] or \f[C]%?X?then&else?\f[R], which expands to
\f[I]then\f[R] if the \f[C]%X\f[R] specifier expands to a non-empty
string, and to \f[I]else\f[R] (or the empty string if there is no else
condition) if it doesn\[cq]t.
Literal \f[C]%\f[R] characters need to be escaped as \f[C]%%\f[R], while
\f[C]&\f[R], \f[C]?\f[R] and \f[C]\[rs]\f[R] characters need to be
\f[C]\[rs]\f[R]-escaped.
(Default: \f[C]%?n?%?m?%n(%m)&%n?: ?\f[R].)
.TP
\f[I]type\f[R]
One of \f[C]imap\f[R], \f[C]imaps\f[R] or \f[C]tunnel\f[R].
\f[C]type=imap\f[R] and \f[C]type=imaps\f[R] are respectively used for
IMAP and IMAP over SSL/TLS connections over an INET socket.
\f[C]type=tunnel\f[R] causes \f[C]interimap\f[R] to create an unnamed
pair of connected sockets for inter-process communication with a
\f[I]command\f[R] instead of opening a network socket.
Note that specifying \f[C]type=tunnel\f[R] in the \f[C][remote]\f[R]
section makes the default \f[I]database\f[R] to be
\f[C]localhost.db\f[R].
(Default: \f[C]imaps\f[R].)
.TP
\f[I]host\f[R]
Server hostname or IP address, for \f[C]type=imap\f[R] and
\f[C]type=imaps\f[R].
The value can optionally be enclosed in square brackets to force its
interpretation as an IP literal (hence skip name resolution).
(Default: \f[C]localhost\f[R].)
.TP
\f[I]port\f[R]
Server port.
(Default: \f[C]143\f[R] for \f[C]type=imap\f[R], \f[C]993\f[R] for
\f[C]type=imaps\f[R].)
.TP
\f[I]proxy\f[R]
Optional SOCKS proxy to use for TCP connections to the IMAP server
(\f[C]type=imap\f[R] and \f[C]type=imaps\f[R] only), formatted as
\f[C]PROTOCOL://[USER:PASSWORD\[at]]PROXYHOST[:PROXYPORT]\f[R].
If \f[C]PROXYPORT\f[R] is omitted, it is assumed at port 1080.
Only SOCKSv5 is supported (with optional username/password
authentication), in two flavors: \f[C]socks5://\f[R] to resolve
\f[I]hostname\f[R] locally, and \f[C]socks5h://\f[R] to let the proxy
resolve \f[I]hostname\f[R].
.TP
\f[I]command\f[R]
Command to use for \f[C]type=tunnel\f[R].
Must speak the IMAP4rev1 protocol on its standard output, and understand
it on its standard input.
The value is passed to \f[C]\[ga]/bin/sh -c\[ga]\f[R] if it contains
shell metacharacters; otherwise it is split into words and the resulting
list is passed to \f[C]execvp\f[R](3).
.TP
\f[I]STARTTLS\f[R]
Whether to use the \f[C]STARTTLS\f[R] directive to upgrade to a secure
connection.
Setting this to \f[C]YES\f[R] for a server not advertising the
\f[C]STARTTLS\f[R] capability causes \f[C]interimap\f[R] to immediately
abort the connection.
(Ignored for \f[I]type\f[R]s other than \f[C]imap\f[R].
Default: \f[C]YES\f[R].)
.TP
\f[I]auth\f[R]
Space-separated list of preferred authentication mechanisms.
\f[C]interimap\f[R] uses the first mechanism in that list that is also
advertised (prefixed with \f[C]AUTH=\f[R]) in the server\[cq]s
capability list.
Supported authentication mechanisms are \f[C]PLAIN\f[R] and
\f[C]LOGIN\f[R].
(Default: \f[C]PLAIN LOGIN\f[R].)
.TP
\f[I]username\f[R], \f[I]password\f[R]
Username and password to authenticate with.
Can be required for non pre-authenticated connections, depending on the
chosen authentication mechanism.
.TP
\f[I]compress\f[R]
Whether to use the \f[C]IMAP COMPRESS\f[R] extension for servers
advertising it.
(Default: \f[C]NO\f[R] for the \f[C][local]\f[R] section, \f[C]YES\f[R]
for the \f[C][remote]\f[R] section.)
.TP
\f[I]null-stderr\f[R]
Whether to redirect \f[I]command\f[R]\[cq]s standard error to
\f[C]/dev/null\f[R] for \f[C]type=tunnel\f[R].
This option is ignored when the \f[C]--debug\f[R] flag is set.
(Default: \f[C]NO\f[R].)
.TP
\f[I]SSL_protocols\f[R]
Space-separated list of SSL/TLS protocol versions to explicitly enable
(or disable if prefixed with an exclamation mark \f[C]!\f[R]).
Potentially known protocols are \f[C]SSLv2\f[R], \f[C]SSLv3\f[R],
\f[C]TLSv1\f[R], \f[C]TLSv1.1\f[R], \f[C]TLSv1.2\f[R], and
\f[C]TLSv1.3\f[R], depending on the OpenSSL version used.
Enabling a protocol is a short-hand for disabling all other protocols.
.RS
.PP
\f[I]DEPRECATED\f[R]: Use \f[I]SSL_protocol_min\f[R] and/or
\f[I]SSL_protocol_max\f[R] instead.
.RE
.TP
\f[I]SSL_protocol_min\f[R], \f[I]SSL_protocol_max\f[R]
Set minimum resp.
maximum SSL/TLS protocol version to use for the connection.
Potentially recognized values are \f[C]SSLv3\f[R], \f[C]TLSv1\f[R],
\f[C]TLSv1.1\f[R], \f[C]TLSv1.2\f[R], and \f[C]TLSv1.3\f[R], depending
on the OpenSSL version used.
.TP
\f[I]SSL_cipherlist\f[R], \f[I]SSL_ciphersuites\f[R]
Sets the TLSv1.2 and below cipher list resp.
TLSv1.3 cipher suites.
The combination of these lists is sent to the server, which then
determines which cipher to use (normally the first supported one from
the list sent by the client).
The default suites depend on the OpenSSL version and its configuration,
see \f[C]ciphers\f[R](1ssl) for more information.
.TP
\f[I]SSL_fingerprint\f[R]
Space-separated list of acceptable fingerprints for the server
certificate\[cq]s Subject Public Key Info, in the form
\f[C][ALGO$]DIGEST_HEX\f[R] where \f[C]ALGO\f[R] is the digest algorithm
(by default \f[C]sha256\f[R]).
Attempting to connect to a server with a non-matching certificate SPKI
fingerprint causes \f[C]interimap\f[R] to abort the connection during
the SSL/TLS handshake.
The following command can be used to compute the SHA-256 digest of a
certificate\[cq]s Subject Public Key Info:
.RS
.IP
.nf
\f[C]
$ openssl x509 -in /path/to/server/certificate.pem -pubkey \[rs]
| openssl pkey -pubin -outform DER \[rs]
| openssl dgst -sha256
\f[R]
.fi
.PP
Specifying multiple digest values can be useful in key rollover
scenarios and/or when the server supports certificates of different
types (for instance a dual-cert RSA/ECDSA setup).
In that case the connection is aborted when none of the specified
digests matches.
.RE
.TP
\f[I]SSL_verify\f[R]
Whether to 1/ verify the server certificate chain; and 2/ match its
Subject Alternative Name (SAN) or Subject CommonName (CN) against the
value of the \f[I]host\f[R] option.
(Default: \f[C]YES\f[R].)
.RS
.PP
Note that using \f[I]SSL_fingerprint\f[R] to specify the fingerprint of
the server certificate provides an independent server authentication
measure as it pins directly its key material and ignore its chain of
trust.
.RE
.TP
\f[I]SSL_CAfile\f[R]
File containing trusted certificates to use during server certificate
verification when \f[C]SSL_verify=YES\f[R].
.RS
.PP
Trusted CA certificates are loaded from the default system locations
unless one (or both) of \f[I]SSL_CAfile\f[R] or \f[I]SSL_CApath\f[R] is
set.
.RE
.TP
\f[I]SSL_CApath\f[R]
Directory to use for server certificate verification when
\f[C]SSL_verify=YES\f[R].
This directory must be in \[lq]hash format\[rq], see
\f[C]verify\f[R](1ssl) for more information.
.RS
.PP
Trusted CA certificates are loaded from the default system locations
unless one (or both) of \f[I]SSL_CAfile\f[R] or \f[I]SSL_CApath\f[R] is
set.
.RE
.TP
\f[I]SSL_hostname\f[R]
Name to use for the TLS SNI (Server Name Indication) extension.
The default value is taken from the \f[I]host\f[R] option when it is a
hostname, and to the empty string when it is an IP literal.
Setting \f[I]SSL_hostname\f[R] to the empty string explicitly disables
SNI.
.SH SUPPORTED EXTENSIONS
.PP
\f[C]interimap\f[R] takes advantage of servers supporting the following
extensions to the IMAP4rev1 protocol (those marked as
\[lq]recommended\[rq] give the most significant performance gain):
.IP \[bu] 2
\f[C]LITERAL+\f[R] (RFC 2088, recommended);
.IP \[bu] 2
\f[C]MULTIAPPEND\f[R] (RFC 3502, recommended);
.IP \[bu] 2
\f[C]COMPRESS=DEFLATE\f[R] (RFC 4978, recommended);
.IP \[bu] 2
\f[C]NOTIFY\f[R] (RFC 5465);
.IP \[bu] 2
\f[C]SASL-IR\f[R] (RFC 4959); and
.IP \[bu] 2
\f[C]UNSELECT\f[R] (RFC 3691).
.SH KNOWN BUGS AND LIMITATIONS
.IP \[bu] 2
Using \f[C]interimap\f[R] on two identical servers with a non-existent
or empty \f[I]database\f[R] will duplicate each message due to the
absence of local \[<>] remote UID association.
(Should they arise, an external tool such as
\f[C]doveadm-deduplicate\f[R](1) can be used to weed them out.) Hence
one needs to manually empty the mail store on one end when migrating to
\f[C]interimap\f[R] from another synchronization solution.
.IP \[bu] 2
\f[C]interimap\f[R] is single threaded and doesn\[cq]t use IMAP command
pipelining.
Synchronization could be boosted up by sending independent commands
(such as the initial \f[C]LIST\f[R] and \f[C]STATUS\f[R] commands) to
both servers in parallel, and for a given server, by sending independent
commands (such as flag updates) in a pipeline.
.IP \[bu] 2
Because the IMAP protocol doesn\[cq]t have a specific response code for
when a message is moved to another mailbox (either using the
\f[C]MOVE\f[R] command from RFC 6851, or via \f[C]COPY\f[R] +
\f[C]STORE\f[R] + \f[C]EXPUNGE\f[R]), moving a message causes
\f[C]interimap\f[R] to believe that it was deleted while another one
(which is replicated again) was added to the other mailbox in the
meantime.
.IP \[bu] 2
Because the IMAP protocol doesn\[cq]t provide a way for clients to
determine whether a disappeared mailbox was deleted or renamed,
\f[C]interimap\f[R] aborts when a known mailbox disappeared from one
server but not the other.
The \f[C]--delete\f[R] (resp.
\f[C]--rename\f[R]) command should be used instead to delete (resp.
rename) the mailbox on both servers as well as within
\f[C]interimap\f[R]\[cq]s internal database.
.IP \[bu] 2
\f[C]PLAIN\f[R] and \f[C]LOGIN\f[R] are the only authentication
mechanisms currently supported.
.IP \[bu] 2
\f[C]interimap\f[R] will probably not work with non RFC-compliant
servers.
In particular, no work-around is currently implemented beside the
tunables in the configuration file.
Moreover, few IMAP servers have been tested so far.
.SH STANDARDS
.IP \[bu] 2
M.
Leech, M.
Ganis, Y.
Lee, R.
Kuris, D.
Koblas and L.
Jones, \f[I]SOCKS Protocol Version 5\f[R], RFC 1928, March 1996.
.IP \[bu] 2
M.
Leech, \f[I]Username/Password Authentication for SOCKS V5\f[R], RFC
1929, March 1996.
.IP \[bu] 2
J.
Myers, \f[I]IMAP4 non-synchronizing literals\f[R], RFC 2088, January
1997.
.IP \[bu] 2
D.
Goldsmith and M.
Davis, \f[I]A Mail-Safe Transformation Format of Unicode\f[R], RFC 2152,
May 1997.
.IP \[bu] 2
C.
Newman, \f[I]Using TLS with IMAP, POP3 and ACAP\f[R], RFC 2595, June
1999.
.IP \[bu] 2
M.
Crispin, \f[I]Internet Message Access Protocol - Version 4rev1\f[R], RFC
3501, March 2003.
.IP \[bu] 2
M.
Crispin, \f[I]Internet Message Access Protocol (IMAP) -
\f[CI]MULTIAPPEND\f[I] Extension\f[R], RFC 3502, March 2003.
.IP \[bu] 2
A.
Melnikov, \f[I]Internet Message Access Protocol (IMAP)
\f[CI]UNSELECT\f[I] command\f[R], RFC 3691, February 2004.
.IP \[bu] 2
M.
Crispin, \f[I]Internet Message Access Protocol (IMAP) -
\f[CI]UIDPLUS\f[I] extension\f[R], RFC 4315, December 2005.
.IP \[bu] 2
A.
Melnikov, \f[I]Synchronization Operations for Disconnected IMAP4
Clients\f[R], RFC 4549, June 2006.
.IP \[bu] 2
A.
Gulbrandsen, \f[I]The IMAP \f[CI]COMPRESS\f[I] Extension\f[R], RFC 4978,
August 2007.
.IP \[bu] 2
R.
Siemborski and A.
Gulbrandsen, \f[I]IMAP Extension for Simple Authentication and Security
Layer (SASL) Initial Client Response\f[R], RFC 4959, September 2007.
.IP \[bu] 2
A.
Gulbrandsen and A.
Melnikov, \f[I]The IMAP \f[CI]ENABLE\f[I] Extension\f[R], RFC 5161,
March 2008.
.IP \[bu] 2
B.
Leiba and A.
Melnikov, \f[I]Internet Message Access Protocol version 4 -
\f[CI]LIST\f[I] Command Extensions\f[R], RFC 5258, June 2008.
.IP \[bu] 2
A.
Gulbrandsen, C.
King and A.
Melnikov, \f[I]The IMAP \f[CI]NOTIFY\f[I] Extension\f[R], RFC 5465,
February 2009.
.IP \[bu] 2
A.
Melnikov and T.
Sirainen, \f[I]IMAP4 Extension for Returning \f[CI]STATUS\f[I]
Information in Extended LIST\f[R], RFC 5819, March 2010.
.IP \[bu] 2
A.
Gulbrandsen and N.
Freed, \f[I]Internet Message Access Protocol (IMAP) - \f[CI]MOVE\f[I]
Extension\f[R], RFC 6851, January 2013.
.IP \[bu] 2
A.
Melnikov and D.
Cridland, \f[I]IMAP Extensions: Quick Flag Changes Resynchronization
(\f[CI]CONDSTORE\f[I]) and Quick Mailbox Resynchronization
(\f[CI]QRESYNC\f[I])\f[R], RFC 7162, May 2014.
.SH BUGS AND FEEDBACK
.PP
Bugs or feature requests for \f[C]interimap\f[R] should be filed with
the Debian project\[cq]s bug tracker at .
.SH SEE ALSO
.PP
A \f[I]getting started\f[R] guide is available locally at
, and online at
.
.SH AUTHORS
Guilhem Moulin (mailto:guilhem@fripost.org).