I’m seeing a few subtle and not so subtle changes in GMail tonight.

1) Quicker message loading

2) New graphics (the yellow type found in Google Reader) at the top of the screen for loading messages

3) New contacts manager which is very slick and a great upgrade

4) The ability to add an event invitation when composing or replying to messages.

Comments

Wait, wasn’t that already possible for some time using POP (Post Office Protocol)? Yes, but IMAP is superior, as Google explains in their help entry:

Unlike POP, IMAP offers two-way communication between your web Gmail and your email client(s). This means when you log in to Gmail using a web browser, actions you perform on email clients and mobile devices (ex: putting mail in a ’work’ folder) will instantly and automatically appear in Gmail (ex: it will already have a ’work’ label on that email).

In addition, IMAP provides a better method to access your mail from multiple devices. If you check your email at work, on your mobile phone, and again at home, IMAP ensures that new mail is accessible from any device at any given time.

Google also state that IMAP offers a more stable overall experience, less prone to losing messages or downloading them several times.

Here’s how you can check if IMAP is already available for your Gmail account; click Settings, and check if the fifth tab is named “Forwarding and POP” or if it’s already named “Forwarding and POP/IMAP”. If the latter is the case – DownloadSquad has a screenshot showing this – you are lucky and can start configuring your IMAP client if you wish to. (If you don’t see IMAP in Gmail yet you might also want to try logging out of Gmail and logging back in, though that didn’t help here and may just have worked coincidentally for some of you.)

[Thanks Or, Jon Henshaw and Chris Gilmer.]

Comments

Germano Caronni, the Google software engineer who helped develop IMAP for Gmail, talked about its capabilities on the official Google blog:

Plenty of devices you use every day can take advantage of IMAP, a technology that lets you keep all your email in sync automatically as you read and sort it. Your smart phone most likely supports it, as does your PDA, laptop, desktop computer, etc. To learn more about IMAP, please have a look at the Gmail Blog, which describes it in more detail, or the Gmail Help Center, which explains exactly how to set it up. And if you have an iPhone, check out our “What’s New” page to learn how to start using IMAP in a matter of minutes.

It’s interesting that Caronni mentions mobile devices, especially since many people expect Google to unveil such a device, a Gphone, that arrives with plenty of Google applications on-board. We contend this product, if it does arrive, won’t be as important as the network that supports it.

IMAP is an always-on technology. For Gmail account holders who like receiving their Gmail messages fast on a PC-based email client, IMAP means messages arrive virtually immediately after hitting Gmail. No waiting for the POP3 check to take place.

That’s the benefit of IMAP, and why it makes a Google Network sound more likely. Typical wireless carriers might balk at thousands of Gphone clients throwing IMAP traffic on their networks, judging by this disadvantage listed on the IMAP page at Wikipedia:

IMAP4 clients need to explicitly request new email message content potentially causing additional delays on slow connections such as those commonly used by mobile devices.

A fast network wouldn’t have this issue. We know Google and Sprint are working together to make Google the default portal on Sprint’s WiMAX service, Xohm. But Xohm is in jeopardy due to its $5 billion price tag, and Sprint’s continued outflow of subscribers.

IMAP promises good synchronization with all of a Gmail user’s devices; read a message on one device, and all the other gadgets know about it. We’re interested in seeing just how far Google may take its promise. All the way to GoogleNet, and ad-supported wireless Internet/VoIP/IMAP, perhaps?

on various platforms (Mac, Windows, Linux, FreeBSD) and spanning over four years, I’ve come to the inevitable conclusion that all IMAP clients suck.

Yes, all of them–especially when used for off-line or disconnection operation.

My needs were simple, but I’d yet to find a tool that would Just Work. So I’ve replaced my lofty goals of using IMAP so that I could keep mail organized on my server but accessible anywhere.

My new system works like this. Email addressed to Jeremy@Zawodny.com comes to my mail server. Exim hands it off to procmail, which runs it thru SpamAssassin. Then it sends a copy to GMail and delivers one locally. It also archives a copy on the server in monthly mbox files. (Yes, it’s a secondary backup.)

I use Thunderbird on the Windows notebook that Yahoo provides me. Periodically, I make sure to archive mail in my GMail account, flag the obvious spam, etc.

The downside is that when I switch from using Thunderbird to Gmail and back (happens once in a while for short periods of time), I may see some messages twice.

The upside is that the broken IMAP sync never happens. I just download all my mail and go offline when I need to. I can then manipulate it to my heart’s content on the client and worry not about things going wrong.

If my notebook blows up, I’m still okay. It is backed up regularly and I’ve got a copy of everything in my Gmail account as well.

Why didn’t I do this a few years ago? Probably because the promise of IMAP is so damned appealing. It makes me a little sad that nobody’s ever been able to get it working well and efficiently.

In Summary

Reader Comments…

Jeremy Zawodny is the author of the popular Jeremy Zawodny’s blog. Jeremy is part of the Yahoo search team and frequently posts in the Yahoo! Search blog as well.

Visit Jeremy’s blog: Jeremy Zawodny’s blog.

If everyone uses POP, there’s usually not much to transfer, and if you can shut off incoming mail and just wait long enough for everyone to pop their mail, there won’t be anything. But many people now use IMAP.

It’s actually sometime useful NOT to transfer anything. Many users let their mailboxes build up without ever deleting unneeded messages. If you can leave the old server on the network, they can always access their old mail if they need to, but they (and you) may find after a year or so that nobody ever has. You might then archive the messages “Just in case” and take down the old server.

If you do want to transfer messages, it can be as simple as running command line tools. The first thing to do is to set the old server to forward all mail to the new server. Exactly what you do to accomplish that depends on your server, but it should be easy. For sendmail, you’d set SMART_HOST and MAIL_HUB, or edit the aliases file and forward each user. For SME server, set the “Delegate Mail Server” in the Server Manager.

Transferring existing mail depends on the format it now uses. For example, Qmail stores messages in individual files. On an SME server (which uses Qmail) you could transfer “tony”‘s current mail with just this:

cd /home/e-smith/files/users/tony/Maildir
for i in *
do
cat $i | /var/qmail/bin/qmail-inject
done

Repeating that for each directory would move all mail to the new server. However, it all ends up in the user’s INBOX unless that server can apply rules to determine where to file it. To assist that, you may want to use a perl program instead. Something like this:

#!/usr/bin/perl
use Mail::Mailer;

@stuff=<>;
foreach (@stuff) {
$from=$_ if /^From:/;
$to=$_ if /^To:/;
$subject=$_ if /^Subject:/;
last if $subject;
}
$from=~ s/From: //;
$from=~ s/ $from=~ s/>//;
$to=~ s/To: //;
$to=~ s/ $to=~ s/>//;
$subject=~ s/^/*** FILE ME IN CUSTS ***/;
$mailer=Mail::Mailer->new();
$mailer->open({From =>$from,
&nbsp&nbsp&nbsp&nbsp To => $to,
&nbsp&nbsp&nbsp&nbsp Subject => $subject,
&nbsp&nbsp&nbsp&nbsp }) or die "Can't open $!\n";
foreach (@stuff) {
&nbsp&nbsp print $mailer $_;
}
$mailer=>close();

You’d adjust the modification to Subject appropriately, or add entirely new headers if desired.

If your mail is stored in Unix mailbox fashion, you need something to read the messages and break them up. While you could read the mailboxes directly, it’s more portable to use tools like POP:

#!/usr/bin/perl
use Net::POP3;
$pop=Net::POP3->new('10.1.36.237') or die "$!";
$pop->login("tony","password");
$messages=$pop->list;
foreach $msg(keys %$messages) {
$message=$pop->get($msg);
foreach (@$message) {
#same basic idea as above,
}
}

You may need to get Net::POP3 from CPAN. There are similar modules for IMAP.

Bruce Garlock suggested that Mailsync might also be useful here.

*Previously published at APLawrence.com

A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com