Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

WireLoad is proud to today introduce YippieMove Complete, the latest addition to YippieMove, which adds the missing piece of the puzzle for many small and mid-size companies (SMB) that are considering switching email provider. YippieMove Complete is a package that includes everything needed for a smooth transition, including:

  • Unbiased technical consulting. What is really the best email solution/provider for your needs?
  • Creation of user accounts on the destination server according to your needs
  • Redirecting the email from your old server to the new
  • Transfer of your old emails from the old server to the new server

Since we launched YippieMove, we’ve been contacted by many SMBs that are planning to change email provider for various reasons. Whatever your reason for switching is, YippieMove Complete can help you. We will do all the work for you and let you focus on what’s important to you – your business.

What does email downtime cost you per hour? If you’re an SMB, it’s likely that it costs you thousands of dollars an hour in lost productivity. YippieMove Complete can make sure that the transition goes as smoothly as possible, and in most cases, without any email downtime at all.

YippieMove Complete is starting at only $499.95 with 10 transfers included. If you ened more transfer than that our normal rate applies (including volume discount).

Requirements

The requirements are simple; we need access to your old email server and your DNS records. If you don’t know anything about this, our sales team can provide you with further details. We can even contact your provider directly as a last resort. The second requirement is related to the transfer of the old emails. In order for us to successfully transfer your old emails, the old email server needs to support IMAP.

More info

For more information about YippieMove Complete, visit the product page.

Author: Tags: , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

I think it’s fair to say that few people outside of Google have more experience of working with Google’s IMAP implementation (GIMAP) than we have. Since we launched YippieMove more than six months ago, we’ve performed a lot of transfers to Google using IMAP. Truth be told, we’ve spent a lot of time trying to find workarounds for bugs in Gmail IMAP implementation. In this brief blog-post, we will explore two bugs that we’ve reported to Google, but which Google seems to have little interest in fixing.

Inconsistency between SELECT and CREATE

The first bug might not be very juicy but it took us a while to recognize it. What we first thought was a bug in our system turned out to be a bug in GIMAP. As it turns out, in GIMAP, SELECT is case sensitive, while CREATE is not. Here’s a brief example to illustrate the bug:


0001 SELECT "INBOX/Sales Invoices"
0001 NO Unknown Mailbox: INBOX/Sales Invoices (Failure)
0002 CREATE "INBOX/Sales Invoices"
0002 NO Folder name conflicts with existing folder name. (Failure)

In this case, there is already a folder named ‘INBOX/Sales invoices’, but since SELECT is case sensitive, and CREATE is not, we were unable to select the folder and with an upper case ‘I’ and at the same time unable to create the folder.

We first encountered this bug when a user migrated from a case sensitive IMAP server to Gmail. Hence we could have two folders named ‘foo’ and ‘Foo’ without it being any problem until we tried to copy those to Gmail.

Rejection of random messages

The next bug is of far more serious nature and it is a bug that we run into everyday. We’ve spent a significant amount of time trying to narrow down this problem, but almost entirely without luck. What happens is that GIMAP decides to reject certain emails. Sometimes the upload works when retrying later, sometimes not. To make this even more interesting, GIMAP can reject emails that it just gave us. For instance, let’s say we’re copying messages from [email protected] to [email protected]. Even that a GIMAP just gave us a particular email, another GIMAP server rejects the same email. Strange, isn’t it?

When I said that we’ve spent a serious amount of time trying to narrow down the problem, I was not kidding. We’ve done statistical analysis on tens of thousands of messages trying to find some kind of pattern (including trying to find a correlation between the content in the header and the body), and still no luck.

That said, the failure rate is quite low. Out of all the messages we upload, only a small fraction gets rejected (a quick database query reveals that it’s currently at 0.04%). And if a message gets rejected, we clearly state what message we failed to upload in the Transfer Report that we send out to our customers upon completion.

In Google’s defense, they do state that they do not officially support ‘upload of messages,’ but that is a quite weak argument, as pretty much any other IMAP-enabled service on the market supports this. Not to mention that without APPEND, simple drag and drop operations may fail in email programs.

For the curious geeks reading this article, our software does comply with RFC 3501, as well as other related RFCs.

As a side note, we’re not the only ones experiencing the APPEND bug. The Google Group discussion for Gmail IMAP and POP is full with threads regarding this. The only official-looking response given multiple times by wár17 § is to upload in small batches as you otherwise is likely to hit the bandwidth limit. However, we can testify that this is not the case as the number of messages and the size of the mailbox seem to have little effect. We’ve had this problem with small mailboxes (<10 messages and only a few hundred bytes) and at the same time had mailboxes that exceed several Gigabytes running through flawlessly.

Update: While it seems like the rejection of emails is somewhat random, there are certain emails that are more likely to get rejected. The other day we ran a transfer of a folder including 600-something bounced messages. They were all rejected.

Author: Tags: , , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Jan
28.
Comments Off
Comments
Category: Technology

We recently had to decide on a configuration format for one of our internal utilities. In this post I’ll talk a little about why we picked YAML as the format and the reasoning behind it.

WireLoad has a couple of servers, each running a number of different services. For a long time we had almost one backup script per service, all hand hacked in bash to fit the requirements of the application. This wasn’t great because it meant we repeated a lot of work. To make the situation a little more manageable we developed BackupWire, a simple backup utility in a single file with a minimal number of dependencies.

The design goals of BackupWire were,

  • Minimal footprint: BackupWire shouldn’t be much heavier than the bash scripts we already had. Why? Because if it was huge and difficult to deploy we might end up writing little bash scripts instead!
  • Minimal dependencies: BackupWire should not have many dependencies. This is for the same reason as in the previous point. BackupWire needs to be easy to install.
  • Readable configuration: One of the problems with bash scripts is that once they’re a little complicated it gets hard to see what’s happening. BackupWire’s real purpose is to alleviate that headache by distilling most backup jobs down to a few lines of configuration.

In order to make everything dead simple the configuration was stored in the BackupWire script itself. This would make it easier to relocate the script, and it would decrease the chance that a config file was not found due to things such as the cron environment being sparse. However, this design decision made it hard to update the script with new versions. In addition, the configuration format became a little cumbersome because it was just a set of Python class instantiations. Hence this feature went against the third design goal of BackupWire. The latest version now uses a configuration file instead.

Thinking that the world really doesn’t need another arbitrary configuration syntax, I wanted to pick a standardized configuration format. So I read up on Wikipedia’s entry on configuration files and found the top three contenders: Lua, XML and YAML.

Lua, being a programming language these days, looked like it would add too many dependencies to BackupWire. BackupWire is written in Python, which we already have on all servers, but Lua we don’t use for anything else so it would be a new requirement which would have to be installed on each server. Also, it just struck me as a little excessive to have a full blown second programming language as a configuration format unless the application was really complex.

The other problem with Lua was that googling Lua config tutorial didn’t really give that many good results, making me think that perhaps the focus of the language has shifted from configuration to something else over time.

XML was immediately off the table, perhaps obviously to some of our readers. Most importantly XML is not a very readable language with it’s abundance of symbols and markup. But also, it’s not very easy to write for the same reason. The people behind Django’s documentation put it best when they said, “Making humans edit XML is sadistic!”

YAML is readable and easy to write both. There is also a light weight Python module called PyYAML to read the format. Using YAML the new BackupWire configuration files are definitely to the point and concise without being complicated to edit. Here is an example of the new configuration format we developed in YAML syntax:

name:       "Sample Backup"         
to:         "/backup/"                   
frequency:  "daily"                 

tasks:
 - run: 
   command: 'df -h'
   log_output: True
 - archive:
   name: "etc.tbz"
   contents: ["/etc/", "/opt/etc/"]
 - archive:
   name: "tmp.tbz"
   contents: [ "/tmp/" ]
# Dump a database using a run task with 
# %(targetFolder)s to locate the destination.
 - run:
   command: 'mysqldump --quick --extended-insert 
     --compact --single-transaction 
     -u backup --databases sample 
     | bzip2 >%(targetFolder)s/mysql-sample.sql.bz2'
---

Not too bad as far as readability goes and all standardized YAML to spare the world from yet one more syntax.

Author: Tags:
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

What’s better than having a job that you love? How about not having to work, and still make money? We want to give you this opportunity. Ok, we might not be able to make you a millionaire, but if you are successful, you will be able to make decent money while literally doing nothing.

The way you would be able to do this is though our brand new affiliate program. It’s dead simple. You link to us on your website using your own custom link that we will provide you with. Then, every time a customer comes to us from your site and we make a sale, we will give you 10% of the sale. Are we great or what? Other affiliates programs, such as Amazon’s only gives you 4%.

Affiliate status page

The Affiliate Program status page.

Convinced yet? If so, just head over and sign up right away.

Author: Tags: ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Jan
13.
Comments Off
Comments
Category: Uncategorized

Shortly after getting iReport running using the fix described in this article, we ran into a new problem — the Postgresql support. After some Googeling, it became clear that one had to add the the driver for Postgresql by hand from here. If not, you will encounter this error message:

Error: java.lang.ClassNotFoundException: org.postgresql.Driver

When adding the driver, beware of what version you’re selecting. After banging our heads in the wall for a while, we realized that we picked the wrong version. On Mac OS X 10.5.6 (with all latest updates installed) the version you’re looking for is the ‘JDBC3′ branch (assuming you’re using the java version that comes with OS X). Once we figured this out, the installation was easy. First, download this file. Then you need to move it into the ‘lib’ folder in iReport.

If you’re a console user like us, here are the steps:

cd iReport-3.0.0/lib
wget http://jdbc.postgresql.org/download/postgresql-8.3-604.jdbc3.jar

Easy as pie.

Author: Tags: , , ,

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009 FrederikM.de, based on blueblog_DE by Oliver Wunder.
Sitemap