JAVA MAIL

SERVER
 A

PROJECT REPORT

ON

JAVA MAIL SERVER

For

Somany Ceramics Limited.

In accordance with the requirement

of

GUJARAT UNIVERSITY
IN PARTIAL FULFILMENT OF
BACHELOR OF COMPUTER APPLICATIONS
(2008-2009)

SUBMITTED BY

Mohammed Umar Maniar

Nishant Gaur

T.Y.B.C.A
XAVIER INSTITUTE OF COMPUTERAPPLICATIONS (XICA)
(Affiliated to the Gujarat University)

2
Navarangpura, Ahmedabad-380009

3
INDEX

Chapter-1 Acknowledgement………………………………………………………………… 5.

Chapter-2 Project Profile……………………………………………………………………… 6.

Chapter-3 Company Introduction……………………………………………………………. 7.

Chapter-4 Functionality of Java Mail Server………………………………………………… 8.

Chapter-5 Solution Architecture……………………………………………………………… 9.

Chapter-6 Introduction to Java Mail Server…………………………………………………. 11.

6.1 Introduction.

Chapter-7 About Java…………………………………………………………………………. 13.

7.1 The java Programming Language.
7.2 The Java Platform.
7.3 Steps of Java Program.
7.4 Java Servlet.

Chapter-8 SMTP Protocol……………………………………………………………………. 18.

8.1 The SMTP Model.
8.2 The SMTP Procedure
8.2.1 Mail.
8.2.2 RCPT.
8.2.3 DATA.
8.2.4 Opening and Closing.
8.2.5 Relaying
8.3 SMTP Specifications.
8.3.1 COMMAND Semantics.
8.3.2 COMMAND Syntax.
8.3.3 Replies.
8.4 Reply Codes by Function Groups.
8.5 Numeric Order List of Reply Codes.

Chapter-9 Multipurpose Internet Mail Extension (MIME)…………………………………. 36.

9.1 The MIME-Version Header Field.
9.2 The Content -Type Header Field.
9.3 The Content -Transfer Encoding Header Field.
9.4 Base 64 Content - Transfer Encoding.
9.5 A MIME Example.

Chapter-10 Data Diagrams…………………………………………………………………….. 49.

10.1 Context Level DFD.
10.2 1st Level DFD.
10.3 Entity Relationship Diagrams (ERD).

JAVA MAIL SERVER 4

Chapter-11 Data Dictionary…………………………………………………………………… 53.
11.1 User_Account_Table.
11.2 Address_Table.
11.3 Country_Table.
11.4 State_Table.
11.5 City_Table.

Chapter-12 Running the Project……………………………………………………………... 55.

Chapter-13 GUI Interface / Forms Reports………………………………………………..page

13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
13.9

Chapter-14 Conclusion……………………………………………………………………..page

Chapter-15 References………………………………………………………………………page

JAVA MAIL SERVER 5

ACKNOWLEDEGEMENT

“Learning is a continuous process”. At this moment of my substantial

enhancement, I have hardly enough words to express my Gratitude towards
those who were constantly involved with me during my training period at
SOMANY CERAMICS LTD.

First of all, my heartfelt thanks to Mr. Pratesh .M.C, who helped

me in every possible manner. He ensured a proper environment to work in. He
allowed complete freedom and reposed complete faith in my work. He was
patient enough in making me understand the whole system and its requirements.
He also saw to it that I did not face any problems in the resource front, by
ensuring prompt delivery of all the materials that I wanted in developing the
system.

My sincere thanks to the entire personal of SOMANY group,

whose co-operative demeanors made my stay at the office a memorable one.
Without their selfless co-operation and willingness to help at all stages in spite of
their workload, it would not have been possible for me to complete the project.

Finally, I express my sincere gratitude to my project internal guide,

Mr.Jaymal Choudhary (the user guide), for being a constant source of
inspiration. He ensured proper complation of project by reviewing my progress at
appropriate stage of my project development. His guidance and inspiration
changed this project into faithful and meaningful exercise. It would be impossible
to continue without the contributions of our faculty members of my college,
especially to Mr.Archit Vohra (college internal guide) who help me with his full
enrolement in the project.

JAVA MAIL SERVER 6

PROJECT PROFILE

The project “JAVA MAIL SERVER” can be used to send and receive electronic mails
efficiently and reliably across transport service environment. JAVA MAIL SERVER is the
application that receives mail(s) from the employee’s within intranet. It also holds email
messages for employee’s, on a network.

Basically E-mail system provides a separate

application layer protocol that is SMTP for sending and receiving emails. This project
includes the implementation of this protocol in JAVA. SMTP is an independent of
particular transmission subsystem and requires only reliable ordered data stream.

In order to provide secure transmission of data

Base64 encoding is used in the server. This encoding algorithm is simple to understand
and implement, but the encoded data are consistently about 33 percent larger than the
un-encoded data.

The user of “JAVA MAIL SERVER” can also enjoy some additional features like
address book and file attachment.

Scope for Further Work:

Today’s mail service is the most used service on the net. Recent developments show
that more features are added to SMTP protocol. Features such as encryption of
messages and compression for security and efficient network transmission can be
added to enhance the functionality of the mail server.

JAVA MAIL SERVER 7

 COMPANY INTRODUCTION

A company started in 1936, which later in 1969 changed to SPL

Limited. SPL has always been the guiding force for Indian tile
industry by bringing new technology, products etc, with total
capital of about 750 cr. Initiated nearly three decades ago, it
started its journey in collaboration with world’s best company
called Pilkingston’s Ltd of UK.

They continue to build competitive advantage with a series of

carefully charted out strategy of alliances, innovative product
launches and quality service (including Internet Technology) from
there family of dealers to add value to your home.

SPL was the first tile company in India to be awarded with ISO

9002 & ISO 14001 certificates for its quality process and
environment friendly manufacturing facilities.

For more information visit www.somanyceramics.com

JAVA MAIL SERVER 8

FUNCTIONALITY

In information technology, functionality (from Latin functio meaning "to

perform") is the sum or any aspect of what a product, such as a software
application or computing device, can do for a user.

A product's functionality is used by marketers to identify product features

and enables a user to have a set of capabilities. Functionality may or may
not be easy to use.Here in Java Mail Server basically, functionality includes
the registration to login part, on successful login the user will be provided
with the facility such as INBOX, SENT ITEMS, COMPOSE MAIL,
CREATIONING FOLDERS and the access to ADDRESS.

JAVA MAIL SERVER 9

SOLUTION ARCHITECTURE

Model-view-controller (MVC) is an architectural pattern used in software

engineering. Successful use of the pattern isolates business logic fromuser
interface considerations, resulting in an application where it is easier to
modify either the visual appearance of the application or the underlying
business rules without affecting the other.

In MVC, the model represents the information (the data)

of the application; the view corresponds to elements of the user
interface such as text, checkbox items, and so forth; and
the controller manages the communication of data and the
business rules used to manipulate the data to and from the
model.

As an architectural pattern

It is common to split an application into separate layers that run on different

computers: presentation (UI), domain logic, and data access. In MVC the
presentation layer is further separated into view and controller.
MVC is often seen in web applications, where the view is the
actual HTML page, and the controller is the code that gathers dynamic data
and generates the content within the HTML. Finally, the model is
represented by the actual content, usually stored in a database or
in XML nodes, and the business rules that transform that content based on
user actions.

JAVA MAIL SERVER 10

Though MVC comes in different flavors, control flow generally works as
follows:

1. The user interacts with the user interface in some way (e.g. presses a
button).
2. A controller handles the input event from the user interface, often via
a registered handler or callback.
3. The controller notifies the model of the user action, possibly resulting
in a change in the model's state. (Eg. controller updates
user's Shopping cart).
4. A view uses the model (indirectly) to generate an appropriate user
interface (e.g. the view produces a screen listing the shopping cart
contents). The view gets its own data from the model. The model has
no direct knowledge of the view.
5. The user interface waits for further user interactions, which begins
then a new cycle.

(A simple diagram depicting the relationship between the Model, View, and Controller. Note: the
solid lines indicate a direct association, and the dashed lines indicate an indirect association)

JAVA MAIL SERVER 11

 6. INTRODUCTION TO JAVA MAIL
SERVER
E-mail is a method of sending and receiving electronic messages and files, usually over
a computer network. E-mail consists of a text message normally typed on a computer
keyboard in an e-mail software application. In addition to a text message, e-mail
software applications also let users transmit computer files by attaching the file to the e-
mail message.

Electronic mail is among the most widely available application services. E-mail can
accommodate small notes or large voluminous memos with a single mechanism. It
should not surprise that more users send file with electronic mail than with the file
transfer protocols. Like most TCP/IP services, it uses the client-server paradigm. The
mail system buffers outgoing and incoming messages, allowing the transfer from client

JAVA MAIL SERVER 12

and server to occur in the background.

TCP
Send Connection
Mail
Outgoing
Client
Mail
Spool Area
Outgoing
User
Interface
Mailboxes
Server
for
Incoming
Read
Mail
Mail
Incoming

Fig 1.1Conceptual components of an electronic mail system. The user invokes a user interface to deposit
or retrieve mail: all transfer occurs in the background

The background mail transfer process becomes a client. The process first attempts to
form a TCP connection to the mail server on the destination machine. If it succeeds, the
transfer process passes a copy of the message to the remote server. If it can not form a
TCP connection or if the connection fails, the transfer process terminates.

The Mail Server is the heart of any e-mail system.  It is the application that receives mail
from the e-mail client and from other mail servers. It also holds e-mail messages for
clients on a network.

JAVA MAIL SERVER 13

Basically E-mail system provides a separate application layer protocol that is SMTP for
sending mails. The project “JAVA Mail Server” includes the implementation of this
protocol in JAVA.

7. ABOUT JAVA

Java is simple language that can be learned easily, even if you just started
programming. A Java programmer need not know the internal of Java program syntax is
same as that of C++. Unlike C++ in which the programmer handles memory
manipulation, Java handles the required memory manipulation, and thus prevents errors
that arise due to improper usage.

JAVA MAIL SERVER 14

Java is purely object-oriented and it defined data as objects with methods that support
the object. It provides abstraction, encapsulation, and inheritance & polymorphism. Any
code that you write in Java is inside a class.

Java is tuned to web. Java programs can access data across the web as they access
from a local system. You can build distributed application in Java that uses resources
from any other network computer.

7.1 The Java Programming Language

The Java programming language is a high-level language that can be characterized by
all of the following buzzwords.
 Simple
 Object-oriented
 Distributed
 Interpreted
 Robust
 Secure

With the most programming language, you either compile or interpret a program so that
you can run it on your computer. The Java programming language is unusual in that a
program is both compiled and interpreted. With the compiler, first you translate a
program into an intermediate language called Java byte codes the platform-independent
codes interpreted by the interpreter on the Java platform. The interpreter parses and
runs each Java byte code instruction on the computer. Compilation happens just once;
interpretation occurs each time the program is executed.

JAVA MAIL SERVER 15

One can think of Java byte codes as the machine code instruction for the Java Virtual
Machine (JVM). Every Java interpreter, whether it’s a development tool or a web
browser that can run applets, is an implication of Java Virtual Machine (JVM).

Java bytecode helps make write once, run anywhere possible. You can compile your
program into byte codes on any platform that has a Java compiler. The byte codes can
then be run on any implementation of Java Virtual Machine (JVM). That means that as
long as a computer has a Java Virtual Machine (JVM), the same program written in the
Java programming language can run on Windows 2000, a Solaris workstation, or on an
iMac.

7.2 The Java Platform

A platform is the hardware or software environment in which a program runs. We have
already mentioned some of the most popular platform like Windows 2000, Linux,
Solaris, and MacOS. Most platforms can be described as a combination of the operating
system and hardware. The Java platform differs from most other platform in that it’s a
software-only platform that runs on top of other hardware-based platform.

Java Platform Has Two Components

 The Java Virtual Machine (JVM)
 The Java application Programming Interface (API)

We have already been introduced to the Java Virtual Machine (JVM). It’s the base for
the Java platform and is ported onto various hardware based platform. The Java API is
a large collection of ready-made software components that provide many useful
capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped
into libraries of related classes and interface: these libraries are known as packages.
The following figure depicts a program that’s running on the Java platform. as the figure
shows, the Java API and the virtual machine insulate the program from the hardware.

JAVA MAIL SERVER 16

7.3 Life Cycle of Java program

 Create a Java source file.

A source file contains text, written in the Java programming language, that we
programmers can understand. We can use a text editor to create and edit source
files.

 Compile the source file into a bytecode file.

The Java compiler takes our source file and translates its text into instructions
that the Java Virtual Machine (JVM) can understand. The compiler puts these
instructions into a bytecode file.

 Run the program contained in the bytecode file

The Java Virtual Machine (JVM) is implemented by a Java interpreter (java.).

This interpreter takes your bytecode file and carries out the instruction by
translating them into instruction that your computer can understand.

7.4 Java Servlet

A servlet is a server-side software component, written in Java that dynamically extends

the functionality of a server. Similar to the manner in which applets run inside a Java-
enabled Web browser on the client, servlets execute on a Java-enabled server. Unlike
applets, servlets do not display a graphical interface to the user. A servlet’s work is

JAVA MAIL SERVER 17

done behind the scenes on the server and only the results of the servlet’s processing
are returned to the client (usually in the form of HTML).

Specifically, servlets are Java classes that conform to a specific interface that can be
invoked from the server. Note that the functionality provided servlets is not restricted to
Web server. Any server that supports the servlet API may be enhanced through
servlets. Common examples include FTP, Telnet, mail, and news servers. The servlet
API is a specification developed by SUN that defines the classes and interfaces used to
create and execute servlets.

Servlets provide a framework for creating applications that implement the

request/response paradigm. For example, when a browser sends a request to the
server, the server may forward the request to a servlet. At this point the servlet can
process the request (through database access or any other means) and construct an
appropriate response (usually in HTML) that is returned to the client.

Features of Servlets

Servlets extends a server’s functionality in almost any way imaginable. Similar to CGI,
they allow for true two-way interaction between the client and server. The following are
just a few of the many possibilities provided b servlets:
 Dynamically build and return an HTML file based on the nature of the client
request.
 Process user input passed by an HTML form and return an appropriate
response.
 Facilitate communication between groups of people by publishing information
submitted by many clients (e.g. an on line bulletin board system).
 Provide user authentication and other security mechanisms.
 Interact with server resources such as databases, other applications, and
network files to return useful information to the client.

JAVA MAIL SERVER 18

  Process input from many clients for interaction among peers for applications
such as multiplayer games.
 Allow the server to communicate with a client applet via a custom protocol and
keep the connection open throughout the conversation.
 Automatically attach Web page design elements, such as headers or footers, to
all pages returned by the server.

8. SMTP PROTOCOL
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and
efficiently. SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel.

JAVA MAIL SERVER 19

An important feature of SMTP is its capability to relay mail across transport service
environments. A transport service provides an inter-process communication
environment (IPCE). An IPCE may cover one network, several networks, or a subset of
a network. Mail is an application or use of interprocess communication. Mail can be
communicated between processes in different IPCEs by relaying through a process
connected to two (or more) IPCEs. More specifically, mail can be relayed between
hosts on different transport systems by a host on both transport systems.

8.1 The SMTP Model

The SMTP design is based on the following model of communication: As the result of a
user mail request, the sender-SMTP establishes a two-way transmission channel to a
receiver-SMTP. The receiver-SMTP may be either the ultimate destination or an
intermediate. SMTP commands are generated by the sender-SMTP and sent to the
receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in
response to the commands.

Once the transmission channel is established, the SMTP-sender sends a MAIL

command indicating the sender of the mail. If the SMTP-receiver can accept mail it
responds with an OK reply. The SMTP-sender then sends a RCPT command
identifying a recipient of the mail. If the SMTP-receiver can accept mail for that recipient
it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but
not the whole mail transaction).The SMTP-sender and SMTP-receiver may negotiate
several recipients. When the recipients have been negotiated the SMTP-sender sends
the mail data, terminating with a special sequence. If the SMTP-receiver successfully
processes the mail data it responds with an OK reply. The dialog is purposely lock step,
one-at-a-time.

JAVA MAIL SERVER 20

 Fig 3.1 Model for SMTP Use

The SMTP provides mechanisms for the transmission of mail; directly from the sending
user's host to the receiving user's host when the two hosts are connected to the same
transport service, or via one or more relay SMTP-servers when the source and
destination hosts are not connected to the same transport service. To be able to provide
the relay capability the SMTP-server must be supplied with the name of the ultimate
destination host.

The argument to the MAIL command is a reverse-path, which specifies who the mail is
from. The argument to the RCPT command is a forward-path, which specifies whom
the mail is to. The forward-path is a source route, while the reverse-path is a return
route (which may be used to return a message to the sender when an error occurs
with a relayed message).

Commands and replies are composed of characters from the ASCII character set.
When the transport service provides an 8-bit byte (octet) transmission channel, each 7-
bit character is transmitted right justified in an octet with the high order bit cleared to
zero.

When specifying the general form of a command or reply, an argument (or special
symbol) will be denoted by a meta-linguistic variable (or constant), for example,

JAVA MAIL SERVER 21

"<string>" or "<reverse-path>". Here the angle brackets indicate these are meta-
linguistic variables. However, some arguments use the angle brackets literally. For
example, an actual reverse-path is enclosed in angle brackets, i.e.,

"<John.Smith@USC-ISI.ARPA>"

is an instance of <reverse-path> (the angle brackets are actually transmitted in the

command or reply).

8.2 The SMTP Procedures:

This section presents the procedures used in SMTP in several parts. First comes the
basic mail procedure defined as a mail transaction. Following this are descriptions of
forwarding mail, verifying mailbox names, sending terminals instead of or in combination
with mailboxes, and the opening and closing exchanges.

8.2.1 MAIL

There are three steps to SMTP mail transactions. The transaction is started with a
MAIL command, which gives the sender identification. A series of one or more RCPT
commands follows giving the receiver information. Then a DATA command gives the
mail data. And finally, the end of mail data indicator confirms the transaction.

The first step in the procedure is the MAIL command. The <reverse-path> contains the
source mailbox.

MAIL <SP> FROM:<reverse-path> <CRLF>

This command tells the SMTP-receiver that a new mail transaction is starting and to
reset all its state tables and buffers, including any recipients or mail data. It gives the

JAVA MAIL SERVER 22

reverse path that can be used to report errors. If accepted, the receiver-SMTP returns a
250 OK reply.

The <reverse-path> can contain more than just a mailbox. The <reverse-path> is a
reverse source routing list of hosts and source mailbox. The first host in the <reverse-
path> should be the host sending this command.

8.2.2 RCPT

The second step in the procedure is the RCPT command.

RCPT <SP> TO:<forward-path> <CRLF>

This command gives a forward-path identifying one recipient. If accepted, the receiver
SMTP returns a 250 OK reply, and stores the forward-path. If the recipient is unknown
the receiver-SMTP returns a 550 Failure reply. This second step of the procedure can
be repeated any number of times.

The <forward-path> can contain more than just a mailbox. The <forward-path> is a
source routing list of hosts and the destination mailbox. The first host in the <forward-
path> should be the host receiving this command
.
8.2.3 DATA
The third step in the procedure is the DATA command.

DATA <CRLF>

If accepted, the receiver-SMTP returns a 354 Intermediate reply and considers all
succeeding lines to be the message text. When the end of text is received and stored
the SMTP-receiver sends a 250 OK reply.

JAVA MAIL SERVER 23

Since the mail data is sent on the transmission channel the end of the mail data must be
indicated so that the command and reply dialog can be resumed. SMTP indicates the
end of the mail data by sending a line containing only a period.

The end of mail data indicator also confirms the mail transaction and tells the receiver
SMTP to now process the stored recipients and mail data. If accepted, the receiver
SMTP returns a 250 OK reply. The DATA command should fail only if the mail
transaction was incomplete (for example, no recipients), or if resources are not
available.

The above procedure is an example of a mail transaction. These commands must be

used only in the order discussed above. The example given below illustrates the use of
these commands in a mail transaction.

This SMTP example shows mail sent by Smith at host Alpha.ARPA, to Jones, Green,
and Brown at host Beta.ARPA. Here we assume that host Alpha contacts host Beta
directly.

S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK

S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK

S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here

S: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK

S: DATA

JAVA MAIL SERVER 24

 R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK
The mail has now been accepted for Jones and Brown. Green did not have a mailbox
at host Beta.

8.2.4 OPENING AND CLOSING

At the time the transmission channel is opened there is an exchange to ensure that the
hosts are communicating with the hosts they think they are. The following two
commands are used in transmission channel opening and closing:

HELO <SP> <domain> <CRLF>

QUIT <CRLF>

In the HELO command the host sending the command identifies itself.; the command
may be interpreted as saying "Hello, I am <domain>".
Example of Connection Opening
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA

Example of Connection Closing

S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel

8.2.5 RELAYING
The forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE",
where ONE, TWO, and THREE are hosts. This form is used to emphasize the

JAVA MAIL SERVER 25

distinction between an address and a route. The mailbox is an absolute address, and
the route is information about how to get there. The two concepts should not be
confused.

Conceptually the elements of the forward-path are moved to the reverse-path as the
message is relayed from one server-SMTP to another. The reverse-path is a reverse
source route, (i.e., a source route from the current location of the message to the
originator of the message). When a server-SMTP deletes its identifier from the forward-
path and inserts it into the reverse-path, it must use the name it is known by in the
environment it is sending into, not the environment the mail came from, in case the
server-SMTP is known by different names in different environments.

If when the message arrives at an SMTP the first element of the forward-path is not the
identifier of that SMTP the element is not deleted from the forward-path and is used to
determine the next SMTP to send the message to. In any case, the SMTP adds its own
identifier to the reverse-path.

Using source routing the receiver-SMTP receives mail to be relayed to another server-
SMTP. The receiver-SMTP may accept or reject the task of relaying the mail in the
same way it accepts or rejects mail for a local user. The receiver-SMTP transforms the
command arguments by moving its own identifier from the forward-path to the beginning
of the reverse-path. The receiver-SMTP then becomes a sender-SMTP, establishes a
transmission channel to the next SMTP in the forward-path, and sends it the mail. The
first host in the reverse-path should be the host sending the SMTP commands, and the
first host in the forward-path should be the host receiving the SMTP commands.

Notice that the forward-path and reverse-path appear in the SMTP commands and
replies, but not necessarily in the message. That is, there is no need for these paths
and especially this syntax to appear in the "To:", "From:", "CC:", etc. fields of the
message header.

JAVA MAIL SERVER 26

If a server-SMTP has accepted the task of relaying the mail and later finds that the
forward-path is incorrect or that the mail cannot be delivered for whatever reason, then
it must construct an "undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-path).
This notification message must be from the server-SMTP at this host. Of course,
server-SMTPs should not send notification messages about problems with notification
messages. One-way to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message is relayed it is
permissible to leave the reverse-path null. A MAIL command with a null reverse-path
appears as follows:

MAIL FROM:<>

An undeliverable mail notification message is shown in below example. This notification

is in response to a message originated by JOE at HOSTW and sent via HOSTX to
HOSTY with instructions to relay it on to HOSTZ. What we see in the example is the
transaction between HOSTY and HOSTX, which is the first step in the return of the
notification message.

Example: Undeliverable Mail Notification Message

S: MAIL FROM:<>
R: 250 ok

S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
R: 250 ok

S: DATA
R: 354 send the mail data, end with.

S: Date: 23 Oct 81 11:22:33

JAVA MAIL SERVER 27

 S: From: SMTP@HOSTY.ARPA

S: To: JOE@HOSTW.ARPA
S: Subject: Mail System Problem
S:
S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.

S: HOSTZ.ARPA said this:

S: "550 No Such User"

S: .
R: 250 ok

8.3 THE SMTP SPECIFICATIONS

8.3.1 COMMAND SEMANTICS

The SMTP commands define the mail transfer or the mail system function requested by
the user. SMTP commands are character strings terminated by <CRLF>. The
command codes themselves are alphabetic characters terminated by <SP> if
parameters follow and <CRLF> otherwise. The syntax of mailboxes must conform to
receiver site conventions.

A mail transaction involves several data objects, which are communicated as arguments
to different commands. The reverse-path is the argument of the MAIL command, the
forward-path is the argument of the RCPT command, and the mail data is the argument
of the DATA command. These arguments or data objects must be transmitted and held
pending the confirmation communicated by the end of mail data indication, which

JAVA MAIL SERVER 28

finalizes the transaction. The model for this is that distinct buffers are provided to hold
the types of data objects, that is, there is a reverse-path buffer, a forward-path buffer,
and a mail data buffer. Specific commands cause information to be appended to a
specific buffer, or cause one or more buffers to be cleared.

HELLO (HELO)
This command is used to identify the sender-SMTP to the receiver-SMTP. The
argument field contains the host name of the sender-SMTP. The receiver-SMTP
identifies itself to the sender-SMTP in the connection greeting reply, and in the
response to this command.

This command and an OK reply to it confirm that both the sender-SMTP and the
receiver-SMTP are in the initial state, that is, there is no transaction in progress and all
state tables and buffers are cleared.

MAIL (MAIL)

This command is used to initiate a mail transaction in which the mail data is delivered to
one or more mailboxes. The argument field contains a reverse-path. The reverse-path
consists of an optional list of hosts and the sender mailbox. When the list of hosts is
present, it is a "reverse" source route and indicates that the mail was relayed through
each host on the list (the first host in the list was the most recent relay).

This list is used as a source route to return non-delivery notices to the sender. As each
relay host adds itself to the beginning of the list, it must use its name as known in the
IPCE to which it is relaying the mail rather than the IPCE from which the mail came (if
they are different). This command clears the reverse-path buffer, the forward-path
buffer, and the mail data buffer; and inserts the reverse-path information from this
command into the reverse-path buffer.

JAVA MAIL SERVER 29

RECIPIENT (RCPT)

This command is used to identify an individual recipient of the mail data; multiple
recipients are specified by multiple use of this command. The forward-path consists of
an optional list of hosts and a required destination mailbox. When the list of hosts is
present, it is a source route and indicates that the mail must be relayed to the next host
on the list. If the receiver-SMTP does not implement the relay function it may user the
same reply it would for an unknown local user (550).

When mail is relayed, the relay host must remove itself from the beginning forward-path
and put itself at the beginning of the reverse-path. When mail reaches its ultimate
destination (the forward-path contains only a destination mailbox), the receiver-SMTP
inserts it into the destination mailbox in accordance with its host mail conventions.

For example mail received at relay host A with arguments

FROM:<USERX@HOSTY.ARPA>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>

will be relayed on to host B with arguments

FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
<@HOSTB.ARPA:USERC@HOSTD.ARPA>.

This command causes its forward-path argument to be appended to the forward-path

buffer.

DATA (DATA)

JAVA MAIL SERVER 30

The receiver treats the lines following the command as mail data from the sender. This
command causes the mail data from this command to be appended to the mail data
buffer. The mail data may contain any of the 128 ASCII character codes. The
mail data is terminated by a line containing only a period, that is the character sequence

"<CRLF>.<CRLF>"

This is the end of mail data indication. The end of mail data indication requires that the
receiver must now process the stored mail transaction information. This processing
consumes the information in the reverse-path buffer, the forward-path buffer, and the
mail data buffer, and on the completion of this command these buffers are cleared. If
the processing is successful the receiver must send an OK reply. If the processing fails
completely the receiver must send a failure reply.

When the receiver-SMTP accepts a message either for relaying or for final delivery it
inserts at the beginning of the mail data a timestamp line. The time stamp line indicates
the identity of the host that sent the message, and the identity of the host that received
the message (and is inserting this time stamp), and the date and time the message was
received. Relayed messages will have multiple time stamp lines.

When the receiver-SMTP makes the "final delivery" of a message it inserts at the
beginning of the mail data a return path line. The return path line preserves the
information in the <reverse-path> from the MAIL command. Here, final delivery means
the message leaves the SMTP world. Normally, this would mean it has been delivered
to the destination user, but in some cases it may be further processed and transmitted
by another mail system. It is possible for the mailbox in the return path be different from
the actual sender's mailbox, for example, if error responses are to be delivered a special
error handling mailbox rather than the message senders.

JAVA MAIL SERVER 31

The preceding two paragraphs imply that the final mail data will begin with a return path
line, followed by one or more time stamp lines. These lines will be followed by the mail
data header and body.

Special mention is needed of the response and further action required when the
processing following the end of mail data indication is partially successful. This could
arise if after accepting several recipients and the mail data, the receiver-SMTP finds
that the mail data can be successfully delivered to some of the recipients, but it cannot
be to others (for example, due to mailbox space allocation problems). In such a
situation, the response to the DATA command must be an OK reply. But, the receiver-
SMTP must compose and send an "undeliverable mail" notification message to
the originator of the message. Either a single notification which lists all of the recipients
that failed to get the message or separate notification messages must be sent for each
failed recipient. All undeliverable mail notification messages are sent using the MAIL
command

Example: Return Path and Received Time Stamps

Return-Path:<@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
Received:from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received:from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received:from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From: JOE@ABC.ARPA
Subject: Improved Mailing System Installed
To: SAM@JKL.ARPA

QUIT (QUIT)

JAVA MAIL SERVER 32

This command specifies that the receiver must send an OK reply, and then close the
transmission channel. The receiver should not close the transmission channel utility
receives and replies to a QUIT command (even if there was an error). The sender
should not close the transmission channel until it send a QUIT command and receives
the reply (even if there was an error response to a previous command If the connection
is closed prematurely the receiver should act as if a RSET command had been received
(canceling any pending transaction, but not undoing any previously completed
transaction), the sender should act as if the command or transaction in progress had
received a temporary error (4xx).

There are restrictions on the order in which these command may be used. The first
command in a session must be the HELO command. The HELO command may be
used later in a session as well. If the HELO command argument is not acceptable a 501
failure reply must be returned and the receiver-SMTP must stay in the same state.

The MAIL, commands begin a mail transaction. Once started a mail transaction
consists of one of the transaction beginning commands, one or more RCPT commands,
and a DATA command, in that order. A mail transaction may be aborted by the RSET
command. There may be zero or more transactions in a session.

If the transaction beginning command argument is not acceptable a 501 failure reply
must be returned and the receiver-SMTP must stay in the same state. If the commands
in a transaction are out of order a 503 failure reply must be returned and the receiver-
SMTP must stay in the same state. The last command in a session must be the QUIT
command. The QUIT command can not be used at any other time in a session.

8.3.2 COMMAND SYNTAX

JAVA MAIL SERVER 33

The commands consist of a command code followed by an argument field. Command
codes are four alphabetic characters. Upper and lower case alphabetic characters are
to be treated identically. Thus, any of the following may represent the mail command:

MAIL Mail mail MaIl mAIl

This also applies to any symbols representing parameter values, such as "TO" or "to"
for the forward-path. Command codes and the argument fields are separated by one or
more spaces. However, within the reverse-path and forward-path arguments case is
important. In particular, in some hosts the user "smith" is different from the user
"Smith".

The argument field consists of a variable length character string ending with the
character sequence <CRLF>. The receiver is to take no action until this sequence is
received. Square brackets denote an optional argument field. If the option is not taken,
the appropriate default is implied.

The following are the SMTP commands:

HELO <SP> <domain> <CRLF>

MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-path> <CRLF>
DATA <CRLF>
RSET <CRLF>
SEND <SP> FROM:<reverse-path> <CRLF>
SOML <SP> FROM:<reverse-path> <CRLF>
SAML <SP> FROM:<reverse-path> <CRLF>
VRFY <SP> <string> <CRLF>
EXPN <SP> <string> <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>

JAVA MAIL SERVER 34

QUIT <CRLF>
TURN <CRLF>

8.3.3 SMTP REPLIES

Replies to SMTP commands are devised to ensure the synchronization of requests and
actions in the process of mail transfer, and to guarantee that the sender-SMTP always
knows the state of the receiver-SMTP. Every command must generate exactly one
reply.

An SMTP reply consists of a three digit number (transmitted as three alphanumeric

characters) followed by some text. The number is intended for use by automata to
determine what state to enter next; the text is meant for the human user. It is intended
that the three digits contain enough encoded information that the sender-SMTP need
not examine the text and may either discard it or pass it on to the user, as appropriate.
In particular, the text may be receiver-dependent and context dependent, so there are
likely to be varying texts for each reply code. A discussion of the theory of reply codes
is given in Appendix E. Formally, a reply is defined to be the sequence: a three-digit
code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in Appendix
E). Only the EXPN and HELP commands are expected to result in multiline replies in
normal circumstances, however multiline replies are allowed for any command

REPLY CODES BY FUNCTION GROUPS

500 Syntax error, command unrecognized

[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands

JAVA MAIL SERVER 35

504 Command parameter not implemented
211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a particular non-standard
command; this reply is useful only to the human user]
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel
[This may be a reply to any command if the service knows it must shut down]
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
451 Requested action aborted: error in processing
551 User not local; please try <forward-path>
452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed

NUMERIC ORDER LIST OF REPLY CODES

JAVA MAIL SERVER 36

211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a particular non-standard
command; this reply is useful only to the human user]
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel
[This may be a reply to any command if the service knows it must shut down]
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
551 User not local; please try <forward-path>
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
554 Transaction failed

JAVA MAIL SERVER 37

 9. MULTIPURPOSE INTERNET MAIL
EXTENSIONS

Multipurpose Internet mail Extensions, MIME, is an extension to the electronic mail

format. Most notably, MIME provides three important Internet services. These services
include the following:

 Describes a standard method for defining a multipart mail message containing

heterogeneous body parts.
 Provides a standard mechanism for encoding binary data into the ASCII format.
 Defines a standard for specifying the type of content stored in the body of a
message.

Hence we can say that MIME defines how to divide a message into several parts, how
to delimit each part and how to describe and characterize each part. Concerned with
our e-mail system MIME helps us to divide the mail into a message into a mail part and
a attachment part.

One of the notable limitations of RFC 821/822 based mail systems is the fact that they
limit the contents of electronic mail messages to relatively short lines of seven-bit ASCII.
This forces user to convert any non-textual data that they may wish to send into seven-
bit bytes representable as printable ASCII characters.

JAVA MAIL SERVER 38

This document describes several mechanisms that combine to solve most of these
problems without introducing any serious incompatibilities with the existing world of RFC
822 mail. In particular, it describes:

1. A MIME-Version header field, which uses a version number to declare a

message to be conformant with this specification and allows mail processing
agents to distinguish between such messages and those generated by older or
non-conformant software, which is presumed to lack such a field.
2. A Content-Type header field, generalized from RFC 1049 [RFC-1049], which
can be used to specify the type and subtype of data in the body of a message
and to fully specify the native representation (encoding) of such data.
a) A "text" Content-Type value, which can be used to represent textual
information in a number of character sets and formatted text description
languages in a standardized manner.
b) A "multipart" Content-Type value, which can be used to combine several
body parts, possibly of differing types of data, into a single message.
c) An "application" Content-Type value, which can be used to
transmit application data or binary data, and hence, among other uses, to
implement an electronic mail file transfer service.
d) A "message" Content-Type value, for encapsulating another mail
message.
e) An "image" Content-Type value, for transmitting still image
(picture) data.
f) An "audio" Content-Type value, for transmitting audio or voice data.
g) A "video" Content-Type value, for transmitting video or moving image
data, possibly with audio as part of the composite video data format.

3. Content-Transfer-Encoding header field, which can be used to specify an

auxiliary encoding that was applied to the data in order to allow it to pass through
mail transport mechanisms which may have data or character set limitations.

JAVA MAIL SERVER 39

 4. Two additional header fields that can be used to further describe the data in a
message body, the Content-ID and Content-Description header fields.

MIME has been carefully designed as an extensible mechanism, and it is expected that
the set of content-type/subtype pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably including character set
names, are likely to have new values defined over time. In order to ensure that the set
of such values is developed in an orderly, well-specified, and public manner, MIME
defines a registration process which uses the Internet Assigned Numbers Authority
(IANA) as a central registry for such values.

9.1 The MIME-Version Header Field

Since RFC 822 was published in 1982, there has really been only one format standard
for Internet messages, and there has been little perceived need to declare the format
standard in use. This document is an independent document that complements RFC
822. Although the extensions in this document have been defined in such a way as to
be compatible with RFC 822, there are still circumstances in which it might be
desirable for a mail-processing agent to know whether a message was composed with
the new standard in mind.

Therefore, this document defines a new header field, "MIME-Version", which is to be

used to declare the version of the Internet message body format standard in use.
Messages composed in accordance with this document MUST include such a header
field, with the following verbatim text:

MIME-Version: 1.0

JAVA MAIL SERVER 40

The presence of this header field is an assertion that the message has been composed
in compliance with this document. Since it is possible that a future document might
extend the message format standard again, a formal BNF is given for the content of the
MIME-Version field:

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Thus, future format specifiers, which might replace or extend "1.0", are constrained to
be two integer fields, separated by a period. If a message is received with a MIME-
version value other than "1.0", it cannot be assumed to conform with this specification.
Note that the MIME-Version header field is required at the top level of a message. It is
not required for each body part of a multipart entity. It is required for the embedded
headers of a body of type "message" if and only if the embedded message is itself
claimed to be MIME-conformant.

It is not possible to fully specify how a mail reader that conforms with MIME as defined
in this document should treat a message that might arrive in the future with some value
of MIME-Version other than "1.0". However, conformant software is encouraged to
check the version number and at least warn the user if an unrecognized MIME-version
is encountered.

It is also worth noting that version control for specific content-types is not accomplished
using the MIME-Version mechanism. In particular, some formats (such as
application/postscript) have version numbering conventions that are internal to the
document format. Where such conventions exist, MIME does nothing to supersede
them. Where no such conventions exist, a MIME type might use a "version" parameter
in the content-type field if necessary.

All header fields defined in this section, including MIME-Version, Content-type, etc., are
subject to the general syntactic rules for header fields specified in RFC 822. In

JAVA MAIL SERVER 41

particular, all can include comments, which means that the following two MIME-Version
fields are equivalent:

MIME-Version: 1.0
MIME-Version: 1.0 (Generated by GBD-killer 3.7)

9.2 The Content-Type Header Field

The purpose of the Content-Type field is to describe the data contained in the body fully
enough that the receiving user agent can pick an appropriate agent or mechanism to
present the data to the user, or otherwise deal with the data in an appropriate manner.

The Content-Type header field is used to specify the nature of the data in the body of an
entity, by giving type and subtype identifiers, and by providing auxiliary information that
may be required for certain types. After the type and subtype names, the remainder of
the header field is simply a set of parameters, specified in an attribute/value notation.
The set of meaningful parameters differs for the different types. In particular, there are
no globally-meaningful parameters that apply to all content-types. The ordering of
parameters is not significant. Among the defined parameters is a "charset" parameter
by which the character set used in the body may be declared. Comments are allowed in
accordance with RFC 822 rules for structured header fields.

In general, the top-level Content-Type is used to declare the general type of data, while
the subtype specifies a specific format for that type of data. Thus, a Content-Type of
"image/xyz" is enough to tell a user agent that the data is an image, even if the user
agent has no knowledge of the specific image format "xyz". Such information can be
used, for example, to decide whether or not to show a user the raw data from an
unrecognized subtype -- such an action might be reasonable for unrecognized subtypes

JAVA MAIL SERVER 42

of text, but not for unrecognized subtypes of image or audio. For this reason, registered
subtypes of audio, image, text, and video, should not contain embedded information
that is really of a different type. Such compound types should be represented using the
"multipart" or "application" types.

Parameters are modifiers of the content-subtype, and do not fundamentally affect the
requirements of the host system. Although most parameters make sense only with
certain content-types, others are "global" in the sense that they might apply to any
subtype. For example, the "boundary" parameter makes sense only for the "multipart"
content-type, but the "charset" parameter might make sense with several content-types.

An initial set of seven Content-Types is defined by this document. This set of top-level
names is intended to be substantially complete. It is expected that additions to the
larger set of supported types can generally be accomplished by the creation of new
subtypes of these initial types. In the future, more top-level types may be defined only
by an extension to this standard. If another primary type is to be used for any reason, it
must be given a name starting with "X-" to indicate its non-standard status and to avoid
a potential conflict with a future official name.

The seven standard initial predefined Content-Types are detailed in the bulk of this
document. They are:

text -- textual information. The primary subtype, "plain", indicates plain (unformatted)
text. No special software is required to get the full meaning of the text, aside from
support for the indicated character set. Subtypes are to be used for enriched text in
forms where application software may enhance the appearance of the text, but such
software must not be required in order to get the general idea of the content. Possible
subtypes thus include any readable word processor format.

multipart -- data consisting of multiple parts of independent data types. Four initial
subtypes are defined, including the primary "mixed" subtype, "alternative" for

JAVA MAIL SERVER 43

representing the same data in multiple formats, "parallel" for parts intended to be
viewed simultaneously, and "digest" for multipart entities in which each part is of type
"message".

message -- an encapsulated message. A body of Content-Type "message" is itself all

or part of a fully formatted RFC 822 conformant message which may contain its own
different Content-Type header field. The "partial" subtype is defined for partial
messages, to permit the fragmented transmission of bodies that are thought to be too
large to be passed through mail transport facilities. Another subtype, "External-body", is
defined for specifying large bodies by reference to an external data source.

image -- image data. Image requires a display device (such as a graphical display, a
printer, or a FAX machine) to view the information. Initial subtypes are defined for two
widely-used image formats, jpeg and gif.
audio -- audio data, with initial subtype "basic". Audio requires an audio output device
(such as a speaker or a telephone) to "display" the contents.

video -- video data. Video requires the capability to display moving images, typically
including specialized hardware and software. The initial subtype is "mpeg".

application -- some other kind of data, typically either uninterpreted binary data or
information to be processed by a mail-based application. The primary subtype, "octet-
stream", is to be used in the case of uninterpreted binary data, in which case the
simplest recommended action is to offer to write the information into a file for the user.

Default messages are typed by this protocol as plain text in the US-ASCII character set,
which can be explicitly specified as "Content-type: text/plain; charset=us ASCII". If no
Content-Type is specified, this default is assumed. In the presence of a MIME - Version
header field, a receiving User Agent can also assume that plain US-ASCII text was the
sender's intent. In the absence of a MIME-Version specification, plain US-ASCII text
must still be assumed, but the sender's intent might have been otherwise.

JAVA MAIL SERVER 44

9.3 The Content-Transfer-Encoding
Header Field

Many Content-Types which could usefully be transported via email are represented, in
their "natural" format, as 8-bit character or binary data. Such data cannot be
transmitted over some transport protocols. For example, RFC 821 restricts mail
messages to 7-bit US-ASCII data.

It is necessary, therefore, to define a standard mechanism for re-encoding such data

into a 7-bit short-line format. This document specifies that such encodings will be
indicated by a new "Content-Transfer-Encoding" header field. The Content-Transfer-
Encoding field is used to indicate the type of transformation that has been used in
order to represent the body in an acceptable manner for transport.

Unlike Content-Types, a proliferation of Content-Transfer-Encoding values is

undesirable and unnecessary. However, establishing only a single Content-Transfer-
Encoding mechanism does not seem possible. There is a tradeoff between the desire
for a compact and efficient encoding of largely-binary data and the desire for a readable
encoding of data that is mostly, but not entirely, 7-bit data. For this reason, at least two
encoding mechanisms are necessary: a "readable" encoding and a "dense" encoding.

The Content-Transfer-Encoding field is designed to specify an invertible mapping

between the "native" representation of a type of data and a representation that can be
readily exchanged using 7 bit mail transport protocols, such as those defined by RFC
821 (SMTP). This field has not been defined by any previous standard.

JAVA MAIL SERVER 45

 encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" ; case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ x-token

If a Content-Transfer-Encoding header field appears as part of a message header, it

applies to the entire body of that message. If a Content-Transfer-Encoding header field
appears as part of a body part's headers, it applies only to the body of that body part. If
an entity is of type "multipart" or "message", the Content-Transfer-Encoding is not
permitted to have any value other than a bit width (e.g., "7bit", "8bit", etc.) or "binary".

It should be noted that email is character-oriented, so that the mechanisms described

here are mechanisms for encoding arbitrary octet streams, not bit streams. If a bit
stream is to be encoded via one of these mechanisms, it must first be converted to an
8-bit byte stream using the network standard bit order ("big-endian"), in which the
earlier bits in a stream become the higher-order bits in a byte.
A bit stream not ending at an 8-bit boundary must be padded with zeroes. This
document provides a mechanism for noting the addition of such padding in the case of
the application Content-Type, which has a "padding" parameter.

The encoding mechanisms defined here explicitly encode all data in ASCII. Thus, for
example, suppose an entity has header fields such as:

Content-Type: text/plain; charset=US-ASCII

Content-transfer-encoding: base64

JAVA MAIL SERVER 46

9.4 Base64 Content-Transfer-Encoding

The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of

octets in a form that need not be humanly readable. The encoding and decoding
algorithms are simple, but the encoded data are consistently only about 33 percent
larger than the unencoded data. A 65-character subset of US-ASCII is used, enabling 6
bits to be represented per printable character. (The extra 65th character, "=", is used to
signify a special processing function.)

The encoding process represents 24-bit groups of input bits as output strings of 4
encoded characters. Proceeding from left to right, a 24-bit input group is formed by
concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-
bit groups, each of which is translated into a single digit in the base64 alphabet. When
encoding a bit stream via the base64 encoding, the bit stream must be presumed to be
ordered with the most-significant-bit first.

That is, the first bit in the stream will be the high-order bit in the first byte, and the eighth
bit will be the low-order bit in the first byte, and so on. Each 6-bit group is used as an
index into an array of 64 printable characters. The character referenced by the index is
placed in the output string. These characters, identified in Table 1, below, are selected
so as to be universally representable, and the set excludes characters with particular
significance to SMTP (e.g., ".", CR, LF) and to the encapsulation boundaries defined in
this document (e.g., "-").

Table: The Base64 Alphabet

Value Encoding Value Encoding Value Encoding Value Encoding

JAVA MAIL SERVER 47

0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Table 9.1

Special processing is performed if fewer than 24 bits are available at the end of the data
being encoded. A full encoding quantum is always completed at the end of a body.
When fewer than 24 input bits are available in an input group, zero bits are added (on
the right) to form an integral number of 6-bit groups. Padding at the end of the data is
performed using the '=' character.
The first step is to convert three bytes to four numbers of six bits. Each character in the
ASCII standard consists of seven bits. Base64 only uses 6 bits (corresponding to 2^6 =
64 characters) to ensure encoded data is printable and humanly readable. None of the
special characters available in ASCII are used. The 64 characters (hence the name
Base64) are 10 digits, 26 lowercase characters, 26 uppercase characters as well as '+'
and '/'.

JAVA MAIL SERVER 48

If, for example, the three bytes are 155, 162 and 233, the corresponding (and
frightening) bit stream is 100110111010001011101001, which in turn corresponds to
the 6-bit values 38, 58, 11 and 41.

These numbers are converted to ASCII characters in the second step using the Base64
encoding table. The 6-bit values of our example translate to the ASCII sequence
"m6Lp".
 155 -> 10011011
 162 -> 10100010
 233 -> 11101001
 100110 -> 38
 111010 -> 58
 001011 -> 11
 101001 -> 41
 38 -> m
 58 -> 6
 11 -> L
 41 -> p

This two-step process is applied to the whole sequence of bytes that are encoded

9.5 A MIME Example

Date: Mon, 2 Feb 2004 22:16:19 -0800 (PST)

From: nolan@stat.Berkeley.EDU
To: txxxx@uclink.berkeley.edu
Subject: did you receive my letter?
In-Reply-To: <web-569552@calmail-st.berkeley.edu>
MIME-Version: 1.0

JAVA MAIL SERVER 49

Content-Type: MULTIPART/Mixed; BOUNDARY:”—669732--deptcsit”

--669732--deptcsit
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Yes it was received.

--669732—deptcsit

Content-Type: APPLICATION/PDF; CHARSET=US-ASCII;

FILENAME: PLOTS.PDF
Content-Transfer-Encoding: BASE64
JVBERi0xLjEKJYHigeOBz4HTDQoxIDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUgKEQ6Mj
AwNDAyMDIxMTIwMTEpCi9Nb2REYXRlIChEOjIwMDQwMjAyMTEyMDExKQovVGl0b
GUgKFIgR3JhcGhpY3MgT3V0cHV0KQovUHJvZHVjZXIgKFIgMS44LjEpCi9DcmVhdG
9yIChSKQo+PgplbmRvYmoKMiAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwovUGFnZX
MgMyAwIFIKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1Rle
HRdCi9Gb250IDw8IC9GMSA2IDAgUiAvRjIgNyAwIFIgL0YzIDggMCBSIC9GNCA5IDAg
UiAvRjUgMTAgMCBSIC9GNiAxMSAwIFIgPj4KPj4KZW5kb2JqCjUgMCBvYmoKPDwKL
1R5cGUgL0VuY29kaW5nCi9CYXNlRW5jb2RpbmcgL1dpbkFuc2lF

--669732—deptcsit

JAVA MAIL SERVER 50

 10. DATA FLOW DIAGRAMS

Data flow diagrams can be used to provide a clear representation of any

business function. The technique starts with an overall picture of the
business and continues by analyzing each of the functional areas of
interest. This analysis can be carried out to precisely the level of detail
required. The technique exploits a method called top-down expansion to
conduct the analysis in a targeted way.

10.1 Context Level DFD

The context diagram represents the entire system under investigation.

This diagram should be drawn first, and used to clarify and agree the
scope of the investigation.

The components of a context diagram are clearly shown on this screen.

The system under investigation is represented as a single process,
connected to external entities by data flows and resource flows. 

The context diagram clearly shows the interfaces between the system
under investigation and the external entities with which it communicates.
Therefore, whilst it is often conceptually trivial, a context diagram serves to
focus attention on the system boundary and can help in clarifying the
precise scope of the analysis.

JAVA MAIL SERVER 51

 ADMIN

User Registration
Details Confirmation

Registration/Login Registration Confirmation

Mail transaction(inbox,outbox) Mail Details
USER Address book(View,Add,Delete) Address book details USER
Send mail(Compose,Attach) Mail send confirmation
Mail Search(Inbox,Outbox,Folder)) JAVA Mail search result
Folder(creation,Deletion) MAIL SERVER Folder modification
Logout

Figure 10.1

10.2 1st Level DFD

The level 1 diagram shows the main functional areas of the system under investigation.
As with the context diagram, any system under investigation should be represented by
only one level 1 diagram.

There is no formula that can be applied in deciding what is, and what is not, a level 1
process. Level 1 processes should describe only the main functional areas of the
system, and you should avoid the temptation of including lower level processes on this
diagram. As a general rule no business process diagram should contain more than 12

JAVA MAIL SERVER 52

process boxes.

Figure 10.2

JAVA MAIL SERVER 53

10.3 Entity Reletion Diagram

ERD is a modeling technique that represents a logical design of a

particular business process. Each entity has attributes and
different entities are connected through primary key/foreign key
relationships. 

There are three basic elements in ER models:-

1). Entities are the "things" about which we seek information.  
Country Table State Table
2). Attributes are the data we collect about the entities.  
PK Country_id Belongs To PK State_id
3). Relationships
Country_Name provide the structure needed to draw State_Name
information from multiple entities. User _Account FK Country_id
  PK User_Id
Password
Secret Question
Answer
First Name
Last Name
Belongs To
Gender
Date_Of_Birth
Address
Phone_no
FK Country_id
FK State_id
FK City_id

Address book Contains

PK User_Id Belongs To
FK
PK Contact_Id
Contact_Name
Phone_No
Address

JAVA MAIL SERVER 54

 Figure 10.3

11. Data Dictionary

ABOUT DATABASE

A database jms.sql using MySQL has been created to store the user information in a
table named user_account_table. Another table address_table has been created to
keep a record of a user related address book, a table country_table to store the names
of countries, a state_table to store the names of states of respective countries and
finally a city_table store the names of cities of belonging state to show on registration
form.

11.1 User Account Table

Column Data Size Constra Description City Table
Name Type int PK City_id
User_id varchar2 5 Primary Stores User id for login, address, City_Name
Key etc FK State_id
Password varchar2 15 - Used for login
Secret varchar2 50 - Used when user forgets
Question password
Answer varchar2 30 - Stores answer for password
retrieval
First Name varchar2 30 - Stores first name of user
Last Name varchar2 30 - Stores last name of user
Gender varchar2 1 M/F Stores gender of user
Date Of Birth Date - Stores date of birth of user
Address varchar2 60 - Stores user address

JAVA MAIL SERVER 55

Phone Number number 20 - Stores user phone number
Country_id number 2 - Used in storing country id of user
State_id number 2 - Used in storing state id of user
City_id number 2 - Used in storing city id of user

11.2 Address Table

Column Name Data Type Size Constraint Description
User_id varchar2 15 Foreign & shows stored contact for a user
Primary key
contact_id varchar2 15 primary key stores id of others users
Contact_name varchar2 30 - stores name of user having above id
Phone number number 20 - stores phone no of user having above id
Address varchar2 60 - stores address of user having above id

11.3 Country Table

Column Name Data Type Size Constraint Description
Country_id number 2 Primary key Stores Country ID of user
Country_name varchar2 15 - Stores Country name of user

11.4 State Table

Column Name Data Type Size Constraint Description
State_id number 2 Primary key Stores state ID of user
State_name varchar2 15 - Stores state name of user
Country_id number 2 Foreign key Stores Country ID of user

JAVA MAIL SERVER 56

11.5 City Table
Column Name Data Type Size Constraint Description
City_id number 2 Primary key Stores city ID of user
City_name varchar2 15 - Stores city name of user
State_id number 2 Foreign key Stores state ID of user

JAVA MAIL SERVER 57

 12. RUNNING THE PROJECT

STEP 1
Initially we need to start the server (Apache Tomcat Server)
STEP 2
We need to deploy the web application on the Apache Tomcat Server.
STEP 3
Run the main server program before running the application.
STEP 4
Open web browser and type http://localhost:8080/javamailServer/ in the address bar
and we are ready to run the project.

JAVA MAIL SERVER 58

13. GUI INTERFACE

JAVA MAIL SERVER 59

 14. CONCLUSION
Discussion of Result:
The result of project is satisfactory, it gives correct output. Programs fulfill our
objectives, which was our goal. We have also implemented and shown Mail Server
features and output with our program. Some limitations were found on the type and size
of the attached files along with the message. Apart from this all other results were
satisfactory.

JAVA MAIL SERVER 60

15. REFERENCES
 Java2: The Complete Reference
Herbert Schildt

 Java Servlet Programming

Jason Hunter, William Crawford

 RFC 0821, Simple Mail Transfer Protocol

http://www.ietf.org/rfc/rfc0821.txt

 RFC 2045, Multipurpose Internet Mail Extensions

http://www.ietf.org/rfc/rfc2045.txt

JAVA MAIL SERVER 61

JAVA MAIL SERVER 62