mirror of
https://github.com/imapsync/imapsync.git
synced 2025-06-11 07:04:36 +02:00
1.836
This commit is contained in:
parent
3afeea4a16
commit
8d76e44c5e
243 changed files with 57452 additions and 10330 deletions
|
@ -1,10 +1,10 @@
|
|||
Imapsync tutorial
|
||||
Gilles LAMIRAL gilles.lamiral@laposte.net
|
||||
$Id: TUTORIAL_Unix.t2t,v 1.18 2016/02/04 03:27:01 gilles Exp gilles $
|
||||
$Id: TUTORIAL_Unix.t2t,v 1.23 2017/09/07 12:09:15 gilles Exp gilles $
|
||||
|
||||
+ Good practices +
|
||||
+ Good practices overview +
|
||||
|
||||
- Do the basic steps showing imapsync works by itself.
|
||||
- Do the basic checks showing imapsync works by itself where you run it.
|
||||
|
||||
- Next, applying imapsync to your data,
|
||||
continue with a **real user** account on the source imap server (host1)
|
||||
|
@ -28,7 +28,7 @@ change to a real user account on host2 or just stop consider it a test one.
|
|||
Open a terminal and go to the imapsync directory.
|
||||
The imapsync directory is the directory created by extraction
|
||||
of the tarball (.tgz), its name is ``imapsync-1.xxx`` where ``1.xxx``
|
||||
is imapsync release number (1.675 or upper).
|
||||
is imapsync release number (1.836 at the time of this writing).
|
||||
|
||||
```
|
||||
cd imapsync-1.xxx/
|
||||
|
@ -38,16 +38,16 @@ Verify imapsync runs on your system
|
|||
```
|
||||
./imapsync
|
||||
```
|
||||
It should outpout the help message. The help message is also at
|
||||
http://imapsync.lamiral.info/OPTIONS but you don't have to read it now.
|
||||
It should outpout the help message.
|
||||
|
||||
If the previous command fails then there is an installation issue.
|
||||
Go back to http://imapsync.lamiral.info/#doc and read INSTALL file
|
||||
or drop me an email.
|
||||
Go back to https://imapsync.lamiral.info/#install then
|
||||
and read and apply the installation file corresponding to your
|
||||
system and drop me an email about your issue.
|
||||
|
||||
Next, verify imapsync runs live tests. This check needs internet
|
||||
Next, verify imapsync runs live tests. This check needs an internet
|
||||
access. It does a simple sync between two real dedicated
|
||||
imap maiboxes located at test.lamiral.info.
|
||||
imap maiboxes located at the host test.lamiral.info
|
||||
```
|
||||
./imapsync --testslive
|
||||
```
|
||||
|
@ -64,7 +64,7 @@ for your future own script.
|
|||
|
||||
You're still in the imapsync directory.
|
||||
|
||||
Copy the script ``examples/imapsync_example.sh``
|
||||
Make a copy of the script ``examples/imapsync_example.sh``
|
||||
```
|
||||
cp examples/imapsync_example.sh mysync
|
||||
```
|
||||
|
@ -78,27 +78,28 @@ So far so good, now we're going to work with your data.
|
|||
++ Prepare your credentials ++
|
||||
|
||||
An IMAP account is accessed with 3 parameters,
|
||||
- the imap server **host**. It's a server name or an ip address.
|
||||
- the **user** name.
|
||||
- the **password**.
|
||||
- the imap server **host**. It's a server name or an ip address
|
||||
- the **user** name
|
||||
- the **password**
|
||||
|
||||
|
||||
Since imapsync job is to sync two imap accounts we need 3 + 3 = 6 parameters.
|
||||
- Three parameters to read from the source account, **host1**, **user1** and **password1**.
|
||||
- Three parameters to write to the destination account, **host2**, **user2** and **password2**.
|
||||
Since imapsync job is to sync two imap accounts we need 3 + 3 = 6 parameters:
|
||||
- Three parameters in order to read data from the source account: **host1**, **user1** and **password1**
|
||||
- Three parameters in order to copy this data to the destination account: **host2**, **user2** and **password2**
|
||||
|
||||
|
||||
++ Take a real user account as source ++
|
||||
|
||||
Even to learn and get familiar with imapsync, you can take a
|
||||
real user account as a source. No problem if it's currently used
|
||||
by a user.
|
||||
real user account as a source. There is also no problem if this account is
|
||||
currently used by a user. By default, this account will only be read, no change will
|
||||
be made by imapsync on it.
|
||||
|
||||
Assuming that the imap source server name host1 is **imaphost1.mydomain.tld**,
|
||||
Assuming that the imap source server name host1 is **origin.example.com**,
|
||||
the user1 account name is **myuser1** and its password is **mysecret1**,
|
||||
we now have the first three parameters.
|
||||
|
||||
- --host1 **imaphost1.mydomain.tld**
|
||||
- --host1 **origin.example.com**
|
||||
- --user1 **myuser1**
|
||||
- --password1 **mysecret1**
|
||||
|
||||
|
@ -111,13 +112,14 @@ it is not a very good idea to use a real user imap account
|
|||
the first times you play with imapsync.
|
||||
|
||||
If you really can't afford a test account on host2, it's ok,
|
||||
imapsync is not that bad but you may have work to fix unwanted behaviour.
|
||||
imapsync is not that bad but you may have some work to do to fix some unwanted behaviour.
|
||||
Unwanted behaviour is mostly folders names that you don't want to be the same on both sides.
|
||||
|
||||
Assuming that the imap destination server name host2 is **imaphost2.mydomain.tld**,
|
||||
Assuming that the imap destination server name host2 is **destiny.example.com**,
|
||||
the user2 account name is **myuser2** and its password is **mysecret2**,
|
||||
we now have the next three parameters.
|
||||
|
||||
- --host2 **imaphost2.mydomain.tld**
|
||||
- --host2 **destiny.example.com**
|
||||
- --user2 **myuser2**
|
||||
- --password2 **mysecret2**
|
||||
|
||||
|
@ -132,19 +134,22 @@ You're ready for a dry test on your accounts.
|
|||
sh mysync
|
||||
```
|
||||
|
||||
Since mysync script is a copy of examples/imapsync_example.sh,
|
||||
Since the ``mysync`` script is a copy of ``examples/imapsync_example.sh``,
|
||||
your first run with your data should include three other options
|
||||
--automap --justfolders --dry.
|
||||
With --dry option, nothing will really be done on host2
|
||||
but you will test whether the credentials are ok on both sides
|
||||
``--automap`` ``--justfolders`` ``--dry``.
|
||||
With ``--dry`` option, nothing will really be done on host2
|
||||
but yet it will test whether the credentials are ok on both sides
|
||||
or not, by a successful login or a failure. You will also observe
|
||||
if the folders mapping is ok.
|
||||
if the folders mapping is ok.
|
||||
|
||||
If a login fails then double-check all three values that identify
|
||||
the account, which are the host, the login name, and the password.
|
||||
|
||||
If the folders mapping proposed is not ok then you can fix it with
|
||||
option --f1f2, like this example:
|
||||
option ``--f1f2``, like the following example mapping source folder
|
||||
"Sent Messages" to the destination folder "Sent". The double-quotes
|
||||
are not part of the folders names but they should be used when special
|
||||
characters like blanks are in the folders names:
|
||||
|
||||
|
||||
```
|
||||
|
@ -157,8 +162,7 @@ As explained in the inline help or in the README:
|
|||
```
|
||||
|
||||
You're ready for a real test on your accounts, resticted to
|
||||
folders. Remove --dry from mysync and rerun it:
|
||||
|
||||
folders. Remove ``--dry`` from the ``mysync`` script and rerun ``mysync``:
|
||||
|
||||
```
|
||||
sh mysync
|
||||
|
@ -171,40 +175,48 @@ sh mysync
|
|||
Three Internet protocols are used to access almost all email accounts:
|
||||
POP3, IMAP, HTTP.
|
||||
|
||||
The oldest one still used is POP3, Post Office Protocol. POP3 allows only
|
||||
one main box called INBOX. With POP3 messages have no flags, no Seen/UnSeen
|
||||
Forwarded Flagged labels. Messages are often
|
||||
removed from the POP3 server each time a software client looks into it,
|
||||
so messages only appear on the client host that fetched them, they are
|
||||
unavailable from any other system located elsewhere.
|
||||
The oldest protocol still used to access mailboxes is POP3, the Post Office Protocol.
|
||||
POP3 gives access to only one main box called INBOX.
|
||||
With POP3, messages have no flags at all, no Seen/UnSeen, Forwarded, or Flagged labels.
|
||||
It's not systematic but messages are often removed from the POP3 server
|
||||
each time a software client looks into it,
|
||||
so messages only appear on the client host that fetched them,
|
||||
then they are unavailable from any other system located elsewhere.
|
||||
|
||||
|
||||
The second protocol to deal with email messages is IMAP, Internet Message Access Protocol.
|
||||
IMAP allows a hierarchy of mailboxes also called folders, also concurrent accesses,
|
||||
tagging with flags, search by many criterium like date, subject, size etc.
|
||||
IMAP gives access to a hierarchy of mailboxes also called folders. Other IMAP features are
|
||||
concurrent accesses, tagging with flags, search by many criterium like date, subject, size etc.
|
||||
The IMAP protocol presents most of the features POP lacks.
|
||||
Messages stay on the imap server so any client on the network can access them
|
||||
at any time from anywhere, the same messages with the same flags.
|
||||
|
||||
The third protocol to access email messages is HTTP, HyperText Transfer Protocol.
|
||||
HTTP is the protocol to browse the web.
|
||||
Web browsers like Google Chrome, Mozilla Firefox, Internet Explorer, Safari,
|
||||
are HTTP client softwares.
|
||||
Webmails often offer the same features than imap servers because
|
||||
webmails underlying storage systems are often imap servers.
|
||||
So webmail mailboxes like Gmail, Yahoo, Exchange, Zimbra or Office365 are also accessible via imap.
|
||||
Web browsers like Google Chrome, Mozilla Firefox, Internet Explorer and Safari
|
||||
are HTTP client softwares. You already know that so what's the point with HTTP mailboxes?
|
||||
HTTP mailboxes are called webmails.
|
||||
Webmails often offer the same features as imap servers do
|
||||
because webmails underlying storage systems are often imap servers.
|
||||
So webmails systems like Gmail, Yahoo, Exchange, Zimbra or Office365 are also accessible via imap.
|
||||
|
||||
The conclusion of this protocol review is that IMAP can be used
|
||||
to access mailboxes most of the time. Here comes imapsync.
|
||||
The conclusion of this protocol review is that mailboxes can be
|
||||
accessed using the IMAP protocol, most of the time.
|
||||
Here comes imapsync.
|
||||
|
||||
In case the source mailbox is only accessible by the POP protocol,
|
||||
you can use the tool ``pop2imap`` located at http://www.linux-france.org/prj/pop2imap/
|
||||
|
||||
|
||||
+ Imapsync presentation +
|
||||
|
||||
Software imapsync is a command line tool to
|
||||
copy, migrate, backup or synchronize IMAP mailboxes.
|
||||
|
||||
|
||||
Command line means imapsync is not graphical, it is textual.
|
||||
Usually with command line tools you have to type characters
|
||||
on your keyboard. But your fingers won't suffer much pain
|
||||
typing on the keyboard because working script examples are available,
|
||||
typing on the keyboard because script examples are given,
|
||||
nearly ready to run. Most of the time you only have to change
|
||||
the main values in those files and adapt them to your context.
|
||||
|
||||
|
@ -215,7 +227,7 @@ and run the little script with a doubleclick.
|
|||
|
||||
Imapsync runs on Linux, Windows and OS X (Macintosh world).
|
||||
Imapsync is written in the Perl language and thanks to the
|
||||
Perl developpers, Perl runs everywhere, so does imapsync.
|
||||
Perl developpers, Perl runs mostly everywhere, so does imapsync.
|
||||
|
||||
While operating systems have a lot in common, they sometimes differ,
|
||||
especially within syntax. I won't blame anyone, historically Windows
|
||||
|
@ -223,8 +235,8 @@ came after Unix. The marvelous designers in this old times
|
|||
decided it would be very cool to not share exactly the same syntax
|
||||
for doing the same things. Thanks guys, great thinking!
|
||||
|
||||
To avoid you to learn by headaches a system you do not master
|
||||
I will give examples in both worlds, Unix and Windows.
|
||||
To avoid you some headaches with systems no one masters
|
||||
I will give examples in both worlds, Unix and Windows.
|
||||
OS X users are in the Unix world nowadays so they must follow
|
||||
the Unix examples.
|
||||
|
||||
|
@ -236,13 +248,12 @@ each imapsync command line is usually written in several lines
|
|||
but it could be written in one single line.
|
||||
|
||||
If you prefer to use the whole command written in one single line then
|
||||
just remove the last visible character of each line and
|
||||
just remove the last visible character of each line ( \ or ^ ) and
|
||||
also the carriage return character.
|
||||
The last visible character meaning "command continues on next line"
|
||||
is the backslash \ character on Unix examples
|
||||
or the caret ^ character on Windows examples.
|
||||
The last visible character means "command continues on next line";
|
||||
it is the backslash \ character on Unix and the caret ^ character on Windows.
|
||||
|
||||
For example, on Unix
|
||||
For example, on Unix, a command like the following
|
||||
|
||||
```
|
||||
imapsync \
|
||||
|
@ -274,8 +285,9 @@ is equivalent to
|
|||
A little explanation about this hint.
|
||||
Imapsync is safe with accounts on host1,
|
||||
it doesn't change anything on them, it just read them.
|
||||
The exception of this safe principle is when --delete option is used,
|
||||
since --delete removes on host1 each message successfully copied to host2.
|
||||
The exception of this safe principle is when ``--delete1`` option is used,
|
||||
since ``--delete1`` removes on host1 each message successfully copied to host2,
|
||||
messages that couldn't be transferred stay on host1.
|
||||
|
||||
|
||||
It's not the same for destination accounts as imapsync writes on host2 accounts.
|
||||
|
@ -286,29 +298,31 @@ to test imapsync. Learn to use it and see what it does on a test account at host
|
|||
What can badly happen? The most common bad behaviour is
|
||||
the folders mapping won't be what you expect because it is strictly
|
||||
reproduced from host1 to host2. The second bad behaviour is
|
||||
duplicates on second run and after, it's rare but it can happen,
|
||||
depending on imap server software changing headers. Solutions
|
||||
to avoid duplicates are often easy. It's also possible to remove
|
||||
the duplicates on host2 but it's better to avoid them on user accounts,
|
||||
users won't like you mess up their mailboxes.
|
||||
duplicates on second run and after, it's rare but it can happen
|
||||
when a imap server software changes headers "``Message-Id``" or "``Received``".
|
||||
Solutions to avoid duplicates are often easy (There's a FAQ called ``FAQ.Duplicates.txt`` about that).
|
||||
It's also possible to remove the duplicates on host2 but it's better to avoid them on user accounts at first,
|
||||
users won't like that you mess up their mailboxes.
|
||||
|
||||
+ Imapsync default behaviour +
|
||||
|
||||
By default, so unless explicitely told to do something else:
|
||||
- Imapsync syncs all folders of host1
|
||||
- Imapsync syncs all messages from host1, except duplicates.
|
||||
- Imapsync syncs all flags, at least all allowed by host2.
|
||||
By default, unless explicitely told to do something else:
|
||||
- Imapsync **goes ssl or tls** if possible
|
||||
- Imapsync syncs **all folders** of host1
|
||||
- Imapsync syncs **all messages** from host1, except duplicates.
|
||||
- Imapsync syncs **all flags**, at least all allowed by host2.
|
||||
|
||||
|
||||
+ To go further with imapsync +
|
||||
|
||||
Imapsync has many options but you can ignore most of them
|
||||
and still make great transfers.
|
||||
|
||||
- Option names all begin with two minus characters ``--``, like ``--automap`` or ``--dry`` etc.
|
||||
- Option names relative to the **source** account are ended with **1**, like ``--host1``
|
||||
- Option names relative to the **destination** account are ended with **2**, like ``--host2``
|
||||
- Some options need a **value**, like ``--host1`` **``source.server.tld``**
|
||||
- Some options are standalone, like **``--ssl1``**
|
||||
- Any order is possible but when an option needs a value then the value must follow its option name, of course.
|
||||
- Option names all begin with two minus characters ``--``, like ``--automap`` or ``--dry`` etc. (using one minus, like ``-dry``, is ok)
|
||||
- Option names relative to the **source** account are ended with the number one **``1``**, like in ``--host1``
|
||||
- Option names relative to the **destination** account are ended with the number two **``2``**, like in ``--host2``
|
||||
- Some options need a **value** just after them, like ``--host1`` **``source.example.com``**, (the value is ``source.example.com``)
|
||||
- Some options are standalone, like **``--automap``**
|
||||
- Any order is possible but when an option needs a value then the value must follow immediately its option name.
|
||||
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue