InterIMAP is a fast bidirectional synchronization program for QRESYNC-capable
IMAP4rev1 servers.  PullIMAP retrieves messages a remote IMAP mailbox and
deliver them to an SMTP session.  Visit https://guilhem.org/interimap for more
information.

______________________________________________________________________________

Compared to IMAP-to-Maildir synchronization solutions like OfflineIMAP, adding
an IMAP server between the Maildir storage and the MUA saves loads of
readdir(2) system calls and other File System quirks; moreover the abstraction
layer offered by the IMAP server makes the MUA and synchronization program
agnostic to the storage backend (Maildir, mbox, dbox,...) in use.

IMAP synchronization of a mailbox is usually two-folds: 1/ detect and
propagate changes (flag updates and message deletions) to existing messages,
then 2/ copy the new messages.  The naive way to perform the first step is to
issue a FETCH command to list all messages in the mailbox along with their
flags and UIDs, causing heavy network usage.  Instead, InterIMAP takes
advantage of the QRESYNC extension from [RFC7162] to perform stateful
synchronization: querying changes since the last synchronization only gives a
phenomenal performance boost and drastically reduces the network traffic.

For convenience reasons servers must also support LIST-EXTENDED [RFC5258],
LIST-STATUS [RFC5819] and UIDPLUS [RFC4315].  Other supported extensions are:

  * LITERAL+ [RFC2088] non-synchronizing literals (recommended);
  * MULTIAPPEND [RFC3502] (recommended);
  * COMPRESS=DEFLATE [RFC4978] (recommended);
  * SASL-IR [RFC4959] SASL Initial Client Response; and
  * UNSELECT [RFC3691].

______________________________________________________________________________

IMAP traffic is mostly text (beside message bodies perhaps) hence compresses
pretty well: enabling compression can save a great amount of network
resources.

However establishing an SSL/TLS connection (type=imaps, or type=imap and
STARTTLS=YES) yields a small overhead due to the SSL/TLS handshake.

On the other hand if SSH access is allowed on the remote server, one can
tunnel the IMAP traffic through SSH and use OpenSSH's ControlPersist feature
to save most of the cryptographic overhead (at the expense of a local 'ssh'
process and a remote 'imap' process).  Moreover if the IMAP user is a valid
UNIX user it is possible to use pre-authentication on the remote server as
well, which saves the extra round trip caused by the AUTHENTICATE command.
For instance the following configuration snippet saves bandwidth and brings a
significant speed gain compared to type=imaps.

    local: $XDG_CONFIG_HOME/interimap/config:
      [remote]
      type = tunnel
      command = /usr/bin/ssh user@imap.example.net

    local: ~/.ssh/config:
      Host imap.example.net
          IdentityFile ~/.ssh/id-interimap
          IdentitiesOnly yes
          ControlPath ${XDG_RUNTIME_DIR}/ssh-imap-%C
          ControlMaster auto
          ControlPersist 10m
          StrictHostKeyChecking yes
          ServerAliveCountMax 3
          ServerAliveInterval 10s
          RequestTTY no
          Compression yes

    remote: ~user/.ssh/authorized_keys:
      restrict,command="/usr/bin/doveadm exec imap" ssh-[…] id-interimap

However for long-lived connections (using the --watch command-line option),
the TLS overhead becomes negligible hence the advantage offered by the OpenSSH
ControlPersist feature is not obvious.  Furthermore if the remote server
supports the IMAP COMPRESS extension [RFC4978], adding compress=DEFLATE to the
configuration can also greatly reduce bandwidth usage with regular INET
sockets (type=imaps or type=imap).

______________________________________________________________________________

InterIMAP is Copyright © 2015-2022 Guilhem Moulin ⟨guilhem@fripost.org⟩, and
is licensed for use under the GNU General Public License version 3 or later.
See ‘COPYING’ for specific terms and distribution information.