2.
3 JavaMail
The JavaMail API is an abstract suite of classes for handling message-based systems. It was first introduced
as a stand-alone package but now ships as part of the core J2EE API, although it can still be downloaded
as a separate package to be used with other applications outside of the J2EE space.
Understanding the Protocols for JavaMail
The protocols that underpin the workings of electronic mail are well established and very mature.
Although it is not completely necessary, it is never a bad idea to get a feeling for what the JavaMail API is
attempting to abstract for you. This section will take a quick a look at the following core protocol
implementations that are bundled as part of the JavaMail distribution.
• Simple Mail Transport Protocol (SMTP)
• Post Office Protocol version 3 (POP3)
• Internet Message Access Protocol (IMAP)
Although Multipurpose Internet Mail Extensions (MIME) is not strictly a transport protocol because it
packages mail content, we’ll take a look at it as well.
SMTP
The Simple Mail Transport Protocol was first proposed back in 1982 and was designed for the delivery of
mail messages to servers. Its staying power can be attributed to its extreme simplicity in moving (or
relaying) messages. Note that SMTP is merely a delivery agent and is not used to read e-mail.
SMTP can act as a relay server by delivering e-mail on behalf of another server. For this reason, it has been
abused by spammers to send large volumes of unsolicited e-mails to users all over the world.
Consequently, many system administrators have blocked, or restricted, their SMTP server’s capability, and
will only accept e-mail that is specifically addressed to that server’s user base.
POP3
The Post Office Protocol is the mechanism by which the majority of people collect their e-mail. It is then
the responsibility of the user to take care of the e-mail by filing it in some logical storage. Much as with a
mailbox at a real post office, a user comes along and collects, or downloads, his or her e-mail, storing it
locally and removing it from the server. The POP server does not offer any storage facilities beyond the
mailbox that new mail is delivered to. This setup can be a little confusing to new users because modern-
day e-mail clients give the illusion that the server stores the messages.
IMAP
The Internet Message Access Protocol is a protocol that many enterprise e-mail servers employ. It offers a
far richer set of functions than POP. With POP the premise is that the user is responsible for the storage of
e-mail, whereas with IMAP the server assumes this responsibility. IMAP offers a folder structure for the
user to interact with and all messages are stored on the server. The user has no need to download e-mail
to his or her local machine.
MIME
The Multipurpose Internet Mail Extension defines the translation of and all the rules that are associated
with the transmission of binary-based e-mail. Internet mail is fundamentally based on pure American
Standard Code for Information Interchange (ASCII) text, and on the whole does not permit non-ASCII data
to be used. At first this may seem a little restrictive, but considering the wide variety of machine types that
are exchanging e-mail with one another, it was important to choose the lowest common denominator to
ensure data arrived safely. However, the need to start attaching non-ASCII files to mail messages soon
became apparent and a standard was required to deal with the encoding of binary files into ASCII in such
a way that they could be transported and, when received, decoded back out to their native binary
representations.
JavaMail Components
The JavaMail API is a collection of about one hundred classes and interfaces. That makes it sound
tremendously complicated, but don’t be intimidated by numbers. Fortunately you don’t need to
understand every single detail to be able to use the API. This is the power of an objectorientated system.
It abstracts the implementation away and presents a clear and concise interface with the functionality. In
this section we’ll take a look at the major components that make up the API. We’ll delve into some of the
more active classes to give you a feeling of just how flexible this API really is.
It contains four major components:
• Session management—The session aspect of the API defines the interaction the mail client has with the
network. It handles all aspects associated with the overall communication, including the protocol to use
for transfer and any default values that may be required.
• Message manipulation—Because the whole premise of the JavaMail is to send and receive mail
messages, it shouldn’t come as any great surprise that there are many ways of creating and manipulating
mail messages.
• Mail storage and retrieval—If a message isn’t being sent or received, it is in storage. Messages are stored
in hierarchies that are not unlike those of files and directories. The JavaMail API has a suite of classes for
managing this storage, including classes for adding, deleting, and moving messages.
• Transportation—Last but not least is the delivery of the message. The API provides easy mechanisms for
this.
Using the JavaMail API
The java application uses JavaMail API to compose, send and receive emails.The following figure illustrates
the architecture of JavaMail.
The abstract mechanism of JavaMail API is similar to other J2EE APIs, such as JDBC, JNDI, and JMS. As seen
the architecture diagram above, JavaMail API is divided into two main parts
• An application-independent part: An application-programming interface (API) is used by the application
components to send and receive mail messages, independent of the underlying provider or protocol used.
• A service-dependent part: A service provider interface (SPI) speaks the protocol-specific languages, such
as SMTP, POP, IMAP, and Network News Transfer Protocol (NNTP). It is used to plug in a provider of an e-
mail service to the J2EE platform.
Sending and Receiving Mail with JavaMail
E−mail was one of the first tools available on the Internet. To the ordinary business person, it is an
indispensable tool. For the business application, e−mail is also indispensable — be it that simple order
confirmation or a mass mailing telling customers of the latest specials. Within the J2EE environment,
JavaMail provides both e−mail and newsgroup capabilities.
Composing the message
A mail message includes a lot of information that is not strictly related to the text that you write with your
mail package. The format of a mail message a number of headers and ancillary information must be
provided with your mail message in order for it to reach its destination.
Routing the message
Once your mail arrives on the greater Internet, the SMTP server has to find a way to deliver it. It does this
by taking the destination e−mail address, stripping the domain name from it, and then attempting to locate
the appropriate server for this domain. If there is no explicit mail server for a domain, the SMTP server
may look to the parent domain(s) until it finds one. This server may act as a gateway to the internal
network for all mail of a particular domain.
Reading the mail
With the mail now sitting on the destination server, the last step is for the user to actually read it. Here
the user has a wide variety of options. The majority of users download the mail to a mail client on their
local machine using the Post Office Protocol (POP). This protocol usually copies the mail from the server
to the local machine and then deletes it from the server a very simple system, but one that works for the
majority of users.
The format of a mail message
The mail sent over an SMTP connection has a very specific format. It must follow the rules set down by a
standard known as RFC 822. RFCs are the standards that govern all of the low−level workings of the
Internet. RFC 822 specifically pertains to the contents of e−mail messages
Structure
A mail message is treated one line at a time. Each line is read and parsed looking for specific
pieces of information. The upshot of this is that the order in which items are declared in an e−mail
is not necessarily important, although everyone tends to follow the same guidelines.
Headers
Despite being hidden from ordinary users, headers contain a lot of interesting information. You can tell so
much about users just by looking at the information contained in their headers. Headers also look
completely foreign if you are not used to seeing them, and most mailers will automatically hide them from
you.
Body
The body of the message is generally free−form text. The text must consist of seven−bit ASCII characters,
which prohibits binary information or most internationalized text. To send a binary file in the earlier days
of the Internet meant using a program like UUencode to turn eight−bit binary into seven−bit ASCII. The
resulting fun of piecing together multiple mail messages in the right order and then decoding them was
part of daily life for Internet users.
The JavaMail package
JavaMail consists of four packages to provide news and e−mail functionality. Although the API is capable
of handling non−Internet mail and news services, the default implementation only includes Internet
capabilities. JavaMail, like all of the J2EE specification, belongs to the Optional Packages extensions to the
Java APIs. This means that the packages all start with the prefix javax.mail. Table 2.3 lists the four packages.
JavaMail requirements
JavaMail is a pure Java API and therefore does not depend on any given system setup. It does not even
require a Java 2 system and will happily run on JDK 1.1 (though running it inside an applet is bound to
cause security exceptions).When running, JavaMail does not require any particular setup. You provide it
with all the information it needs to connect to a mail server to send and receive messages at runtime.
JavaMail terminology
As a multipurpose, multiprotocol API, JavaMail has to abstract many things and create an appropriate set
of terminologies for each abstraction. Most of these terms should feel straightforward.
Session
The session is everything about your application using the mail interface. If you have multiple applications
running in the same JVM instance (for example, servlets in a Web server or EJBs in a middleware server),
it is possible for each to have its own environment to work in. A session defines the environment that the
mail will run. This environment can be shared across many applications, or each application can have its
own individual setup.
Transport
Transport is the protocol used for sending and or receiving e−mail. For a system that will be sending out
e−mail, the transport will be SMTP. For a receiving system, it will be either POP or IMAP. Naturally, you can
set up a single session with a number of different transports — one for the sending side and one for the
receiving side.
Message
The message is all the information that has to be sent, including the body, headers, and addressing
information. You will need to create a single message for each time you need to send something to a user.
Multiple recipients may be specified in the message, within the limits imposed by the mail server and
Internet standards.
Store
The store is a collection of messages, just as in a mail client. A store consists of a number of folders and
messages. Within each folder you can contain other folders and messages ad infinitum.
