forked from imapsync/imapsync
-
Notifications
You must be signed in to change notification settings - Fork 0
/
FAQ.OnlineUI.txt
136 lines (100 loc) · 5.61 KB
/
FAQ.OnlineUI.txt
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
#!/bin/cat
$Id: FAQ.OnlineUI.txt,v 1.20 2019/12/06 14:51:03 gilles Exp gilles $
This document is also available online at
https://imapsync.lamiral.info/FAQ.d/
https://imapsync.lamiral.info/FAQ.d/FAQ.OnlineUI.txt
=====================================================================
Imapsync tips about the online visual user interfaces
https://i005.lamiral.info/X/
https://imapsync.lamiral.info/X/
=====================================================================
Questions answered in this FAQ are:
Q. How secure is the online visual user interface /X?
Q. Will I have any issues with browser timing out? What happens
if the browser connection is closed for whatever reason?
Now the questions again with their answers.
=====================================================================
Q. How secure is the online visual user interface /X?
R0. Well, I don't know if asking the provider whether his online
service is secure or not would be of any interest.
Let's do it anyway, you'll be the judge.
R1. Some figures
Date of this report: 6 December 2019.
The online imapsync service /X started 9 January 2017
(1061 days of service).
In average, /X has 50 users per day lunching in mean 6
different migrations, from just one launch to many (hundreds).
The total volume /X transferred is around 101 TiB in more
than 219 thousands email imap migrations,
340 millions email messages.
R2. Pros & Cons
The online imapsync service /X runs on https only, with a
letsencrypt certificate, a certificate overall rated "A+" at
https://www.ssllabs.com/ssltest/analyze.html?d=i005.lamiral.info
Because of the https usage, what the users enter in their browser,
the imap logins and passwords, can't be eavesdropped on the network.
Imapsync itself takes care about encryption for the imap sessions,
if possible: It tries SSL first on port 993, then TLS on port 143
if the servers announces TLS, then no encryption at all.
Concerning encryption, what is done with the source imap server host1
is independent of what is done with the destination imap server host2.
At the date of 6 December 2019, there is no security problem
detected or reported to me (Gilles LAMIRAL), so far.
Feel free to attack the service and feel free to report any
hole encountered. Have in mind I can watch what you try
from the server side and take measure if the service suffers from
your acts.
As the owner of the service, it could have been 219 000 pairs of
credentials collected and nearly 101 terabytes of email messages.
I haven't kept them but I can't prove I haven't. It's just trust,
like nearly every online service in the universe.
The imap server certificates are not checked for authenticity
(by default) because too many imap servers are crappy configured
regarding certified certificates.
This default behavior is chosen like this because users of /X
want their emails transferred, instead of being not transferred
because of an incompetent imap server sysadmin.
I admint that this part, checking imap ssl/tls certificates,
could be improved from my side by including well known
certificates directly in imapsync.
If the imap servers don't honor ssl nor tls, then logins, passwords
and everything will go clear text during the imap transfers.
That's not good at all but what "comforts" me is that if the
imap servers do only clear text transfers, then it's also true
for all imap sessions the accounts' owner encounters,
imapsync is just one of them.
Last point, who could be sure that no cracker cracked the online
hosts and that he isn't currently sniffing the credentials?
No one, I'm not sure myself, even if I do take care of that
possibility. So changing the imap accounts passwords after
a sync is a safe and recommended practice!
=====================================================================
Q. Will I have any issues with browser timing out? What happens
if the browser connection is closed for whatever reason?
R. It stops the imapsync process, ie, the sync is ended right away.
Further comments on this behavior.
When using the /X interface there are three connections.
One connection is the Browser/WebServer connection,
the two others connections are the WebServer/ImapServers
connections (imapsync stuff).
If the Browser/WebServer connection is timeout or ended,
the imapsync sync is also ended immediately by the remote
Apache https server. Technically, Apache sends a TERM signal
to the imapsync process, then wait some seconds before
sending a KILL signal if it is still alive.
You can relaunch a sync again with "Sync!" button, at any time.
If the "Sync!" button is gray/inactive then just reload
the page (F5 or similar), and reenter the credentials.
If the interface tells you that a sync is already going on,
it may be that a sync is running from another browser or place.
You can stop this sync with the "Abort!" button from any /X
tab/window, even from another browser or place. To be able
to abort with success, you have to give the same account
parameters, same credentials, or imapsync will ignore the demand.
In other words, you can try safely to launch several parallel
runs between the same mailboxes. Open a new tab/windows with /X,
and start the exact same sync. It's safe, the /X will say, if any, that
there is already a current sync running on them and it will present
the logfile running the sync like a "tail -f" command (isn't that magic?).
=====================================================================
=====================================================================