Something has got to be done to make mobile email easier. The technology is confusing and cumbersome to use and hard to support. Different types of mobile users need different types of products, depending on whether they are never in an office, they travel between two fixed points, or they travel all over. Plus, products that have been long promised by both Microsoft and Lotus are ridiculously late in coming. Let's look at the problem. If you support many mobile email users, you have three principle technology choices. First off, you could purchase the vendor's own remote email client. With cc:Mail, this is a separate package from the LAN-connected client, and that introduces all sorts of synchronization problems for those users that alternately use the two different versions. Specifically, your address books and your messages will not match between the remote client and the LAN-based client. To keep things in synch, your users will have to copy this information to their laptops prior to hiting the road: which I feel is unacceptable. Lotus has promised a better remote client for several years but not delivered on them as of yet. Microsoft Mail has a better solution with their remote Windows client, provided you store all your messages on your local hard disk. If you use the same laptop on your desk, then going mobile isn't that tough, since all your email and addresses are right there in your laptop. However, this scenario has a few drawbacks. First off, you'll probably want a fairly powerful laptop if you are going to use it all the time. Powerful means heavy, and that's quite literally a drag. Second, all your data is with you at all times, so if you lose your laptop your life is in ruins. Another issue is that Microsoft has so far just delivered only the Windows client for Mail. They have been promising better remote clients for Macs and its other non-Windows platforms, but haven't delivered on them either. Some of you have adopted a second approach, to use some sort of remote access product to get connected to the office network, and then just use the standard LAN email client running over that link. The advantage here is that your directories and message fles stay in the office, so the synchronization issues disappear. Plus, you have access to other LAN applications and resources besides mail. The downside is all this software can be cumbersome to explain to some computing neophytes, who have trouble understanding exactly where the "computer" is when they are using remote access products. And many IS managers don't like remote control products because of perceived security issues. There is a third approach: use Unix. Now before you dismiss this idea as totally crazy, think about it for a minute: with Unix, you have your choice of at least a half-dozen email front ends, some of them quite graphical and powerful. You've got an operating system that was built for remote terminals to connect to it, so that the tools to manage these connections and users are part and parcel and not some bolt-on package that may or may not work with something else. An email back-end comes at no extra charge and is also integrated into the operating system, something that can't be said for cc:Mail and Microsoft Mail. You never have to worry about your data not being around, because all of your data is on the server and gets taken care of. You can run the same email software local or remote, and its performance remotely is more than acceptable. You don't need much computing power on the remote end: indeed, a portable terminal is all that is really required. And, if you get some serial line internet protocol products, you can run more sophisticated Windows or Mac clients talking to your Unix box too. Some organizations have begun to take this latter path: they figure the hassle of supporting Unix more than makes up for the higher integration and more developed set of tools that are part of the operating system. But for the rest of us stuck in remote email hell, we have to wait until Microsoft and Lotus get their act together.