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-2020 Guilhem Moulin ⟨guilhem@fripost.org⟩, and licensed for use under the GNU General Public License version 3 or later. See ‘COPYING’ for specific terms and distribution information.