Enterprise Software

Make Sent mail visible with the CDO Library

You can use the CDO Library to make Sent mail visible. Here's how.

This article originally appeared as a Web Development Zone e-newsletter.

By Phillip Perkins

This is a situation I frequently encounter: A company delivers mail within its Internet/intranet solution, and then employees don't understand why the mail isn't delivered to their Sent folders (in Microsoft Exchange Server). Most developers grab the CDONTS.NewMail object, set properties, and Send() the mail on its way.

The problem with that is CDONTS is an extension to the Collaboration Data Objects (CDO) Library that allows a cheap and easy way to send mail without having to begin a CDO session. In essence, CDONTS opens a port on the server, calls the destination server through SMTP, and sends the mail into cyberspace. In order to reach your Sent folder, the mail item would have to be delivered through Exchange. This doesn't happen using SMTP. You can accomplish this task by using the CDO Library, which is a collection of objects that wrap up MAPI functionality.

Follow these four easy steps to create a mail message and deliver it through the Exchange Server:

  1. Open a new CDO Session.
  2. Create a message.
  3. Set message Properties (which includes adding Recipients).
  4. Update and Send.

Note: The CDO Library uses a local profile to access Exchange, so Outlook 98 or above must be installed on the server and a profile must be set up for sending e-mail.

Are you concerned about the safety issues with regards to this procedure? If so, I would recommend that the appropriate architecture for deploying a solution like this would be to provide a COM component that wraps up this functionality, run this component in component services under a particular identity, and place this component on an application server with limited access. (For the purpose of this article, we'll assume that we can place Microsoft Outlook on the server and use a local profile.)

Here is the source code for sending a message:

Dim mapiSession, mapiMessage, mapiRecipient

Set mapiSession = Server.CreateObject("MAPI.Session")
mapiSession.Logon "ProfileName", "password", False

Set mapiMessage = mapiSession.Outbox.Messages.Add()
mapiMessage.Subject = Request.Form("txtSubject")
mapiMessage.Text = Request.Form("txtBody")

Set mapiRecipient = mapiMessage.Recipients.Add()
mapiRecipient.Name = Request.Form("txtTo")
mapiRecipient.Type = 1 'CdoTo
mapiRecipient.Resolve

mapiMessage.Update
mapiMessage.Send

mapiSession.Logoff
Set mapiRecipient = Nothing
Set mapiMessage = Nothing
Set mapiSession = Nothing

First, we create a new Session object and log on to Exchange. The Logon() method takes these parameters: Profile Name, Password, and Show Dialog. The Profile Name is the name of the profile that you created for authentication against Exchange. The Password is self-explanatory. The Show Dialog parameter is a Boolean value that specifies whether the login dialog box should appear. (In IIS, this should always be False.)

Next, we create a new Message object by Adding a new Message to the Messages collection of the Outbox folder. The Subject and Text (the body of the mail message) properties are set. Then, we create a Recipient object by Adding a new Recipient to the Recipients collection of the new Message object

Set the Name and Type properties, and then Resolve This Recipient. Resolve is a way to resolve aliases or full names to e-mail addresses or Exchange addresses for delivery. Resolve will throw an exception if the Name property is an alias or full name that isn't in the Address Book or doesn't qualify as an appropriate e-mail address.

Now, we Update the Message object. This method saves the message in the MAPI system. And finally, we Send the message and Logoff. The Send method queues the message for delivery. Be sure to release all of your references by setting your objects to Nothing.

When you successfully create a mail message and send it, you should see the message appear in the Sent folder of the particular profile. One of the other major benefits to using CDO instead of CDONTS is that you get detailed exceptions if an exception occurs. This makes it easier to debug when your messages quit arriving at their intended locations. Although there's more coding to do than with CDONTS, the extra coding is minimal.

If you'd like to read more about CDO and possibly open up a valuable marketplace of functionality with Exchange, you can find information about CDO on MSDN.

Phillip Perkins is a contractor with Ajilon Consulting. His experience ranges from machine control and client/server to corporate intranet applications.

Editor's Picks