Posted on Jan 27th 2009 by matt.
Some people have written in confused about why Emailchemy converted so many more emails than their Inbox was showing. While perhaps alarming, it’s not cause for concern. To say it simply, Emailchemy extracts deleted messages from many email storage formats, and if you don’t want that to happen you should use the “Compact Mailbox” or “Compact Database” feature of your old email application before doing the conversion.
… Read more
Posted on Jan 23rd 2009 by matt.
Here’s a walkthrough I recently sent to a customer who had questions about how the Google Apps Uploader works. I’m posting it here for future reference.
1) Using either the “Conversion Wizard” or “Advanced Conversion” tool in Emailchemy’s toolbox, convert your mail to Standard mbox Format, giving it a name like “converted”.
2) Switch over to Emailchemy’s Google Apps Uploader tool, select the “converted” folder and enter the target email account’s address (the account that you want to receive the uploaded messages) and leave the default settings for the other options for now.
… Read more
Posted on Jan 11th 2009 by matt.
Emailchemy 9.8.4 was released on January 7 with better handling of Eudora for Mac email and the ability to recover deleted messages from Entourage Database files. This update is recommended for all users converting Eudora for Mac email.
… Read more
Posted on Jan 9th 2009 by matt.
Are you already on Twitter? Probably; we’re getting to this late, but we hope you start following “weirdkid” on Twitter.
Often times, there isn’t much to say beyond “hey, check out this link” or “new version ready for download” and microblogging, like with Twitter, is the perfect venue for when writing a full “real” blog post isn’t really needed or convenient at the moment. For example, Twitter “tweets” (as they are called) were designed to be sent from a mobile phone as a SMS text message, so they are naturally limited to be no more that 140 characters long. And, we can post them while sitting in a meeting, or walking to the next one, riding the bus, while writing code, or even waiting on line at Starbucks.
Posted on Jan 5th 2009 by matt.
In Part 1, I explained how the “Date:” header of an email is actually the “sent date” and introduced a couple of issues with how the sent date is created by different email clients. Now in Part 2, I’ll give a similar rundown of the problems with the received date, starting with a nod to the the title of this series of posts by telling you there is no such thing as a received date.
That’s right – it doesn’t exist. The format of all Internet mail, as it goes over the wire (or over the air, whatever) is specified by RFC-2822 – the standard Internet Message Format. It defines the structure of a message, including the various header fields you may be familiar with, like “From: ” or “To: ” or “Subject: ” and many more that you may never see. The point here is that RFC-2822 does not define a header field for a received date, and this is a problem because then every email client application is free to interpret and create a received date pseudo-header which may not map to any other email client’s interpretation.
For example, Mail for Mac OS X uses the date found in the top (last written) “Received:” header as a received date. It’s a novel approach because it doesn’t require the injection of proprietary non-portable headers like “X-Received-Date:”, but the date it is using is when the last mail server in the delivery chain received the message. Specifically, it is not the date that the email recipient saw or even read the message. The email could have a received date of today, even if you don’t check your email for the next week!
… Read more