Migrating emails from one server to another using imap

I recently switched the email hosting from one provider to another. I always set email up as IMAP so the mail is stored and can be accessed and synchronised on multiple devices. This ‘How to’ is based on you having a similar setup. There are tools out there that perform this task automatically but being a control freak I wanted to do this manually to ensure all went well.

Presumptions:

  • You have an IMAP mail account on one server, and you want to migrate this account and the messages to another server.
  • The old server is still up and running and the nameservers still point to the existing hosting (e.g. the server you are migrating the messages from)
  1. Create a mail account with the new provider that exactly mirrors settings of the existing account on the old provider e.g. same user, same password, same email address
  2. Install an additional email client on your desktop system – I recommend a separate client from your main client in case it all goes awry. I’ve successfully tested it with the same client when using Thunderbird 3 but ymmv.
  3. Set up the old mail account in thunderbird  (the provider you’re migrating from)
  4. Important: Ensure the account is setup as IMAP in Thunderbird
  5. Deselect any default junk mail options (This stops Thunderbird  from automatically moving mails to different mail boxes)
  6. Let Thunderbird connect to the old mail account and download all emails
  7. Set up the new mail account in thunderbird (the provider you’re migrating to) – You will need to use the ip address of the new server as the imap and smtp dns names aren’t pointing to the new provider yet
  8. Once Thunderbirds has connected and and set up the inbox you will need to create the folder in the new mail account, mirroring the folders in the old account on the old servers
  9. In the OLD Mail account (the one you are migrating from), select each mail folder, CTRL+A to select all the messages, right click and choose ‘Copy to…’ and select the equivalent folder on the NEW server version of the account
  10. Repeat step 9 for all folders/messages in the account (don’t forget the Sent items!)

Users susceptible to man-in-the-middle attacks due to corporate https inspection

A large number of companies use “security” products to inspect HTTPS traffic for detecting malware and prevent other types of attacks. However, they might inadvertently make their user’s more susceptible to man-in-the-middle attacks by  decrypting and re-encrypting HTTPS connections.

The U.S. Computer Emergency Readiness Team (US-CERT) warns in an advisory that HTTPS inspection products don’t mirror the security attributes of the original HTTPS connections between the client and the server (Mirror: HTTPS Interception Weakens TLS Security | US-CERT).

HTTPS inspection is deployed in companies for checking the encrypted traffic coming from an HTTPS website to make sure it does not contain any malware or any other type of attacks. It basically performs a decryption and re-encryption of the client’s connection to an HTTPS server. The “security” products (proxy, web-gateway, firewall etc.) establish the connection on the client’s behalf by first decrypting the client’s HTTPS connection and re-encrypting the traffic sent to the HTTPS server. The client is served with a different, locally generated certificate by the security product which essentially perform a man-in-the-middle attack.

In some enterprise environments, an HTTPS connection may even be intercepted and re-encrypted multiple times. For example, at the network perimeter by a security gateway product and later, on the endpoint by a client’s antivirus program which needs to inspect the traffic for malware.

The problem revolves around the fact that the client’s browser no longer validates the real certificate issued by the server because its replaced with a locally generated certificate from the security product. In return, the task of validating the certificate now falls to the intercepting proxy.

According to the published advisory, those security products are evidently pretty bad at validating server certificates. An investigation conducted by researches from Google, Mozilla, Cloudfare, and multiple Universities states that the intercepted connections use weaker cryptographic algorithms (Source: interception-ndss17). The security products even advertise support for known-broken encryption ciphers that would allow an active man-in-the-middle attack by intercepting and downgrading a connection in order to decrypt it.

The analysis by the researches found that at least 32 percent of connections to e-comerce sites and 54 percent of Cloudflare HTTPS connections, which were intercepted, became less secure than they would have been if the user had connected directly to the server.

Browser makers had a long time to properly unterstand the quirks of TLS connections and certificate validation. Therefore, there is no better client-side implementation of TLS, the protocol used for encrypting HTTPS connection, than the one found in modern browsers.
In comparison, security product vendors use outdated, customised TLS libraries where they even back-port new protocol features. Re-implementing those features found in newer libraries makes them susceptible to serious vulnerabilities.

Furthermore, the US-CERT points out another widespread problem that many products intercepting HTTPS don’t properly validate the certificate chain presented by servers. Certificate-chain verification errors are infrequently forwarded to the client, leading the client to believe that operations were performed with the correct server.

The BadSSL website allows organisations and even employees to check if their HTTPS inspection products improperly validate certificates or allow for insecure ciphers. The client test from Qualys SSL Labs also provides checks for some known TLS vulnerabitiles and weakenesses.

 

Source Code Formatter for Blogspot

Add the following CSS Style to your Blogger template


pre.source-code {
font-family : Andale Mono, Lucida Console, Monaco, fixed, monospace;
color : #000;
background-color : #eee;
font-size : 12px;
border : 1px dashed #999999;
line-height : 14px;
padding : 5px;
overflow : auto;
width : auto;
text-indent : 0px;
}

surround your code with the following tags to add the source-code formatter:




chris@blogspot.com:~$ who

chris    tty7         2010-09-09 7:52 AM

For a long time I thought about documenting my technical adventures. Since I was a child I’ve been tinkering with computers and related technologies from mobile phones to game consoles to laptops. Challenging problems are inevitable and so I spend a considerable amount of time looking for nifty tricks and solutions to issues I enctounter. I thought about documenting my findings and solutions in a wiki or blog but never actually realized it. Instead, I wrote short how-tos and saved them locally in text-files. I hope that by sharing my tutorials I can help people facing the same problems. (^_^)

Thank you for reading my posts.