The Mail API itself is a set of abstract Java classes that describe an electronic mail system in a platform-independent manner. “Service Providers” are extensions of these classes that describe a particular email system, such as the Internet mail system.

JavaSoft provides a free (binary) reference implementation of the Mail API, which includes a provider for Internet-style email, including the SMTP and IMAP protocols. No implementation of POP has yet been announced, and it is not clear whether this will be implemented by Sun or a third party. Access to the source code of the reference implementation is available for a fee.

Other possible providers that could be provided by a third party might handle proprietary electronic mail environments such as Lotus Notes, MAPI, ccMail, and so on. The Mail API allows developers to implement these protocols in a manner that complies with the emerging Java standard.

Objects that use an implementation of the Mail API can request standard services from the JavaBeans Activation Framework (JAF), part of the new Glasgow specification of JavaBeans. Using these services, Mail API implementations can request the content type of a data stream and determine the actions that may be performed on it. In this way, JavaBeans can dynamically change their behavior based on the existence of other Beans within their environment. Those creating an email user agent, for example, can use the JAF to assist in the handling of MIME types embedded in mail messages. JAF is based on Unix’s mailcap technology, defined in Internet RFC 1524, that maps data types to handlers.

Naturally, the Java Mail API can be used in Java applications such as locally installed clients and servers. However, those clients operating as applets within Web browsers encounter some restrictions. The HotJava browser from Sun and Microsoft Internet Explorer handle embedded applets’ requests to mail services without problem. Netscape’s browser, on the other hand, uses a more restrictive security model that limits necessary network access. These restrictions may be bypassed by using the Java Activator or by signing the applets and requesting access to sensitive services.

Of course, U.S. export restrictions mean that secure email will be difficult to handle in a standard way. To date, the U.S. government has dealt as severely with those wishing to export standard hooks for encryption technologies as those who wish to export the products themselves. Support for secure email based on the S/MIME and PGP/MIME methods is not likely to be forthcoming.

The Java Mail API is not part of the standard Java distribution (either in the Java Development Kit or the Java Runtime Environment). It is a “standard extension” to the language. Not part of the Java core and not expected to exist on any given platform, standard extensions are nonetheless defined in a standard way for all Java developers. Many standard extensions now released or planned operate with Java 1.1, which provides a standard way of adding to functionality without waiting for a version release. Standard extensions require that the class files be distributed with an application, to ensure that it is locally available.

JavaSoft typically releases an API as a standard extension, followed rapidly by a reference implementation that is royalty free. In some cases, the reference implementation may be very incomplete and viewed by Sun as a third-party opportunity.

The Java Mail API is one such standard extension. It, in turn, uses JAF to allow Java Mail applications to handle arbitrary content data types. JAF is another standard extension.

In all, the Java Mail reference implementation gives developers a standard way of accessing some parts of the Internet mail system now. The API provides an assurance that new email implementations can interoperate with compliant code. Sun’s concept of standard extensions gives us the ability to cooperate without further bloating the Java core.