Lector: Aliyev H.U.

Lecture №13: E-Mail Protocols and E-mail communication software design.

TASHKENT UNIVERSITY OF INFORMATION TECHNOLOGIES

THE DEPARTMENT OFDATA COMMUNICATION NETWORKS AND SYSTEMS

Introduction

• We touched on the various protocols that exist for sending and receiving e-mails across the network on the second lesson. E-mail protocols are broad in the sense that they don't only pertain to .NET. Ever since the rise of Internet messaging, e-mail has been a cornerstone of electronic communication. I'm sure almost everyone reading this book has had some prior experience sending e-mails within a programming language, so we aren't really covering some new and exciting technology that .NET brings to the table.

• What is exciting is how easy and seamless .NET makes network programming, especially with regard to using the various e-mail protocols to send and retrieve e-mails, and to perform various tasks that may have been convoluted or difficult in the past. In this chapter, we are going to give a high-level overview of the various e-mail protocols and how they are accessed and used in a .NET environment. Particular examples will be given in C#, and discussion will follow.

E-mail in a Nutshell• It's quite easy to think of e-mail like ordinary mail that you may send out. The big difference is

that no stamps are needed! Well, that and the fact that e-mail sending is almost instantaneous, and the postal service is usually very slow. There are various advantages to sending e-mail, though. E-mail can be sent to many recipients at once, as well as forwarded on and on very easily. However, in both cases we know that there is a starting point and an endpoint to a communication session. There is also a delivery mechanism that transfers the mail from one point to another along its mail route until it reaches its final destination. In the most generic sense, there are two components interacting in this scenario:

• Message Transfer Agent (MTA)• User Agent (E-mail client) • In our real-world snail mail example, the Transfer Agent may be a postal or carrier company

such as the USPS (United States Postal Service), FedEx, or UPS. The sender and receiver are quite obvious. In the electronic world, the place of the Transfer Agent is taken by the implementation of the SMTP (Simple Mail Transfer Protocol), which is responsible for directing e-mail from the starting point (sender) to the endpoint (receiver), bouncing the e-mail across various machines on the Internet. Keep in mind that this method stems from roots in TCP/IP, and is the most prevalent messaging topology used today. However, there are a number of other systems and standards that have been used for messaging in the past.

How does E-Mail Work?

E-Mail Protocols• As this scenario shows, the three main topics for e-mail programming are SMTP, POP3, and

IMAP. This is not to say that they are the only topics, just the ones that are most important to us developers when we are writing our applications that send and retrieve e-mail messages. This is because these are the standard protocols for sending and retrieving e-mail. We must keep in mind that these aren't the only ones, but the most commonly used and accepted methods. Other messaging standards such as X.400 exist as an alternative to TCP/IP related messaging. For more information about the X.400 protocol, see http://www.itu.int/ and http://www.alvestrand.no/x400/.

• Internet mail is largely defined by a number of standards and recommendations made by companies and individuals close to Internet technology research and design. These standards are endorsed by the IMC or Internet Mail Consortium (http://www.imc.org/) and the IETF or Internet Engineering Task Force (http://www.ietf.org). The current set of Internet mail standards is composed of many related RFCs (Request For Comments), recommendations, and statements on common practices. Not all standards are fully endorsed or full IETF standards documents, but are considered stable and are used throughout the industry for developing e-mail software.

• There are many RFCs available on the IMC web site (http://www.imc.org/rfcs.html). These documents are detailed and speak in much greater depth about every aspect of e-mail handling. For our purposes we are going to touch on a few of these RFCs within our discussion of various topics in this chapter. In particular, we will look at RFC 2821, which defines the SMTP protocol, and RFC 2822, which defines what an e-mail message should look like. For more information about these RFCs, take a look at the IMC web site.

SMTP• Simple Mail Transfer Protocol, or SMTP, is outlined in RFC 2821, and defines the

interaction between mail servers that are transporting e-mails. It's good to note that SMTP for the most part uses TCP as a transport protocol (see RFC 1090 for SMTP over X.25). In essence, an SMTP session consists of a conversation between two machines that are trying to hand off or pass along an e-mail message. A simplified view of this is shown in the following figure:

SMTP Command SummaryCommand Summary

Description

HELLO (HELO) Identifies the SMTP client to the SMTP server.MAIL (MAIL) Initiates a mail transaction to deliver an e-mail to one or more mailboxes.RECIPIENT (RCPT)

Identifies the recipient to whom the mail data is to be sent. If the data is to be sent to more than one recipient, multiple RCPT commands can be used.

DATA (DATA) Marks the start of the mail data. The data following the DATA command is appended to the mail buffer. The mail data may contain any of the 128 ASCII character codes. The end of the data is marked by the sequence <CRLF>.<CRLF>.

SEND (SEND) Initiates a mail transaction to deliver an e-mail to one or more terminals. Here it is important to note that ‘terminal' refers to a user's terminal screen. Because most clients are not terminal clients nowadays, the SEND, SOML, and SAML commands are for the most part obsolete. They are included here for the sake of completeness, because they are part of the RFC.

SEND or MAIL (SOML)

Initiates a mail transaction to deliver an e-mail to one or more terminals or mailboxes. The e-mail is delivered to the terminal of each recipient if that recipient is active on the host and accepting terminal messages, and to every recipient's mailbox.

(SAML) Initiates a mail transaction to deliver an e-mail to one or more terminals or mailboxes. The e-mail is delivered to the terminal of each recipient if that recipient is active on the host and accepting terminal messages, and to every recipient's mailbox.

RESET (RSET) Aborts the current mail transaction. All data will be discarded, and all buffers cleared. The receiver must send an OK reply.

VERIFY (VRFY) Asks the receiver to confirm that the following argument is a valid username. If it is, the full name of the user (if known) and the fully specified mailbox are returned.

EXPAND (EXPN) Asks the receiver to confirm that the following argument is a mailing list, and if so, to return the names of the members of that list. The full names of the users (if known) and the fully specified mailboxes are returned in a multi-line reply. This command is similar to the VRFY command, but is used for multiple recipients.

HELP (HELP) Asks the receiver to send helpful information to the sender. The command can take an argument (such as a command name) and return more specific information as a response.

NOOP (NOOP) This command has no effect, except that the receiver should send an OK reply. No operation takes place, and no other commands or data should be affected.

QUIT (QUIT) On receiving a QUIT command, the receiver must send an OK reply, and then close the connection to the sender.TURN (TURN) On receiving a TURN command, the receiver must either (1) send an OK reply and take on the role of the SMTP client; or (2)

send a refusal reply and retain the role of the SMTP server. This command is deprecated because of security concerns. Poor authentication implementations would allow a client machine to take on the role of the SMTP server and divert e-mail messages.

POP3• There are actually a few versions of the POP protocol that have been around. The POP2

and POP3 standards are not even compatible from a protocol standpoint. But since the huge majority of POP clients are POP3, we'll restrict our discussion to that protocol.

• So what does POP3 allow us to do? As we've already learned, POP3 only allows a client to retrieve mail from a mail server. This protocol allows us to write nice-looking GUI (Graphical User Interface) applications that will present e-mail in a way that's easy to read and manage. For reference, POP3 is outlined in further detail in RFC 1939.

• In the POP3 world, the mail exists on the mail server when it's received by the system. It just sits there, waiting to be picked up by a mail client. Once we connect to the mail server with a client mail program, the POP3 client copies the mail from the server to the local machine's hard drive. This method locks us into reading the mail on the client machine. Why would this make a difference? Depending on the situation, POP3 access might not be ideal. For instance, suppose we have a mail account that we read both at work and at home. Let's suppose that we have Microsoft Outlook installed on both the office and home machines. If we connect at the office and Outlook downloads four new mail messages, those messages will generally be removed from the server and transported to the local hard drive on the office machine. This means that we've lost access to those messages from our home machine. Because POP3 moves the messages from the server to your client machine, sharing a POP3 e-mail system between multiple machines can be troublesome.

IMAP• IMAP gives us everything that POP3 doesn't. It provides capability for on-line, off-

line, or disconnected modes of operation. It allows us to control folders on both the client machine as well as the server. It also provides enhanced authentication (POP3 authentication is relatively weak). And it allows the use of multiple mail servers that can work together with the same mail client.

• Let's take a brief look at how an IMAP client and server might interact:

IMAP• IMAP4 is outlined and documented in RFC 2060. Some of IMAP's features include:• Server-side Mailbox Manipulation• Ability to add messages to a remote mailbox• Support for and notification of simultaneous updates in shared mailboxes• New mail notification• Multiple Mailbox Support• Remote folder management: list/create/delete/rename• Support for folder hierarchies• Access to message types other than e-mail, such as NetNews• Online Performance Optimization• Provision for determining message structure without downloading the entire message• Selected retrieval of MIME body parts• Server-based search and retrieval to minimize data transfer• Perfect for Roaming Power Users• Shared folders overcome limitations of POP3 access on more than one machine• Performance optimization helps with slow mail server connections

.NET and E-Mails

• Now that we've had an overview of mail protocols, we can get to the most interesting bits of information. Once you understand the way the SMTP, POP3, and IMAP protocols work, the code being presented here should be very easy to follow.

• We'll start by looking at how to send e-mails using the .NET System.Web.Mail namespace, which allows us to send e-mail and attachments using SMTP. We'll also develop some sample applications that implement the SMTP and NNTP (the Network News Transport Protocol, which is used for newsgroup access and is very similar to SMTP).

System.Web.Mail NamespaceClass Description

Mail Attachment Represents the attachments of an e-mail.

MailMessage Represents the e-mail message itself.

SmtpMail Responsible for sending a MailMessage via SMTP.

Enumeration Description

Mail Encoding Specifies the encoding of the message-Base64 or UUEncode.

MailFormat Specifies the format of the message. Either HTML or Text.

MailPriority Specifies the priority of the message. High, Medium, or Low

SMTP Mailer Application

Important Code of SMTP Mailer Application

• private void button1_Click(object sender, System.EventArgs e)• { • // Create mail message • MailMessage email = new MailMessage(); • // Set message parameters • email.From = txtFrom.Text; • email.To = txtRecipient.Text; email.Subject = txt Subject.Text; • email.BodyFormat = System.Web.Mail.MailFormat.Text; • email.Body = txtMessage.Text;• // Add attachment • email.Attachments.Add(new MailAttachment(txtAttachment.Text,

MailEncoding.Base64)) • // Set SMTP server • SmtpMail.SmtpServer = txtSmtpServer.Text; • // Now send message SmtpMail.Send(email); }

SUMMARY• That just about concludes our talk about e-mail protocols. As you can clearly see,

there is much more to learn and dive into, and we've only touched the surface of fully understanding every nook and cranny of the RFCs and the protocols themselves. Just to recap, in this chapter we covered the basics of the SMTP, POP3, IMAP, and NNTP protocols and saw how those protocols worked together in sending and receiving e-mail messages over the Internet. We also took a deeper look and presented sample code to send e-mails via the .NET Framework's in-built classes for sending e-mails via SMTP, as well as developing some grassroots protocol implementation classes for POP3 and SMTP.

• Although I would have liked to dive deeper into topics such as the IMAP and MIME protocols, those are such deep and complex protocols that they would be hard to cover within the constraints of this chapter. However, there are third-party tools that allow you to use these protocols in .NET. Unfortunately, there is no easy way to implement this functionality ourselves, so for production use, one of the third-party controls would probably be more economical than developing our own implementation. It's not as easy as POP3 and NNTP.

Q&A?