When the email is delivered from the sending mail server, it has to be stored somewhere while time elapses until you, the user decides to retrieve it.

In general, most email servers store your email locally in a file or files on their hard disk drives.

Assuming then you are the client that will be reading your email, and you already have a login to the mail server, your email client will merely need to look inside the file(s) or inside the directory that stores the files.

There is another whole issue of what mailbox type you are using to store email, but we'll leave that until the advanced networking course where we actually configure a mail server.

For both Category 2 and 3, we will want to implement a retrieval protocol. Categories 2 and 3 are similar in many respects, but differ in the fact that in Category 3, you, the client have little to do with the organization offering the service.

A typical office environment (as is prevalent in many large corporate companies) is that describing Category 2, while a user that dials into their ISP to retrieve their email would be an example of Category 3. Of course these are not mutually exclusive, and one could implement both Categories in an environment.

In the case of Category 2, we do not want to log onto a separate machine in order to read our email.

Let 's make it a little more concrete. In the case of a large corporate, they may require that all their clients keep all email on a central server for the purposes of security, backups and the ability to roam around the office.

For this there is a protocol called the Internet Message Access Protocol or IMAP. IMAP is used in this scenario (office environment) since it encourages email to be stored on the server rather than an individual workstation client.

Thus, IMAP is a central point of storage of the email. Naturally, given this type of system, the system administrator will need to make the necessary arrangements to have the email backed up and will need to provide a good level of service delivery. You will not believe how fast users will moan if their email is not available.

The other method of email retrieval is that offered by the majority of ISP's.

ISP 's generally don't want to store your email permanently (perhaps they have limited storage capacity for all their clients to store email). As such, they are happy to store (for a very limited time) the email that arrives at their mail servers addressed to you, but as soon as you dial in to collect it, they expect you to take it away with you. They are usually not responsible for your mail once it is accessed by you (contrast with this, a corporate client who stored the email of everyone in the organization on a central email server).

Thus, in the ISP scenario, it makes little sense for the ISP to implement IMAP, since this implies our email will be stored in a central repository at the ISP - pretty pointless when you need to read something off-line.

Additionally, if the ISP has implemented IMAP, then when we do go online, all the messages will need to be downloaded to the client (in fact only the headers are downloaded with IMAP, the message body remains on the server until such time as it is accessed). This is a costly process in both time (you will be waiting for the email to download) and money (you will be paying phone charges while waiting - come to think of it, no wonder Telecoms companies are so wealthy!!). In this scenario, it may be wise to have a protocol that has the ability to pop the mail off the mail server and store it locally (on your machine) - enter the Post Office Protocol version 3 (POP3).

POP3 was designed to retrieve email from a mail server in "batch" mode and save it as files on the hard disk of the client machine. This system has the advantages in terms of time and money saved, as well as the ability to read your email anywhere, any time. However, the disadvantage is that if your hard disk fails (aka crashes), you loose all your email. But of course, you are a good system administrator and you have done adequate backups!

POP3 and IMAP are often bundled together in the same package. In this way, when you install a POP3 server, you get a free IMAP servers thrown in, or of course visa-versa. Now who said Linux was not good value for money!!!! POP3 and IMAP serve different purposes and it is wise to consider carefully what is required before offering one or the other. In general, MS Exchange is a modified IMAP type service.

POP3 and IMAP serve different purposes and it is wise to consider carefully what is required before offering one or the other. (In general, MS Exchange is a modified IMAP type service.)

In much the same way as we were able to walk through a SMTP conversation, we are able to walk through a POP3 and IMAP conversation. There are a variety of POP3 and IMAP commands, and we will look at some in the trouble shooting section later in this course.

Finally, POP and IMAP are inherently insecure. They send passwords unencrypted over the wire and are therefore prone to eavesdropping and packet sniffing. One method of solving this is by means of using certificates and implementing the secure sockets layer (SSL).

Thus in addition to POP3 and IMAP, there is POP3S and IMAPS and this will be covered in the advanced networking course when you configure a POP3 and IMAP server.

In conclusion then, when setting up an email client like Ximian's Evolution or Mutt, you need to supply an outgoing mail server (the SMTP server) as well as an incoming mail server (a POP3 or IMAP server). Once that is done, you should be able to send and receive email.

It is also worth noting that, on the whole, outgoing SMTP servers do not usually require that you authenticate in order to send email, while naturally incoming POP3 and IMAP servers will require one form of authentication.