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
|
imapsync is a fast bidirectional synchronization program for
QRESYNC-capable IMAP servers. Consult the manual 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, imapsync 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]. Furthermore,
while imapsync can work with servers lacking support for LITERAL+
[RFC2088] and MULTIAPPEND [RFC3502], these extensions greatly improve
performance by reducing the number of required round trips hence are
recommended.
#######################################################################
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 a 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/imapsync:
[remote]
type = tunnel
command = /usr/bin/ssh user@imap.example.net
local: ~/.ssh/config:
Host imap.example.net
IdentityFile ~/.ssh/id-imapsync
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:
command="/usr/lib/dovecot/imap",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-... id-imapsync
#######################################################################
imapsync is Copyright© 2015 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.
|
