Chapter 5: Integrating Mail Services

This chapter dives into the e-mail services available to the .NET Framework. First, it introduces the key concepts and protocols related to mail services. Next, it looks at sending and receiving mail messages programmatically. The chapter also shows how to incorporate Hypertext Markup Language (HTML) into mail messages as a means to streamline collaborative communication within the enterprise. Finally, it puts all of these elements to work as you build out the mail services layer in the IssueTracker application.

Understanding E-Mail Concepts

Sending and receiving e-mail messages across the Internet means interacting with countless variations of messaging clients and mail servers, each running on various operating system platforms. You can only successfully achieve this through well-defined protocols that specify how a message is encoded, sent, and received. As Figure 5-1 illustrates, these protocols work together to relay e-mail messages from the original sender to the final recipient.

Figure 5-1: Relationship between e-mail clients, servers, and binding protocols

Exploring the Exchange Protocols

In an electronic world filled with mixed technologies, the only way to exchange common information, such as e-mail, is through open communication standards. These open standards include exchange protocols for packaging, sending, and receiving e-mail.

Using the Simple Mail Transport Protocol

The Simple Mail Transport Protocol (SMTP) is a protocol generally used to send messages from a mail client to a mail server. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another.

Using the Post Office Protocol

When e-mail messages are exchanged, they are queued in message stores. The Post Office Protocol (POP) is used to retrieve mail messages that are queued in a mailbox. With POP, messages are removed from the mailbox after they have been transferred to the client. This enables mail clients to read messages offline. There are two versions of POP. POP2 is an older standard that requires SMTP to send messages. You can use the newer POP3 with or without SMTP.

Using the Internet Message Access Protocol

The Internet Message Access Protocol (IMAP) is also a protocol for retrieving e-mail messages. With IMAP, the message store keeps the messages for the clients. Each time the mail client reads the message, it downloads from the mail server. This enables multiple clients in multiple locations to access the same message, such as in Microsoft Hotmail. IMAP4 is similar to POP3 but supports some additional features including a keyword search through e-mail messages while they are still on the mail server. Also, users can select specific messages for download to the client instead of downloading all the messages. This lets the e-mail client respond faster because it can first download only the message subject and then later download the entire message body.

Using Multipurpose Internet Mail Extensions

Multipurpose Internet Mail Extensions (MIME) is a specification for formatting non-ASCII messages so that they can travel over the Internet. MIME enables the sending and receiving of rich media, such as graphics, audio, and video files. In addition to e-mail applications, Web browsers also support various MIME types to display or output files that are not in HTML format. A new version of MIME, called S/MIME, is also available and supports encrypted messages.

Exploring E-Mail Body Formats

The body format of e-mail messages can either be plain text or be HTML. Both formats are in common use today by enterprise applications, and each offers different advantages and disadvantages.

Using Plain-Text Messages

Plain-text messages have existed since the beginning of e-mail and are natively supported by all e-mail clients. HTML, however, is relatively new with support existing in most e-mail clients, but not all. Part of the resistance to HTML messages comes from Internet-enabled consumer devices, such as cellular phones, pagers , and Personal Digital Assistants (PDAs) that are hindered by low bandwidth as well as minimal message display areas. Another downside to HTML messages is that they have been widely adopted by the spam-sending community. As a result, many corporate e-mail filters are configured to block e-mail messages that use HTML formatting and stick with plain-text messages. Figure 5-2 illustrates how a plain-text e-mail message appears in a typical user 's e-mail client.

Figure 5-2: Plain-text e-mail message in Microsoft Outlook

Using HTML Messages

HTML messages offer a level of richness that significantly improves the readability and usability of an e-mail message. This richness can include specialized text formatting, embedded graphics, and audio clips. Figure 5-3 illustrates the same plain text e-mail message, enhanced with HTML formatting.

Figure 5-3: HTML e-mail message in Microsoft Outlook

The message body has been formatted with a different font in a variety of sizes. The message also contains page breaks and an embedded image. The message depicted in Figure 5-3 is more readable than its plain-text counterpart . When message sizes grow to multiple pages, ensuring good readability encourages the user to continue reading to the end.

In addition to enhanced message formatting, HTML messages also have the ability to include Web forms. HTML forms embedded within an e-mail message function as they do within any Web page. Form fields can include textboxes, check boxes, list boxes, option buttons, and push buttons . Form controls can be formatted and positioned with tables just as in Web pages.

To create HTML messages, set the BodyFormat property of the MailMessage object to HTML. Next, set the UrlContentBase property. This property designates the starting point for all relative Uniform Resource Locators (URLs) defined within the Web form, similar to the <BASEREF> tag in HTML. When the mail recipient clicks the Send button, the action specified in the <FORM> tag will execute. Furthermore, the click can take a POST action, sending the posted values to an .aspx file for processing. An example of such a <FORM> tag follows :

 <form     action="http://127.0.0.1/IssueTracker/IssueTracker_WebUI/ProcessSubmit.aspx" > 

In this case, the button form control triggers the POST action to submit all form data to the ProcessSubmit.aspx page. Chapter 7, "Building Web Applications," goes deeper into building Web forms that process user input. In an enterprise application, the URL specified in the action attribute should point to the deployed domain or subdomain of the server. Also, authentication is necessary to ensure that the person filling in the e-mail form is authorized to do so. You can implement this through Forms Authentication, which is detailed in Chapter 13, "Understanding .NET Security and Cryptography."

Exploring Platform E-Mail Services

On the Microsoft operating system platforms, the underlying Collaboration Data Objects (CDO) performs the messaging between the client and the server. CDO is a Component Object Model (COM) object library that exposes the interfaces of the Messaging Application Programming Interface (MAPI). CDO has evolved over the years and has taken many different names . In Exchange Server 4.0, it was termed OLE Messaging , and in Exchange Server 5.0, it was termed Active Messaging . With the release of Exchange Server 5.5, the library was renamed to CDO to describe its services as more than just messaging functionality. All applications using previous versions of CDO, from Exchange Server 4.0, are compatible with the latest version of the library.

Exploring .NET E-Mail Services

The .NET Framework provides limited support for e-mail manipulation within an application. The System.Web.Mail namespace defines a MailMessage object. This object abstracts a normal e-mail message with attributes, such as Subject, Body, and Priority. This namespace also provides the SmtpMail object with static methods , such as Send, used to deliver e-mail messages.

Unfortunately, the .NET Framework does not offer any capability to read messages directly from the mail server. Receiving e-mail messages is an important part of an enterprise solution, which can still be accomplished by interacting directly with the CDO library.

Receiving messages from a mail server is typically important to the enterprise developer because e-mail communication has become the dominant form of enterprise communication. An example use of mail receiving services includes embedding an e-mail client within a corporate portal. Another example might require an application to monitor customer postings and ensure that someone responds to them in a reasonable amount of time. This functionality is typical of Customer Relationship Management (CRM) applications. An automated response will let a customer know that their message was received. However, ensuring that a real customer support representative responds to the user is even more important for customer retention.

The CDO library is packaged as a COM component designed to simplify writing programs that create or manipulate e-mail messages. CDO is one in a suite of collaborative COM components referred to collectively as CDO and is an integral part of the Windows operating system. CDO is designed for creating applications that create and manage messages formatted and sent using Internet standards such as MIME. The CDO component supports sending messages using both the SMTP and the Network News Transport Protocol (NNTP), as well as through a local SMTP/NNTP service pickup directory.

Exploring Application Business Services

Chapter 2, "Accessing Data in ADO.NET," described application framework objects as memory structures that closely resemble parts of the database schema. They temporarily hold information that is passed between the database and the user interface. Application framework services, however, interact with the framework objects to accomplish specific business functions. Figure 5-4 illustrates the relationship between business objects and business services.

Figure 5-4: Relationship between the mail service and existing business objects

Within the application framework, business services are implemented within the Business Facade project. They are implemented as public classes that inherit from the abstract BusinessService class. They have methods that match specific business functions that need to be accomplished. Listing 5-1 presents the BusinessService base class.

Listing 5-1: The BusinessService Abstract Class Definition

 public abstract class BusinessService {     EventLog _SystemLog = new EventLog();     public BusinessService()     {     }     public void LogEvent( string strMessage )     {         try         {              _SystemLog.Source = "IssueTracker";              _SystemLog.WriteEntry( strMessage, EventLogEntryType.Error, 0 );         }         catch( Exception x )         {             Debug.WriteLine( "Unable to write to Event Log." );             Debug.WriteLine( "Event Massage:" + strMessage );         }         return;     } } 

 

The BusinessService class defines a specification for how business services must be implemented within the application framework. It also implements a more robust approach to application error logging. Although output to the console is useful during application debugging, it offers little help when the application is running in a deployed environment. The System.Diagnostics namespace also provides the EventLog object, which enables applications to write messages to the Windows system event log. Messages written to the event log are persisted , even if the server shuts down or restarts.