PUNE INSTITUTE OF COMPUTER TECHNOLOGY

UNIVERSITY OF PUNE

SEMINAR REPORT ON

INTERNET MESSAGE ACCESS PROTOCOL ( IMAP )

NAME

KUNAL . R . CHIGARE

CLASS

BE - I

ROLL NO

109

YEAR

2002-2003

CERTIFICATE
This is to certify that
Mr. Kunal . R . Chigare
Has completed the necessary seminar work and prepared the bonafied report
on
INERNET MESSAGE ACCESS PROTOCOL ( IMAP )
in a satisfactory manner as partial fulfillment for requirement of the degree
of
B.E (Computer)
Of
University of Pune In the academic year 2002-2003
Date:
Place

Prof. Rajesh Ingle

Internal Guide

Prof. G P Potdar
Seminar coordinator

Prof. Dr. C V K Rao

H.O.D

DEPARTMENT OF COMPUTER ENGINEERING

PUNE INSTITUTE OF COMPUTER TECHNOLOGY
PUNE - 43

CONTENTS
Preface.iv
Acknowledgement...v
1. IMAP : BRIEF OVERVIEW AND HISTORY....1

IMAP.
IMAP Features.
IMSP Features.
IMAP History & Status.

2.WHAT IS IMAP....4
IMAP definition
Key goals and operations
3. MESSAGE ACCES PARADIGMS.6
Modes of operation
Message access protocols
Protocol requirements
4. SYNCHRONIZATION OPERATIONS FOR..14
DISCONNECTED IMAP CLIENTS
Design principles
Overall picture of synchronization
Normal synchronization
5. POP AND IMAP...23
Similarities between POP & IMAP
IMAP Advantages
IMAP Disadvantages
6. IMAP : THE FUTURE OF THE INTERNET MAIL..30
Advantages of IMAP revolution
Conclusion
REFERENCES37

Acknowledgement
I express my sincere thanks and heartfelt gratitude to my internal
guide
Prof. R.B. Ingle for his efforts and help in my Seminar.
Special thanks to Prof. Girish Potdar for there tremendous help through
out the seminar.
I wish to record my thanks to Prof. C.V.K. Rao (H.O.D, Computer
Science Dept.) for his support and co-operation extending to me during
this work.
Also I am very thankful to my friends for their timely help and
useful suggestions.

PREFACE
Internet mail has escaped the academic world to become
dominant basis for electronic mail world-wide . While the World-Wide Web
and http/html continue to get attention for their many and sundry uses .
electronic mail quietly remains the predominant mission-critical use of the
internet , and its growth path matches or exceeds that of the web.
Among the many growth trends associated with internet
email , two have developed as particularly troublesome to managers and
administrators of existing mail systems ,the rapid upward scaling of users
,data ,administrative units,
And the mobility of users as they move between home , office and travel in
various states of connectivity.
IMAP ( The Internet Message Access Protocol ) has emerged
as the corner step technology of so-called enterprise internet mail , largely
because the model and depth of the IMAP protocol provide solutions to the
user and administrator problems associated with scaling and mobility. From
its origins at Stanford University and the University of Washington and
Carnegie Mellon University , IMAP is now embraced by companies ranging
from dozens of small start-ups to Netscape , Microsoft , Apple , HP , and Sun .
IMAP is the future of internet mail technologies.

1. IMAP : BRIEF OVERVIEW AND HISTORY

1. IMAP
A client / server protocol for manipulating remote message stores . part
of the open architecture :

EMSTP mail transport

NNTP news transport

RFC822 ; 1036 Header definitions

MIME content encoding & labeling

IMAP remote mail box access

2. IMAP Features

Support for online , offline , and disconnected operation.

Selective access to MIME body parts.

Access to multiple mailboxes , potentially on multiple

servers.

Support for folder hierarchies ( i.e. nested mailboxes )

Standard and user-defined message flags.

Shared / concurrent access to folders by multiple users.

Server-based searching and selection.

Support for advanced authentication techniques .

Provision for protocol extensibility , e.g. Annotation

3. IMSP Features .

Companion protocol to IMAP , being developed at CMU

Ability to map a username / mailbox pair to the correct mail

server .

Location-independent access to support files , such as

personal address.

4.IMAP Command Summary :

Housekeeping operations : AUTHENTICATE , CAPABILITY ,
NOOP , LOGIN , LOGOUT
Mailbox operations : SELECT , EXAMINE , CHECK CLOSE ,
EXPUNGE , SEARCH , CREATE , DELETE ,
RENAME , LIST , LSUB , SUBSCRIBE,
UNSUBSCRIBE.
Message operations : FECTH , PARTIAL , STORE , COPY ,
APPEND

5. IMAP History & Status .

1986 : IMAP conceived at Stanford University .
Interlisp client and DEC-20 server implemented.
1987 : IMAP2 defined ; client & server updated.
First Unix server implemented.
1988 : First IMAP RFC published in July ( 1064 )
Initial work on C-Client library.
1989 : Crispin hired by U .Washington .
1990 : Revised IMAP2 RFC published in August ( 11176 )
1991 : MIME support added , forming basis of IMAP2bis IMAP3
offshoot published in Feb. ( same abandoned )
1992 : IMAP2bis server developed by UW.
Pine 2.0 released with IMAP support.
CMU begins Andrew II / Cyrus project.
1993 : IMAP2bis I-D published in August.
First VMS server implemented.
IETF IMAP Working Group formed.
1994 : IMAP4 RFC s published ( 1730-1733 ).
IMAP4 approved as Protocol Internet Standard.
1995 : First IMAP4 server released by CMU.
IMAP4 C-Client and server implemented by UW.
IMAP Consortium planned.

2. WHAT IS IMAP
IMAP stands for Internet Message Access Protocol . It is a method of
accessing electronic mail for bulletin board messages that are kept in a
( possibly shared ) mail server. In other words it permits a client email
program to access remote message stores as if they were local. For example
email stored on IMAP server can be manipulated from a desktop computer at
home , a workstation at the office , and a notebook computer while traveling
without the need to transfer messages or files back and forth between these
computers.

IMAP s ability to access messages ( both new and saved ) from more than
one computer has become extremely important as reliance on electronic
messages and use of multiple computer increase , but this functionally cannot
be taken for granted : the widely used Post Office Protocol ( POP ) works
best when one has only a single computer , since it was designed to support
offline message access , wherein messages are downloaded and then
detected from the mail server . This mode of access is not compatible with
access from multiple computers since it tends to sprinkle messages across all
of the computers used for mail access . Thus unless all of those machines
share a common file system , the offline mode of access that POP was
designed to support effectively ties the user to one computer for the message
storage and manipulation.

Key goals for IMAP include :

Be fully compatible with Internet messaging standards ,

e.g. MIME

Allow message access and management from more than one

computer.

Allow access without reliance on less efficient file access

protocols.

Provide support for online , offline and disconnected

access modes.

Support for concurrent access to shared mailboxes.

Client software needs no knowledge about the servers file

store format.

The protocol includes operations for creating , deleting , and remaining

mailboxes , checking for new messages ; permanently removing messages ;
setting and clearing flags ; selective fetching of message attributes , texts and
formats and portions there for efficiency.

IMAP is centered on the notion the server is your primary mail repository.
Messages are always retained in the server. The client may issue commands
to download them , access and set message state information , but the server
always maintains the mailboxes . The protocol also provides for the entire

structure of a message to be transferred, which can provide client , mail

program with an outline of a locally to determine that structure, which is
how POP works . This is specially important on low-bandwidth
connections .

The same applies to message envelope information which is normally

presented in the message header in a fraction of the time it would take to
transfer the entire mailbox across the wire , and parse it locally . Once a
message is selected for viewing , the entire message may then be brought in.
Alternatively , a client might wish to browse only a few lines f a message ,
or a specific part of a multi-part MIME message .This is also possible , and
is extremely advantageous on slow connections.

3. MESSAGE ACCESS PARADIGMS

In the early days of email , messages were delivered to a single
time-sharing machine within organization and everyone would login to that
machine to read their email .While this model is till widely used , it has
serious limitations : first , it does not scale very well to accommodate growing
user populations , and second it does not allow use of native Mac or PC
messaging applications . The first point is primarily of concern to system
managers , but the second issue directly affects the usability of the system ,
both in terms of providing a graphical user-interface look/feel common with
other personal productivity tools , and also in order to make it easy to
import/export data between the mail system

and the desktop or laptop

machine.
Accordingly a distributed messaging architecture that
accommodates personal computer usage paradigms is of interest . However
before specific client-server protocols to support such an architecture , it is
important to understand the different ways messaging clients and servers
might be used .
The Internet document RFC-1733 defines three modes of
operation , or message access paradigms , in a disturbed messaging system :

Offline

Online

Disconnected

In offline operation messages are delivered to a ( typically

shared ) server and a workstation or personal computer user periodically
connects to then server and downloads all of the pending messages to the
client machine. More precisely the mail client program or mail user agent
( MUA ) fetches messages from the server to the machine where the mail
program is running and then deletes them from the server . There after all
messages processing is local to the client machine.
In on line operation messages are left on the mail server and
manipulated remotely by mail client programs possibly more than one at
different times.
In disconnected operation , a mail client connects to the mail
server , makes a cache copy of selected messages and then disconnects
from the server , later to reconnect and resynchronize with the server . The
user may then operate on the message cache offline , but this model
differs from the pure offline model in that primary messages remains on
the server , and the mail client program will subsequently re-connect to the
server and re-synchronize message status between the server and the clients
message cache . Online and disconnected operation complement each other
and one may alternate between them ; however neither is compatible with
offline operation since , by definition , offline implies deleting the messages
from the server after they have been copied to the client machines local disk.

You can think of office operation as providing a store-andforward service , where the last hop transmission is initiated by the user via a
mail program in the final destination host. It is intended to move mail ( on
demand ) from an intermediate server ( drop point ) to a single destination
machine , usually a PC or Mac . Once successfully delivered to the users
machine , the messages are declared from the mail server.
The offline model shines when a person always accesses their
mail from a single computer and is content to have the primary copy of their
messages live on that single machine . If however one needs to access their
message store from different times , or if they wish to keep the message store
* on a different machine than one they directly interact with , then the offline
model is inappropriate.
A growing fraction of e-mail users have one machine at work and a
different one at home , and a different one at home , and possibly also a
laptop for travel . We fell that such users would , if given a choice , prefer
online and disconnected access , and would choose offline access only when
connect time and /or server resources are at a premium . And while online
access

does imply longer connect times than offline , disconnected use

requires roughly the same connect times as offline access .A preference fro
offline access can not be inferred from its present market share , because
much of the user community has never been offered the choice .

NOTE :

The terms message store , mail box and folder

are used interchangeably in this paper , although a message store

might contain than one mail box or mail folder .

MESSAGE ACCESS PROTOCOLS :

Most people do not have messages delivered directly computer ,

and instead rely upon an , always up mail server , which is usually shared
by others in organization .Whenever mail is delivered to one machine but read
on a different one , there is a need fro a network protocol to access the
messages

on the server is a need for a network protocol to access the

messages on the server machine >once a policy decision is made on where

someones message data is going to permanently reside , i.e. on a protocol ,
workgroup , departmental , or a central server , then the question becomes ,
which protocol should be used to access the message data when using a
different machine ? The question applies both to incoming message folders
( e.g. ones primary INBOX ) and also ones saved-message folders .When
reading data sets must be available simultaneously >it is not a requirement
that the same protocol be used to access both classes of messages ,but
in most cases it makes sense to do so.
Protocol choices include :

Generic remote file system access protocols ( e.g. NFS )

Application-specific message access protocols ( e.g. POP , IMAP )

Although it is tempting to think that a remote file system protocol is the best
solution to the problem of accessing remote message stores , there are some
problems with that strategy :

There is no single file system protocol universally available on all

types of computers.

File system protocols are tightly bound to the operating system and
installation can sometimes be invasive.

File locking and security issues have proven to be problematic in some

file access protocols .

Reliance on file system protocols can lead to inefficient use of network

bandwidth , as when , for example , entire files must be transferred
over the net in order to determine the presence or absence of a
particular string.

In contrast , an application-specific protocol can :

Be tailored to maximize performance within a specific application

domain.

Allow for a logical spilt of processing between client and server in

order to minimize data transmitted across the network.

Often be installed without special privileges.

Insulate the client program from the file format used on the server.

Hence , use of an application-specific protocol is preferred . Within that

category ,
the choices are :

A proprietary / vendor-specific solution.

One of three Internet message access protocols.

The proprietary approaches

reasons having

are herein summarily

rejected for all usual

to do with getting locked into a single-vendor solution

.Moreover , these approaches inevitably lead to having email gateways to the

Internet , a perennial source of grief .That leaves us with the Internet-oriented
messaging protocols , of which there are three : POP , DMSP , and IMAP

The Post Office Protocol ( POP ) was designed to support offline mail
processing .In the offline paradigm , mail is delivered to a ( usually shared )
server and a personal computer user periodically invokes a mail client
program that connects to the server and downloads all of the pending mail to
the users own machine . Thereafter , all mail processing is local to the client
machine .Think of the offline access mode as a kind of store-and-forward
service , intended to move mail( on demand ) from the mail server ( drop point
) to a single destination machine , usually a PC or Mac. Once delivered to the
Pcs or Macs , the messages are then deleted from the mail server .Although
the limitations of offline access have triggered interest in using POP in online
( or disconnected ) operation .Indeed , POP s pseudo online mode of
operation , wherein client protocol in order for the mail client to access or

update saved-messages folders or message state information such as status

flags.

The Distributed Mail System Protocol ( DMSP ) was first

defined in RFC-984 of May 1986 . The latest revision is in RFC-1056 of June
1988 .Unlike POP , DMSP has not been widely supported , and is largely
limited to a single application , PCMAIL

.DMAP was designed specifically

to accommodate , and is best known for , the disconnected operation support

in PCMAIL.
The Internet Message Access Protocol ( IMAP ) dates to 1986 at
Stanford University , T\though it was not documented until RFC-1064 of July
1988 . It too has seen several revisions since then , with IMAP4 ( described
in RFC-1730) being the current version. IMAP was originally designed to
support the online access model ,indeed IMAP once stood for Interactive
Mail Access Protocol
but the name was changed in 1993 as part of the IETF standardization effort
in order to better reflect IMAP s current capabilities . Since IMAP is a
functional though not syntactic-superset of POP capabilities , it can fully
support offline access as well as POP does , and with additions made in
version 4 it can also support disconnected operation .
subsumed the functionality of both POP and DMSP.

IAMP has therefore

PROTOCOL

REQUIRMENTS

FOR

ONLINE

AND

DISCONNECTED

OPERRATION.

A proper online message access protocol must be able to

manipulate remote message stores as if they were local . For the reasons cited
earlier , a complete solution

requires that this be accomplished without

reliance on general file system protocols . So if one were to design a protocol (

or protocol family ) to support a high-quality client-server messaging system ,
what capabilities would it need ? It would need to offer :

Offline , online and disconnected operation .

Nomadic ( data less ) clients , without replying on remote

file protocols.

Sending , retrieving and saving messages.

Remote folder management.

Retrieving and updating per-message status information .

Retrieving

and

updating

personal

information .

Shared mail box ( multiple user ) support.

configuration

Online performance optimization.

Full compatibility with relevant Internet standards to avoid

having mail gateways

In the Internet , sending messages is accomplished via the

Simple Mail Transfer Protocol ( SMTP ) is indeed simple , there is no
particular advantage to duplicating this functionality in the message access
protocol , and neither POP nor IMAP do so . Likewise accessing and updating
personal configuration support protocol is called IMSP ( Internet Message
Support Protocol ) and was developed at Carnegie Mellon University. Hence
the focus of subsequent

sections will be on remote folder access and

manipulation capabilities , as well as performance considerations while clients

and servers are connected.
Disconnected operation has all of the same requirements as
online operation , plus it demands that messages in a particular folder be
uniquely throughout the life of that folder . This is so that clients and servers
can periodically resynchronize the status of particular messages.

4. SYNCHRONIZATION OPERATIONS FOR DISCONNECTED IMAP

CLIENTS.
1 . DESIGN PRINCIPLES
All mailbox state or content

information stored on the

disconnected client should be viewed strictly as a cache of the server . the

master state remains on the server , just as it would with an interface
IMAP4 client . The one exception to this rule is that information about that
state of the disconnected clients cache , remains on the disconnected
client : that is , unlike the equivalent case in the DMSP protocol , the
IMAP4 server

is not responsible for remembering the state of the

disconnected IMAP4 client .

We assume that a disconnected client is a that , for whatever
reason , wants to minimize the length of time that it is on a phone to
the IMAP4 server Often this will be because the client is using a dialup
connection , possibly with very low bandwidth , but sometimes it might
just be that the human is in a hurry to catch an airplane , or some other
event beyond our control . Whatever the reason , we assume that we must

make efficient use of the network connection , both in the usual sense
( not generating spurious traffic ) and in the sense that we would prefer
not to have the connection sitting idle while the client and/or the server is
performing strictly local computation or I/O . Another , perhaps simpler
way of stating this is that we assume that network connections are
expensive.

Practical experience with existing disconnected mail systems

(PCMAIL / DMSP) has shown that there is no single synchronization
strategy that is appropriate for all cases. Different preferences , and the
same

humans preference will vary depending both on external

circumstance ( how much of hurry is human is in today ) and on the value

that the human places on the messages being transferred . The point here
is that there is no way that the synchronization program can guess exactly
what the human wants to do , so the human will have to provide some
guidance .
Taken together , the preceding two principles lead to the
conclusion that the synchronization program must make its decisions
based on some kind of configuration file provided by the human , but
almost certainly should not pause for I/O with the human during the
middle of the synchronization process . The human will almost certainly
have several different configurations for the synchronization program , for
different circumstances.
Automated support for helping nave humans write better
configuration files would be a good possibility.
Since a disconnected client has no way of knowing what
changes might have occurred to the mailbox while it was disconnected ,
message numbers are not useful to a disconnected client . All disconnected

client operations should be performed using UID s , so that the client can
be sure that it and server are talking about the same messages during the
synchronization process. It is permissible , but probably not useful , for a
disconnected client to use message numbers once it has obtained a valid
current mapping between UID s and message numbers.

2. OVERALL PICTURE OF SYNCHRONIZATION :

The basic strategy for normal synchronization is pretty and
closely follows the strategy used by a disconnected

DMSP

client

( terminology explained below) :

a) Process any actions that were pending on the client ;
b) Fetch the current list of interesting mailboxes ;
c) For each mailbox , fetch the bodies of any interesting messages that
the client doesnt already have.
Explanation :
a) Actions are queued requests that were made by the human to the
clients MUA software while the client was disconnected . Expected
requests are commands like

COPY , STORE , EXPUNGE ,

CREATE , FETCH commands may also show up as actions , if the

MUA allows the human to explicitly fetch the body of a particular
message that was skipped by the normal synchronization process . In

general any IMAP4 commands at all , such as requests to send a

newly composed message via SMTP.
The list of actions should be ordered . e.g. if then human
deletes

message A1 in mailbox , then expunges mailbox A ,

then deletes message A2 in mail box A , the human will expect that
message A1 is gone and that message A2 is still present but its now
deleted.

By processing all of the actions before proceeding with

synchronization , we avoid having to compensate for the local MUA
s changes to the servers state .That is , once we have processed al
the pending actions ,the steps that the client must take to synchronize
itself will be the same no matter where the changes to the servers state
originated.
b) The set of interesting mailboxes pretty much has to be determined
by the human . What mailboxes belong to this set may vary between
different IMAP4 sessions with same server , client and human .
c) Descriptors is a DMSP term borrowed here because its both
easier to use and more precise than a specific list of IMAP4 FETCH
data items . Conceptually a messages descriptor

is that set of

information that allows the synchronization program to decide what

protocol actions are necessary to bring the local to the desired state for
this message ; since this decision is really up to the human , this
information probably includes at least a few header fields intended for
human consumption. Exactly what will constitute a descriptor contains

the messages UID and FLAGS .Other likely candidates are the RFC822.SIZE and BODYSTRUCTURE data items and the RFC-822
Note that this step is also where the client finds out about
changes to the flags of messages that the client already has in its local
cache , as well as finding out about messages in the local cache that
no longer exist on the server ( i.e. messages that have been expunged ).

d) Interesting messages are those messages that the synchronization

program thinks the human wants to have cached locally , based on the
configuration file and the data retrieved in step ( c ).
The rest of this discussion will focus primarily on the synchronization
issues for a single mailbox.
3 . CHECKING UID VALIDITY :
The UID validity of a mailbox is a number returned in
an UIDVALIDITY response code in an OK untagged response at mailbox
selection time . The UID validity changes between sessions when UID s fail
to persist between sessions .
Whenever the client to select a mailbox , the client must
compare the returned UID validity value with the value stored in the local
cache .If the UID validity values differ , the UID s in the clients cache are

no more valid . The client should then empty the local cache of that mailbox
and remove any pending
actions which refer to the UID s in that mailbox . The client may also
issue a warning to the human.

4 . DETAILS OF NORMAL SYCHRONIZATION OF A SINGLE MAILBOX. :

The most common form of synchronization is where the
human trusts the integrity of the client s copy of the state of a particular
mailbox and simply wants to bring client s cache up to date so that it
accurately reflects the mailboxs current state on the server .
Let < last seen > represent the highest UID that the client
knows about in this mailbox .Since UID s are allocated in strictly ascending
order , this is simply the UID of the last message in the mailbox that the client
knows about .
Let < descriptors > represent a list consisting of all the FETCH data item that
the implementation considers to be part of the descriptor ; at a minimum this
is just the FLAGS data item.
With no further information , the client can issue the
following two commands :

tag1 UID FETCH < last seen + 1> : * < descriptors >

tag2 UID FETCH1 : < last seen > FLAGS

The order here is significant . We want the server to start

returning the list of new message descriptors as fast as it can , so that the
client can start issuing more FETCH commands , so we start out by asking
for the descriptors of all the messages we know the client cannot possibly
have cached yet. The second command fetches the information we need to
determine what issues these two commands , theres nothing more the client

can do with this mailbox until the responses to the first command start
arriving . A clever synchronization program might use this time to fetch its
local cache state from the disk , or start the process of synchronizing another
mailbox.
Once the descriptors start arriving, the client can start issuing
appropriate FETCH commands for interesting messages or body parts
thereof. The decision on what is an interesting message is up to the client
software and the human. One easy criterion that should probably be
implemented in any client is whether the message is too big for automatic
retrieval, where too big is a parameter defined in the clients configuration
file .It is important to note that fetching a message into the disconnected
clients local cache does NOT imply that the human has (or even will)
read the message . Thus the synchronization program for a disconnected client
should always be careful to use the PEEK variants of the FETCH data items
that implicitly set the / seen flag.
Once the last descriptor has arrived and the last FETCH
command has been issued , the client simply needs to process the incoming
fetch items using them to update the local message cache .

In order to avoid deadlock problems , the client processing of

received messages priority over issuing new FETCH commands during the
synchronization process. This may necessitate temporary local queuing of
FETCH requests that cannot be issued without causing a dead lock .In order to
achieve the best use of the expensive network connection , the client
almost certainly need to careful attention to any flow-control information that
it can contain from the underlying transport connection( usually TCP-IP
connection ).

5. SPECIAL CASE : DESCRIPTOR ONLY SYNCHRONIZATION :

For some mailboxes , fetching the descriptors might be the
entire synchronization step . Practical experience with DMSP has shown that
a certain class of mailboxes (e.g. archival mailboxes ) are used primarily
for long-term storage of important messages that the human wants to have
instantly available on demand but does not want cluttering up the
disconnected clients cache at any other time. Messages in this kind of
mailbox would be fetched exclusively by explicit action queued by the local
MUA . Thus the only synchronization that is necessary for a mailbox of this
kind of descriptor information that the human will use to identify messages
that should be explicitly fetched .
Special mailboxes that receive traffic from a high volume ,
low priority mailing list might also be in this category , at least when the
human is in a hurry.

6. SPECIAL CASE : FAST NEW ONLY SYNCHRONIZATION :

In some cases the human might be in such hurry that s/he
doesnt care about changes to old messages , just about new messages . In this
case the client can skip the UID FETCH command that obtains the flags and
UID s for old messages ( 1:< last seen >).

7. SPECIAL CASE : BLIND FETCH :

In some cases the human may know ( for whatever reason )
that s/he always wants to fetch any new messages in a particular mailbox ,
unconditionally . In this case

the client can just fetch the

messages

themselves , rather than just descriptors , by using a command like :

tag1 UID FETCH < last seen +1 > : * ( FLAGS RFC822 .PEEK )
8. SPECIAL CASE : OPTIMIZING MOVE OPERATIONS :
Practical experience with IMAP , DMSP and other mailbox
access protocols that support multiple mailboxes suggest that a moving a
message from on mailbox to another is an extremely common operation. In
IMAP4 a move operation is really a combination of a COPY operation
and a STORE + FLAGS (Deleted ) operation .This makes good protocol
sense for IMAP , but it leaves a simple-minded disconnected client in the

silly position of deleting and possibly expunging its cached copy of a message
, then fetching an identical copy via the network.
Fortunately , there is a relatively easy way around this
problem by including the Message-ID: header and the INTERNALDATE
data item as part of the descriptor of a new message against messages that
are already in its cache and avoid fetching the extra copy. Of course its

possible that the cost of checking to see if the message is already in the local
cache may exceed the cost of just fetching it , so this technique should not be
used blindly. If the MUA implements a move command , it make special
provisions to use this technique when it knows that a copy / delete sequence
is the result of a move command .
Since its theoretically possible for this algorithm to find the
wrong message ( given sufficiently malignant Message ID headers ) ,
implementers should provide a way to disable this
permanently and on a message-by-message basis.

optimization , both

5. POP AND IMAP

Although the protocols are not directly compatible and differ in significant
ways , there are some common characteristics . Both of them :

Handle mail access only ; relying on SMTP by sending .

Rely on mail delivery to a , usually shared , client up mail server.

Allow access to new mail from a variety of client platform types.

Allow access to new mail from anywhere on the network .

Fully support the offline ( download and delete) access model.

Support persistent message identifiers for disconnected use.

Have freely available implementations ( including source ) available .

Have client implementations available for PCs Macs and Unix .

Have commercial implementations available .

Are open protocols , defined by Internet RFC s

Are native Internet protocols ; no mail gateways required.

IMAP ADVANTAGES.
The functional areas where POP is weak, with respect to online /
disconnected operation, are strengths for IMAP, since online access was its
original design center. Specific advantages of IMAP over POP (for
online/disconnected use) include:
Remote Folder Manipulation:

Ability to append messages to a remote folder.

Ability to set standard and user - defined message status

flags.

Support for simultaneous update and update discovery in

shared flags.

New mail notification.

Multiple folder support:

Ability to manipulate remote folders other than INBOX.

Remote folder management (list / create/delete/rename).

Support for folder hierarchies.

Suitable for accessing non-email data ; e.g. Netnews ,

documents.

Online performance optimization:

Provision for determination message structure without

downloading entire message.

Selective fetching of individual MIME body parts.

Server-based searching and selection to minimize data

transfer.

In addition, IMAP has provision for negotiated extensions, and therefore

its capabilities can grow incrementally.

Implication of remote folder manipulation abilities...

The ability to append messages to a remote folder means that
you can save messages to an archive folder or even from an archive folder
to one's inbox. Saving messages is central to message management.
The ability to "set standard and user-defined ma=message status
flags " means that the mail client program can record status information
about particular messages: for example, the fact that it has been answered,
or marked important by the user, or marked deleted. IMAP allows for
user-defined status flags, as well as small set of standard flags.
Support for simultaneous update and update discovery in shared
folders is important in situations where several people are handling
incoming messages to the same mailbox. For example, a help desk may
have several people processing requests coming into a single mailbox.
This requirement has implications for both the message access protocol

and the mailbox format. In particular, the mailbox format must permit
concurrent status flag updates from different sessions, and the message
access protocol must provide for notification
of each user session when a status flag changes. IMAP differs from many
client server protocols in that the responses from a server may not be a
direct result of requests from one's own clients; the server must be able to
send "unsolicited data to any client to inform it of mailbox state changes.

Note that in practice, shared folder support also requires that the protocol
permit access to multiple folders.
Another example of mailbox state change is new mail
notification . In IMAP, when a client program performs any operation on
a mailbox, the server will automatically include in its response notification
of any new messages that have arrived since the last notification.
Implications of multiple folder support...
A key objective of online and disconnected operation is to support
message access from different computer from different times. This
includes knowledge workers with one computer in the office and a
different one at home, as well as "nomadic students who must rely on lab
machines which do not have any local per - user storage.
Thus, the ability to "manipulate remote folders other than INBOX
is fundamental to online and disconnected operation. This means being
able to save messages from one folder to a different one , being able to

access archived messages subsequently , and allowing for multiple

incoming message folders .
Accessing multiple incoming message folders is useful for people who
have partitioned their incoming mail streams, either via delivery filters, or
by having different accounts for different purposes. The same protocol
issues that argue for the online and disconnected access model for one's
INBOX also apply to other message folders, be they "incoming or
"archive ".

Remote folder management (list/create/delete/rename)"follows

from the need to access and manipulate more than one folder. In IMAP
version 4, there is also "support for folder hierarchies, which allows
nesting collections of folders. This has protocol implications because the
mail client program must be able to distinguish directory names from
folder names.
One additional benefit of IMAP is that it is " suitable for accessing
non-email data; e.g., Netnews, documents ".This capability is attractive in
cases where it is desirable to unify different categories of information.
Note that, depending on the IMAP client implementation and the
mail architecture designed by a system manager, the user may save
messages locally on the client machine, or save them on the server, or be
given the choice of doing either.

Implications of online performance optimization...

Whenever the mail client is connected to the main lever, in either
online mode or during cache resynchronization in disconnected mode,
there is an issue of network latency -- exacerbated when the link speed
between client and server is low. IMAP provides server facilities that can
be used dramatically reduce the data transmitted between client and server.

First, there is "provision for determining message structure

without downloading entire message".
This allows the mail client to display information about MIME message
attachments without transferring them.
Moreover, "selective fetching of individual MIME body parts
means that if someone sends you a two line text message with a 10 MB
video clip attached , your mail client can choose to transfer only the two
lines of text until you specifically request the attachment . If connected via
dialup from a hotel room, this can be an enormous benefit. Efficient
processing of MIME messages is a significant benefit of IMAP over POP.
(MIME stands for Multipurpose Internet Mail extensions. It is technique
for encoding arbitrary files as attachments to SMTP and RFC-822
compatible mail messages) in the same vein, IMAP4 also provides for
selective retrieval of specific message headers.

Finally, the ability of IMAP software to use "server -based

searching and selection to minimize data transfer should not be
underestimated. This is one of the key advantages of an application specific messaging protocol in comparison to a general purpose file access
protocol (or POP in pseudo - online mode, for that matter). When the
client server does not include primitives to ask the server to do searching,
then searching transferring all of the data over the net to the client. Being
able to ask the server to find relevant messages by searching its local file
is a huge win.

IMAP DISADVANTAGES:

The protocol is more complex, and requires more effort to

implement.

The is currently less IMAP software available than POP software.

Obviously IMAP is more complex because it does more, but the

complexity concern is mitigated by two factors: first, depending on the
objectives of the he client, one may not need to use all the functionality
available. For example one of the earliest IMAP clients was POP mail
from the University of Minnesota .It offers only offline support, via
both POP and IMAP, but it is likely that the author found that the
complexity of implementing offline support was roughly the same as
for POP.A second mitigating factor is the existence of freely available
support libraries which implement IMAP protocol details .An example
is the c-client library from the University of Washington.

While it is true that the POP enjoys broader vendor

support than IMAP, there is already a substantial list of IMAP software,
and many POP software vendors are working to add IMAP support as
soon as possible .At the moment there are 20 different IMAP clients
available, and at least seven more in development.

6. IMAP THE FUTUER OF THE INTERNET MAIL.

Keeping the mail on the server, instead of storing it on our
own computer, is what LAN based email systems have been doing for
years .And threes a reason for that: it makes your mail easier to deal with,
in more powerful ways .IMAP gives the same power and advantages as
LAN based mail - but its an internet protocol, so the standard is open and
universal, and you will be able to access your mail from everywhere.
Here are just some of the advantages of the IMAP
revolution :
Mobile users:
Access and manipulate your mail and all your mail boxes (mail
folders) from anywhere - work, home on the road, even using some one
else computer - with total else convenience and transparency, without any
confusion about what you have read, when you have stored it, and so on.

Fast and Convenient:

Same valuable bandwidth ,because when you check your mail , all
your downloads is headers : you dont download any message before you
read it .Read or download any part of the MIME message without
downloading the other parts - no more waiting for attachments before you
can read your mail.
Business Powers -Collaborative tools:
Mail boxes (mail folders) can be shared! Collaborate with workers
easily _no more rerouting, forwarding confusion over multiple copies.

Message integration:
Everything in the message architecture can be integrated via
IMAP: Usenet news can be fed into shared folders and read as email
.Mailing lists and mailing list digests world just like Usenet news .Hold
bulletin board discussions with friends and co workers.
Mobility and persistent access to user data:
With ACAP and IMAP together, you will be able to store data not
in MIME and internet mail message format on the network .Keep your
Netscape bookmarks there, for sharing and for access on the road .Keep
company data, to-do lists schedules.

CONCLUSION.
The key points are that:

The "offline" message access paradigm is insufficient for

contemporary needs; support for "online" and "disconnected
access is essential.

In comparison to POP. IMAP offers equivalent "offline" support,

and far

superior support for "online" and "disconnected"

operation.

An application specific protocol such as IMAP offers important

advantages over generic file systems protocols.

The key virtue of the offline message access paradigm is that it minimizes
server connect time and server disk requirements .However , offline mode
works best for the people who use single client machine all the time ;its
not suited for the goals of accessing ones camping or saved messages
folder from different machines at different times .If one realizes on a
remote file system protocol to access message data on different machine
,this is really " online mode in disguise" -- but without the advantages of
the application specific protocol turned for online and disconnected
operation.
IMAP is such an application -specific protocol; a client
server messaging protocol designed to permit manipulation of the remote
mail boxes as if they were local .In addition to fully supporting the offline
access paradigm, it offers capabilities that are essential for proper online
message access, and which cannot be achieved with POP mailers unless
they also use general file system protocols to provide location-independent
access to message archives and message status information.

A reasonable conclusion is that the only advantage of POP

over IMAP is that there is currently more POP software available.
However, this is changing rapidly, and IMAP 's functional advantages over
POP are nothing less than overwhelming.

REFERNCES :
[1] www.linktionary.com/i/imap.html.
[2] www.imc.org.
[3] www.imc.org/fcs.html.
[4] www.ema.org.
[5] www.imap.org
[6] www.washington.edu/imap
[7] www.emailman.com
[8] www.screen.com/start/guide/email.html.
[9] www.idm.internet.com/foundation/imap4.html.
[10] Computer networks - Tenunbaum