aboutsummaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorGuilhem Moulin <guilhem@debian.org>2021-01-01 12:44:17 +0100
committerGuilhem Moulin <guilhem@debian.org>2021-01-01 12:44:17 +0100
commitd782c12d603fcbcc8bcf7b18860e9a16a27f4b1b (patch)
tree789fa2c3e7d08b08e82b6e5fa999ac7584fe3416 /README
parent2ce885e19f4a5f18da30c35dc7da7a204e2ceb58 (diff)
parent3d818bf7e24f0757bcd13f30118d229e5a6b5448 (diff)
Merge tag 'debian/0.5.5-1' into debian/buster-backports
interimap Debian release 0.5.5-1
Diffstat (limited to 'README')
-rw-r--r--README93
1 files changed, 45 insertions, 48 deletions
diff --git a/README b/README
index fbc4ed7..c241486 100644
--- a/README
+++ b/README
@@ -1,54 +1,51 @@
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.
+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.
+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.
+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
+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.
+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.
+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]
@@ -59,7 +56,7 @@ type=imaps.
Host imap.example.net
IdentityFile ~/.ssh/id-interimap
IdentitiesOnly yes
- ControlPath /run/shm/%u@%n
+ ControlPath ${XDG_RUNTIME_DIR}/ssh-imap-%C
ControlMaster auto
ControlPersist 10m
StrictHostKeyChecking yes
@@ -69,17 +66,17 @@ type=imaps.
Compression yes
remote: ~user/.ssh/authorized_keys:
- command="/usr/lib/dovecot/imap",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-... id-interimap
+ 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).
+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-2018 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.
+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.