1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
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 /run/shm/%u@%n
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.
|
