Merge tag 'debian/0.5.5-1' into debian/buster-backports

interimap Debian release 0.5.5-1

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.