Companies must be open to the Internet to receive data from the rest of the world (via SMTP) but access to reading the data on e-mail servers (POP, IMAP, and WebMail access) is always protected through a VPN (see the figure). However, VPN technology isn't as available on mobile devices as it is on desktops. If you want to give read access to your wireless employees on multiple phones, some mobile e-mail providers require that their e-mail servers be exposed directly to the Internet. I believe that this is an architectural error and a security nightmare.

Most traditional e-mail servers are set up so that the SMTP (receiving) engine is behind the firewall with a designated port opened up. Your SMTP receiving server is accessible from the Internet for write-only access. To protect you from in-bound data, you must use solid server products, able to fend off security attacks. When employees need to read their e-mail from outside your network, you must increase your protection, with a VPN as a first line of defense. Once the employee is in your network and the connection is secure, they can access their mail via POP, IMAP, and a Web interface.

Security attacks are best handled by open-source and high-volume proprietary software packages because they've been put through their paces with millions of installs and tens of millions of attacks. They're battle-hardened, with a long history that you want to leverage.

To allow secure read access from the outside world, you need a VPN. The problem is, most wireless devices currently available aren't VPN-capable. For mobile users to read e-mail, you'll have to open other ports directly to the Internet. However, giving direct access to your e-mail server is asking for trouble. Don't expose your server directly to the Internet, even if vendors say they have secure and well tested servers. There are other ways.

The better approach is to leave your existing email server where it is, and use middleware to extend it to your mobile devices. For the majority of your company's e-mail traffic, nothing will change at all, and lack of disruption is a good thing for end-users and administrators. For mobile e-mail traffic, the middleware is set up in your company's DMZ, acting as a bridge to the mobile devices' data services for handling e-mail. The middleware is behind your firewall in the DMZ, so it has a line of defense, and if it's the right middleware, it's open source, thereby providing another line of defense. As an added benefit, the mobile middleware may be able to handle not just mobile e-mail standards (such as SyncML) but also POP and IMAP from mobile devices (and P-IMAP, once it shows up on phones) without having to change your existing email server at all.

The mobile middleware should use SSL, triple-DES, and AES to further protect the data streams, but that will require some software to be installed on the mobile devices. It must be based on open standards, and keep up with the rapid evolution of the mobile market. It should be open source, because it's the safest option and puts strategic control in your hands (rather than a vendor's).

In the long run, mobile e-mail will follow the lead of standard e-mail and Internet protocols—to full standardization and commoditization, with open source implementations being the dominant backbone of network services and providing full security. Because it's only a matter of time, you might as well just get there now, rather than making architectural compromises.

About the author
Fabrizio Capobianco is the CEO of Funambol. He can be reached at info@funambol.com.