zydronium/imapsync
1
0
Fork 0
mirror of https://github.com/imapsync/imapsync.git synced 2025-07-22 18:25:54 +02:00
Code Issues Projects Releases Packages Wiki Activity

1.678

Browse source
This commit is contained in:
Nick Bebout 2016-01-22 10:52:28 -06:00
parent c16227350f
commit 629adbb8db
113 changed files with 7581 additions and 43297 deletions
Download patch file Download diff file Expand all files Collapse all files

177
doc/GOOD_PRACTICES.html Normal file
View file

@ -0,0 +1,177 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META NAME="generator" CONTENT="http://txt2tags.org">
</HEAD><BODY BGCOLOR="white" TEXT="black">
<CENTER>
</CENTER>
<P></P>
<HR NOSHADE SIZE=1>
<P></P>
<UL>
<LI><A HREF="#toc1">Best practices for imapsync</A>
<UL>
<LI><A HREF="#toc2">Simple transfer</A>
<LI><A HREF="#toc3">Exact backup</A>
<LI><A HREF="#toc4">Restore</A>
<LI><A HREF="#toc5">Presync</A>
</UL>
</UL>
<P></P>
<HR NOSHADE SIZE=1>
<P></P>
<A NAME="toc1"></A>
<H1>Best practices for imapsync</H1>
<P>
You are not supposed to have read the TUTORIAL documentation but it
reading it should help to understand and master the following best practices.
</P>
<A NAME="toc2"></A>
<H2>Simple transfer</H2>
<P>
By principle, imapsync does not change any single byte of messages,
unless --regexmess or --addheader is used.
But since imapsync identifies messages with "Message-Id" and "Received" headers,
it ignores messages that lack those headers;
most of the time it happens with the "Sent" folders.
A way to sync those messages is to add option --addheader.
Before appending a message on host2, and only when needed,
--addheader option adds a Message-Id header like "Message-Id: &lt;123456789@imapsync&gt;"
where 123456789 is the host1 folder message UID. Messages on host1 stay untouched.
This way, multiples runs will not generate duplicates as long as UIDs stay
the same on host1, which is the case for most imap servers.
</P>
<P>
Unix:
</P>
<PRE>
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--addheader
</PRE>
<P>
Windows:
</P>
<PRE>
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--addheader
</PRE>
<A NAME="toc3"></A>
<H2>Exact backup</H2>
<P>
Assertions for this example:
</P>
<UL>
<LI>The target account at host2 is considered like inactive.
<LI>Everything a user does on host1 will be synced, folders, messages, flags.
<LI>Everything a user does on host2 will be erased by the sync.
<P></P>
Two options are good for an exact backup, --delete2 and --delete2folders.
<P></P>
<LI>--delete2: deletes messages in host2 that are not in host1 server.
<LI>--delete2folders: deletes folders in host2 that are not in host1 server.
<P></P>
Unix:
<PRE>
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--delete2 --delete2folders
</PRE>
Windows:
<PRE>
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--delete2 --delete2folders
</PRE>
</UL>
<P>
Have in mind
</P>
<UL>
<LI>Backupping without restoring at least one time to check the process
is like pissing in a violin or throwing away your messages.
<LI>Manual backups are useless, this way you will never have the ones you need to restore.
<LI>Automatic backups are the way to go. They never forget to start. They may fail.
<LI>Automatic backups can fail. How? Hard disks get fully filled, they crash. Networks fail too.
<LI>Monitor the backups.
<LI>Remenber you have backups.
<LI>Document the restoring process or consider the backup is a just a lost trash.
<LI>Think twice at least before running any restoring command.
</UL>
<A NAME="toc4"></A>
<H2>Restore</H2>
<P>
Restoring is not the exact reverse of backupping
since between a backup and a mistake, the context has changed,
some things went wrong but not all, for examples new messages arrived.
So synchronize an active account identical from a backup might not be the best idea.
</P>
<P>
The context can be a crash or equivalent like when a
not friendly admin or service closed definitevely access to your messages.
Even in that case an exact restore, with --delete2 --delete2folders, should not be ok,
just because new messages arrive in INBOX all the time.
</P>
<A NAME="toc5"></A>
<H2>Presync</H2>
<P>
Presync is like a backup except deleting folders on host2 that
are not on host1 is not always wanted. Presync means a new
different imap server will host messages and folders.
Often this new imap server has predefined folders that
should be kept for proper use, so I suggest to not use
option --delete2folders.
</P>
<P>
Unix:
</P>
<PRE>
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--delete2
</PRE>
<P>
Windows:
</P>
<PRE>
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--delete2
</PRE>
<!-- html code generated by txt2tags 2.6 (http://txt2tags.org) -->
<!-- cmdline: txt2tags -i doc/GOOD_PRACTICES.t2t -t html -\-toc -o doc/GOOD_PRACTICES.html -->
</BODY></HTML>

122
doc/GOOD_PRACTICES.t2t Normal file
View file

@ -0,0 +1,122 @@
% $Id: GOOD_PRACTICES.t2t,v 1.7 2016/01/18 13:27:31 gilles Exp gilles $
= Best practices for imapsync =
You are not supposed to have read the TUTORIAL documentation but it
reading it should help to understand and master the following best practices.
== Simple transfer ==
By principle, imapsync does not change any single byte of messages,
unless --regexmess or --addheader is used.
But since imapsync identifies messages with "Message-Id" and "Received" headers,
it ignores messages that lack those headers;
most of the time it happens with the "Sent" folders.
A way to sync those messages is to add option --addheader.
Before appending a message on host2, and only when needed,
--addheader option adds a Message-Id header like "Message-Id: <123456789@imapsync>"
where 123456789 is the host1 folder message UID. Messages on host1 stay untouched.
This way, multiples runs will not generate duplicates as long as UIDs stay
the same on host1, which is the case for most imap servers.
Unix:
```
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--addheader
```
Windows:
```
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--addheader
```
== Exact backup ==
Assertions for this example:
- The target account at host2 is considered like inactive.
- Everything a user does on host1 will be synced, folders, messages, flags.
- Everything a user does on host2 will be erased by the sync.
Two options are good for an exact backup, --delete2 and --delete2folders.
- --delete2: deletes messages in host2 that are not in host1 server.
- --delete2folders: deletes folders in host2 that are not in host1 server.
Unix:
```
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--delete2 --delete2folders
```
Windows:
```
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--delete2 --delete2folders
```
Have in mind
- Backupping without restoring at least one time to check the process
is like pissing in a violin or throwing away your messages.
- Manual backups are useless, this way you will never have the ones you need to restore.
- Automatic backups are the way to go. They never forget to start. They may fail.
- Automatic backups can fail. How? Hard disks get fully filled, they crash. Networks fail too.
- Monitor the backups.
- Remenber you have backups.
- Document the restoring process or consider the backup is a just a lost trash.
- Think twice at least before running any restoring command.
== Restore ==
Restoring is not the exact reverse of backupping
since between a backup and a mistake, the context has changed,
some things went wrong but not all, for examples new messages arrived.
So synchronize an active account identical from a backup might not be the best idea.
The context can be a crash or equivalent like when a
not friendly admin or service closed definitevely access to your messages.
Even in that case an exact restore, with --delete2 --delete2folders, should not be ok,
just because new messages arrive in INBOX all the time.
== Presync ==
Presync is like a backup except deleting folders on host2 that
are not on host1 is not always wanted. Presync means a new
different imap server will host messages and folders.
Often this new imap server has predefined folders that
should be kept for proper use, so I suggest to not use
option --delete2folders.
Unix:
```
imapsync \
--host1 imap.truc.org --user1 foo --password1 secret1 \
--host2 imap.trac.org --user2 bar --password2 secret2 \
--delete2
```
Windows:
```
imapsync ^
--host1 imap.truc.org --user1 foo --password1 secret1 ^
--host2 imap.trac.org --user2 bar --password2 secret2 ^
--delete2
```

443
doc/TUTORIAL_Unix.html Normal file
View file

@ -0,0 +1,443 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META NAME="generator" CONTENT="http://txt2tags.org">
<TITLE>Imapsync tutorial</TITLE>
</HEAD><BODY BGCOLOR="white" TEXT="black">
<CENTER>
<H1>Imapsync tutorial</H1>
<FONT SIZE="4"><I>Gilles LAMIRAL gilles.lamiral@laposte.net</I></FONT><BR>
<FONT SIZE="4">$Id: TUTORIAL_Unix.t2t,v 1.17 2016/01/21 03:34:23 gilles Exp gilles $ </FONT>
</CENTER>
<P></P>
<HR NOSHADE SIZE=1>
<P></P>
<UL>
<LI><A HREF="#toc1">1. Good practices</A>
<LI><A HREF="#toc2">2. Basic steps</A>
<UL>
<LI><A HREF="#toc3">2.1. Verifying imapsync works well on its own</A>
<LI><A HREF="#toc4">2.2. Working with your data</A>
<LI><A HREF="#toc5">2.3. Prepare your credentials</A>
<LI><A HREF="#toc6">2.4. Take a real user account as source</A>
<LI><A HREF="#toc7">2.5. Take a test user account as destination</A>
</UL>
<LI><A HREF="#toc8">3. Background knowledge about emailboxes</A>
<LI><A HREF="#toc9">4. Conventions</A>
<LI><A HREF="#toc10">5. Why start with a test account on destination host2?</A>
<LI><A HREF="#toc11">6. Imapsync default behaviour</A>
</UL>
<P></P>
<HR NOSHADE SIZE=1>
<P></P>
<A NAME="toc1"></A>
<H1>1. Good practices</H1>
<UL>
<LI>Do the basic steps showing imapsync works by itself.
<P></P>
<LI>Next, applying imapsync to your data,
continue with a <B>real user</B> account on the source imap server (host1)
and a <B>test</B> account on the destination imap server (host2).
<P></P>
It's the best advice I can give to learn imapsync, be confident in it, and
verify it will do what you expect it to do in your context, all of that
without much pain. So try imapsync with a real account at the source, aka host1,
and a test account at the destination, aka host2.
<P></P>
<LI>Next, once familiar and satified by the result on the host2 test account,
change to a real user account on host2 or just stop consider it a test one.
</UL>
<A NAME="toc2"></A>
<H1>2. Basic steps</H1>
<A NAME="toc3"></A>
<H2>2.1. Verifying imapsync works well on its own</H2>
<P>
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 <CODE>imapsync-1.xxx</CODE> where <CODE>1.xxx</CODE>
is imapsync release number (1.675 or upper).
</P>
<PRE>
cd imapsync-1.xxx/
</PRE>
<P>
Verify imapsync runs on your system
</P>
<PRE>
./imapsync
</PRE>
<P>
It should outpout the help message. The help message is also at
<A HREF="http://imapsync.lamiral.info/OPTIONS">http://imapsync.lamiral.info/OPTIONS</A> but you don't have to read it now.
</P>
<P>
If the previous command fails then there is an installation issue.
Go back to <A HREF="http://imapsync.lamiral.info/#doc">http://imapsync.lamiral.info/#doc</A> and read INSTALL file
or drop me an email.
</P>
<P>
Next, verify imapsync runs live tests. This check needs internet
access. It does a simple sync between two real dedicated
imap maiboxes located at test.lamiral.info.
</P>
<PRE>
./imapsync --testslive
</PRE>
<P>
Now verify the script examples/imapsync_example.sh runs
</P>
<PRE>
sh examples/imapsync_example.sh
</PRE>
<P>
This script does the same thing than "<CODE>imapsync --testslive</CODE>" but it
uses explicitely the 6 parameters so it'll a good start
for your future own script.
</P>
<A NAME="toc4"></A>
<H2>2.2. Working with your data</H2>
<P>
You're still in the imapsync directory.
</P>
<P>
Copy the script <CODE>examples/imapsync_example.sh</CODE>
</P>
<PRE>
cp examples/imapsync_example.sh mysync
</PRE>
<P>
Check that the copy works as the original
</P>
<PRE>
sh mysync
</PRE>
<P>
So far so good, now we're going to work with your data.
</P>
<A NAME="toc5"></A>
<H2>2.3. Prepare your credentials</H2>
<P>
An IMAP account is accessed with 3 parameters,
</P>
<UL>
<LI>the imap server <B>host</B>. It's a server name or an ip address.
<LI>the <B>user</B> name.
<LI>the <B>password</B>.
</UL>
<P>
Since imapsync job is to sync two imap accounts we need 3 + 3 = 6 parameters.
</P>
<UL>
<LI>Three parameters to read from the source account, <B>host1</B>, <B>user1</B> and <B>password1</B>.
<LI>Three parameters to write to the destination account, <B>host2</B>, <B>user2</B> and <B>password2</B>.
</UL>
<A NAME="toc6"></A>
<H2>2.4. Take a real user account as source</H2>
<P>
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.
</P>
<P>
Assuming that the imap source server name host1 is <B>imaphost1.mydomain.tld</B>,
the user1 account name is <B>myuser1</B> and its password is <B>mysecret1</B>,
we now have the first three parameters.
</P>
<UL>
<LI>--host1 <B>imaphost1.mydomain.tld</B>
<LI>--user1 <B>myuser1</B>
<LI>--password1 <B>mysecret1</B>
</UL>
<A NAME="toc7"></A>
<H2>2.5. Take a test user account as destination</H2>
<P>
Unlike the source side, the destination side will be modified by
imapsync. Therefore, for learning, checking and adjusting,
it is not a very good idea to use a real user imap account
the first times you play with imapsync.
</P>
<P>
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.
</P>
<P>
Assuming that the imap destination server name host2 is <B>imaphost2.mydomain.tld</B>,
the user2 account name is <B>myuser2</B> and its password is <B>mysecret2</B>,
we now have the next three parameters.
</P>
<UL>
<LI>--host2 <B>imaphost2.mydomain.tld</B>
<LI>--user2 <B>myuser2</B>
<LI>--password2 <B>mysecret2</B>
<P></P>
++ Edit your own script mysync ++
<P></P>
Now edit the script <CODE>mysync</CODE> and replace the test values by yours.
<P></P>
You're ready for a dry test on your accounts.
<P></P>
<PRE>
sh mysync
</PRE>
<P></P>
Since 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
or not, by a successful login or a failure. You will also observe
if the folders mapping is ok.
<P></P>
If a login fails then double-check all three values that identify
the account, which are the host, the login name, and the password.
<P></P>
If the folders mapping proposed is not ok then you can fix it with
option --f1f2, like this example:
</UL>
<PRE>
... --f1f2 "Sent Messages=Sent"
</PRE>
<P>
As explained in the inline help or in the README:
</P>
<PRE>
--f1f2 str1=str2 : Force folder str1 to be synced to str2.
</PRE>
<P>
You're ready for a real test on your accounts, resticted to
folders. Remove --dry from mysync and rerun it:
</P>
<PRE>
sh mysync
</PRE>
<A NAME="toc8"></A>
<H1>3. Background knowledge about emailboxes</H1>
<P>
Three Internet protocols are used to access almost all email accounts:
POP3, IMAP, HTTP.
</P>
<P>
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.
</P>
<P>
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.
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.
</P>
<P>
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.
</P>
<P>
The conclusion of this protocol review is that IMAP can be used
to access mailboxes most of the time. Here comes imapsync.
</P>
<P>
Software imapsync is a command line tool to
copy, migrate, backup or synchronize IMAP mailboxes.
</P>
<P>
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,
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.
</P>
<P>
Don't be afraid, the mouse won't be forsaken.
You can still use the mouse to launch an editor,
select/copy/paste complete examples,
and run the little script with a doubleclick.
</P>
<P>
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.
</P>
<P>
While operating systems have a lot in common, they sometimes differ,
especially within syntax. I won't blame anyone, historically Windows
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!
</P>
<P>
To avoid you to learn by headaches a system you do not master
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.
</P>
<A NAME="toc9"></A>
<H1>4. Conventions</H1>
<P>
In order to simplify display or print,
each imapsync command line is usually written in several lines
but it could be written in one single line.
</P>
<P>
If you prefer to use the whole command written in one single line then
just remove the last visible character of each line 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.
</P>
<P>
For example, on Unix
</P>
<PRE>
imapsync \
--host1 test.lamiral.info \
--user1 test1 \
--password1 secret1 \
...
</PRE>
<P>
is equivalent to
</P>
<PRE>
imapsync --host1 test.lamiral.info --user1 test1 --password1 secret1 ...
</PRE>
<P>
and on Windows
</P>
<PRE>
imapsync.exe ^
--host1 test.lamiral.info ^
--user1 test1 ^
--password1 secret1 ^
...
</PRE>
<P>
is equivalent to
</P>
<PRE>
imapsync --host1 test.lamiral.info --user1 test1 --password1 secret1 ...
</PRE>
<A NAME="toc10"></A>
<H1>5. Why start with a test account on destination host2?</H1>
<P>
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.
</P>
<P>
It's not the same for destination accounts as imapsync writes on host2 accounts.
Imapsync creates folders on them, add messages, set flags on messages.
It isn't a safe behavior on a real account. So don't use a real user account
to test imapsync. Learn to use it and see what it does on a test account at host2.
</P>
<P>
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.
</P>
<A NAME="toc11"></A>
<H1>6. Imapsync default behaviour</H1>
<P>
By default, so unless explicitely told to do something else:
</P>
<UL>
<LI>Imapsync syncs all folders of host1
<LI>Imapsync syncs all messages from host1, except duplicates.
<LI>Imapsync syncs all flags, at least all allowed by host2.
<P></P>
</UL>
<OL>
<LI>To go further with imapsync +
<P></P>
Imapsync has many options but you can ignore most of them
and still make great transfers.
<P></P>
</OL>
<UL>
<LI>Option names all begin with two minus characters <CODE>--</CODE>, like <CODE>--automap</CODE> or <CODE>--dry</CODE> etc.
<LI>Option names relative to the <B>source</B> account are ended with <B>1</B>, like <CODE>--host1</CODE>
<LI>Option names relative to the <B>destination</B> account are ended with <B>2</B>, like <CODE>--host2</CODE>
<LI>Some options need a <B>value</B>, like <CODE>--host1</CODE> <B><CODE>source.server.tld</CODE></B>
<LI>Some options are standalone, like <B><CODE>--ssl1</CODE></B>
<LI>Any order is possible but when an option needs a value then the value must follow its option name, of course.
</UL>
<!-- html code generated by txt2tags 2.6 (http://txt2tags.org) -->
<!-- cmdline: txt2tags -i doc/TUTORIAL_Unix.t2t -t html -\-toc -o doc/TUTORIAL_Unix.html -->
</BODY></HTML>

313
doc/TUTORIAL_Unix.t2t Normal file
View file

@ -0,0 +1,313 @@
Imapsync tutorial
Gilles LAMIRAL gilles.lamiral@laposte.net
$Id: TUTORIAL_Unix.t2t,v 1.17 2016/01/21 03:34:23 gilles Exp gilles $
+ Good practices +
- Do the basic steps showing imapsync works by itself.
- Next, applying imapsync to your data,
continue with a **real user** account on the source imap server (host1)
and a **test** account on the destination imap server (host2).
It's the best advice I can give to learn imapsync, be confident in it, and
verify it will do what you expect it to do in your context, all of that
without much pain. So try imapsync with a real account at the source, aka host1,
and a test account at the destination, aka host2.
- Next, once familiar and satified by the result on the host2 test account,
change to a real user account on host2 or just stop consider it a test one.
+ Basic steps +
++ Verifying imapsync works well on its own ++
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).
```
cd imapsync-1.xxx/
```
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.
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.
Next, verify imapsync runs live tests. This check needs internet
access. It does a simple sync between two real dedicated
imap maiboxes located at test.lamiral.info.
```
./imapsync --testslive
```
Now verify the script examples/imapsync_example.sh runs
```
sh examples/imapsync_example.sh
```
This script does the same thing than "``imapsync --testslive``" but it
uses explicitely the 6 parameters so it'll a good start
for your future own script.
++ Working with your data ++
You're still in the imapsync directory.
Copy the script ``examples/imapsync_example.sh``
```
cp examples/imapsync_example.sh mysync
```
Check that the copy works as the original
```
sh mysync
```
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**.
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**.
++ 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.
Assuming that the imap source server name host1 is **imaphost1.mydomain.tld**,
the user1 account name is **myuser1** and its password is **mysecret1**,
we now have the first three parameters.
- --host1 **imaphost1.mydomain.tld**
- --user1 **myuser1**
- --password1 **mysecret1**
++ Take a test user account as destination ++
Unlike the source side, the destination side will be modified by
imapsync. Therefore, for learning, checking and adjusting,
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.
Assuming that the imap destination server name host2 is **imaphost2.mydomain.tld**,
the user2 account name is **myuser2** and its password is **mysecret2**,
we now have the next three parameters.
- --host2 **imaphost2.mydomain.tld**
- --user2 **myuser2**
- --password2 **mysecret2**
++ Edit your own script mysync ++
Now edit the script ``mysync`` and replace the test values by yours.
You're ready for a dry test on your accounts.
```
sh mysync
```
Since 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
or not, by a successful login or a failure. You will also observe
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:
```
... --f1f2 "Sent Messages=Sent"
```
As explained in the inline help or in the README:
```
--f1f2 str1=str2 : Force folder str1 to be synced to str2.
```
You're ready for a real test on your accounts, resticted to
folders. Remove --dry from mysync and rerun it:
```
sh mysync
```
+ Background knowledge about emailboxes +
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 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.
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.
The conclusion of this protocol review is that IMAP can be used
to access mailboxes most of the time. Here comes imapsync.
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,
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.
Don't be afraid, the mouse won't be forsaken.
You can still use the mouse to launch an editor,
select/copy/paste complete examples,
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.
While operating systems have a lot in common, they sometimes differ,
especially within syntax. I won't blame anyone, historically Windows
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.
OS X users are in the Unix world nowadays so they must follow
the Unix examples.
+ Conventions +
In order to simplify display or print,
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
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.
For example, on Unix
```
imapsync \
--host1 test.lamiral.info \
--user1 test1 \
--password1 secret1 \
...
```
is equivalent to
```
imapsync --host1 test.lamiral.info --user1 test1 --password1 secret1 ...
```
and on Windows
```
imapsync.exe ^
--host1 test.lamiral.info ^
--user1 test1 ^
--password1 secret1 ^
...
```
is equivalent to
```
imapsync --host1 test.lamiral.info --user1 test1 --password1 secret1 ...
```
+ Why start with a test account on destination host2? +
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.
It's not the same for destination accounts as imapsync writes on host2 accounts.
Imapsync creates folders on them, add messages, set flags on messages.
It isn't a safe behavior on a real account. So don't use a real user account
to test imapsync. Learn to use it and see what it does on a test account at host2.
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.
+ 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.
+ 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.