First, and foremost, you need the .NET Framework installed. Then you need a reference to the System.Web.dll (automatically included in ASP.NET applications). Then you need to use the System.Web.Mail namespace to create and send email messages.

Because SWM is simply a wrapper around the two COM libraries: CDONTS.NewMail (found in the cdonts.dll) and CDO.Message (found in the cdosys.dll) you will also need them installed on your server. If you are using NT4 or Win9x, the cdonts.dll is installed with the NT4 Option pack or with the personal webserver. The cdosys.dll is installed by default on Windows 2003 and on Windows XP. It can also be installed by installing Microsoft Office.

Once you can successfully use SWM, you will need a relay server to send email through. A relay server is a mail server, or a SMTP server/service, that can handle sending email. SWM simply sends the mail to a relay server, and the relay server is responsible for delivering it to the final destination.

Update

I got this email from Jay Harrlow, an Outlook MVP who corrected me about this item.
It begins...

CDOSYS.DLL is part of the OS and is only installed from the OS installs. Office (Outlook actually) can optionally install CDO.DLL which System.Web.Mail does not use.

For information on the various flavors of CDO see:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/exchanchor/htms/msexchsvr_cdo_top.asp

The four CDOs are (in chronological order):

- CDO.DLL : CDO version 1.2.1
- CDONTS.DLL : CDO version 1.2.1 for Windows NT Server (not the same as CDO version 1.2.1!)
- CDOSYS.DLL : CDO for Windows 2000
- CDOEX.DLL : CDO for Exchange 2000 Server

FWIW: CDOEX.DLL is installed as part of Exchange Server installs.
Jay

A relay is a service that allows you to send email. It is usually a full fledged mail server, or can be a specialized SMTP Service. Some examples of a mail server include Microsoft Exchange, IMail by IPSwitch, or Mail Enable by Mail Enable. An example of a SMTP service is the SMTP Service installed that can be installed with IIS. SWM sends email to a relay server, and the relay server is responsible for delivering the email to the final destination. When sending email to a relay server, you must have protocol permissions to use that server. Because of SPAM problems, relay servers are normally locked down, either by IPAddress or by some type of username/password authentication. Relaying errors are the most common problems when programmatically sending emails. If you ever see an exception that reads something like "550 Permission Denied", this is usually a relay error, and you need to talk to your mail server administrator about proper permissions.

Yes. System.Web.Mail is not a full .NET native implementation of the SMTP protocol. Instead, it uses the existing CDONTS and CDOSSYS dlls already written by Microsoft some years ago. This can best be demonstrated by using Anakrino and reflecting into the SWM namespace and SmtpMail class. Inside of the SmtpMail class are two private classes called CdoNtsHelper and CdoSysHelper. Under the covers, CdoNtsHelper creates the CDONTS.Newmail object, while the CdoSysHelper creates the CDO.Message class. This can best be seen in the two screen shots CdoNtsHelper.gif and CdoSysHelper.gif.

Another interesting fact, is how SWM decides to use either the CDONTS.Newmail or the CDO.Message object. When the SmtpMail class sends the MailMesage, the SmtMail class checks the OS version. If the version is <= 4, the CDONTS.Newmail object is used. For all OS’s greater than 4, the CDO.Message object is used. Again, using Anakrino, the SmtpMailSend.gif screen shot verifies this behavior. Because of this condition, troubleshooting SWM can become interesting, when moving the code to different OS’s.

The IIS SMTP service is a SMTP service used for sending email. It handles all of the MX Record (Mail server location) lookups, SMTP connections to remote mail servers, retries, and failures. More information about configuring the SMTP Service can be found here: Manage Your Company's E-mail with the Windows 2000 SMTP Service http://www.microsoft.com/mind/1299/smtp2000/smtp2000.asp

No. System.Web.Mail can only send email. To read email you either need a Mime parsing component such as aspNetMime or a POP3 component such as aspNetPOP3.

This System.Web.Mail QuickStart is a series of samples and supporting commentary designed to quickly acquaint developers with the syntax of sending email in .NET. The QuickStart samples are designed to be short, easy-to-understand illustrations of System.Web.Mail.

Important: When testing these samples, always be sure to:
1. Have a reference set to the System.Web.dll.
2. If you are using C#, be sure the "using System.Web.Mail;" statement is found at the top of your code. Or, if you are using VB.NET, be sure the "Imports System.Web.Mail" statement if found at the top of your code.
3. Set the correct FROM and TO addresses.
4. Set the SmtpMail.SmtpServer to a valid server that allows relaying for your FROM email address or the IP address you are sending email from.

The following example demonstrates sending a simple text email.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body";
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body"
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

By default, email sent with System.Web.Mail is formatted as plain text. To format as Html, set the MailMessage.BodyFormat property to MailFormat.Html.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.BodyFormat = MailFormat.Html;
mail.Body = "this is my test email body.<br><b>this part is in bold</b>";
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.BodyFormat = MailFormat.Html
mail.Body = "this is my test email body.<br><b>this part is in bold</b>"
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

To send an email with attachments, the ASP.NET process (or the ASP.NET impersonated account) will need permission to read the file, and attach it to the MailMessage class.

Note: Attachments can only be created from files on the file system. System.Web.Mail does not support creating attachments directly from strings, byte arrays, streams, or from uploaded files. To directly create attachments from these types, use aspNetEmail, otherwise, the attachment contents must first be saved to the file system.

The following example demonstrates adding the file "test.txt" as an attachment to a MailMessage.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
MailAttachment attachment = new MailAttachment( Server.MapPath( "test.txt" ) ); //create the attachment
mail.Attachments.Add( attachment );	//add the attachment
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
Dim attachment As New MailAttachment(Server.MapPath("test.txt")) 'create the attachment
mail.Attachments.Add(attachment) 'add the attachment
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

By default, many people set the FROM property of the MailMessage class to something like:

mail.From = "me@mycompny.com"

By doing this the email address will show up in the FROM line of most email readers, such as Outlook, Outlook Express, or Eudora. To have a friendly name be displayed (instead of the email address), use the following syntax.

mail.From = "\"John Smith\" <me@mycompny.com>"

The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "\"John Smith\" <you@yourcompany.com>";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = """John Smith"" <you@yourcompany.com>"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

The same technique used to display a friendly FROM name, is the same technique used to display friendly TO and CC fields. By default typical .To code looks like:

mail.To = "me@mycompny.com"

By doing this the email address will show up in the TO line of most email readers, such as Outlook, Outlook Express, or Eudora. To have a friendly name be displayed (instead of the email address), use the following syntax.

mail.To = "\"Jane Doe\" <me@mycompny.com>""

The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "\"Jane Doe\" <me@mycompany.com>";
mail.From = "\"John Smith\" <you@yourcompany.com>";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = """Jane Doe"" <me@mycompany.com>"
mail.From = """John Smith"" <you@yourcompany.com>"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

To specify multiple recipients for a MailMessage, simply separate each recipient with a semicolon. For example:

mail.To = "me@mycompany.com;him@hiscompany.com;her@hercompany.com";

The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com;him@hiscompany.com;her@hercompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com;him@hiscompany.com;her@hercompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

To add the Reply-To header to an email, you need to use the MailMessage.Headers property. For example:

mail.Headers.Add( "Reply-To", "alternate_email@mycompany.com")

The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
mail.Headers.Add( "Reply-To", "alternate_email@mycompany.com" );
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
mail.Headers.Add("Reply-To", "alternate_email@mycompany.com")
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

To add custom headers to an email, you need to use the MailMessage.Headers property. For example:

mail.Headers.Add( "X-Organization", "My Company LLC")

The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "this is my test email body.";
mail.Headers.Add( "X-Organization", "My Company LLC" );
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "this is my test email body."
mail.Headers.Add("X-Organization", "My Company LLC")
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

To change the port number, you will need to chane the http://schemas.microsoft.com/cdo/configuration/smtpserverport field.
The following code snippet demonstrates this technique.

[ C# ]

MailMessage mail = new MailMessage(); 
mail.To = "me@mycompany.com"; 
mail.From = "you@yourcompany.com"; 
mail.Subject = "this is a test email."; 
mail.Body = "Some text goes here"; 
mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpserverport", "your port number"); 
SmtpMail.SmtpServer = "mail.mycompany.com"; 
SmtpMail.Send(mail);

[ VB.NET ]

Dim mail As New MailMessage()
   mail.To = "me@mycompany.com"
   mail.From = "you@yourcompany.com"
   mail.Subject = "this is a test email."
   mail.Body = "Some text goes here"
   mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpserverport", "your port number") 'Put port number here

   SmtpMail.SmtpServer = "mail.mycompany.com" 'your real server goes here

   SmtpMail.Send(mail)

This System.Web.Mail Advanced Samples is a series of code samples and supporting commentary designed perform advanced email operations. Some of the topics discussed here cannot be achieved using System.Web.Mail, but are listed for completeness, and because I have seen these questions asked on various newsgroups and lists.

Important: When testing these samples, always be sure to:
1. Have a reference set to the System.Web.dll.
2. If you are using C#, be sure the "using System.Web.Mail;" statement is found at the top of your code. Or, if you are using VB.NET, be sure the "Imports System.Web.Mail" statement if found at the top of your code.
3. Set the correct FROM and TO addresses.
4. Set the SmtpMail.SmtpServer to a valid server that allows relaying for your FROM email address or the IP address you are sending email from.

In the beginning, when email was first being used, it was all us-ascii content. To handle different languages and character sets, different encodings must be used. The following example demonstrates sending a non us-ascii email, using the Chinese GB2312 character set as an example. The hardest part of sending non us-ascii email, is to determine the correct character set. For reference, an easy to use character set chart can be found at aspNetEmail's website, here: http://www.aspnetemail.com/charsets.aspx .

Note: There is one major pitfall with this technique. The original email rfcs required that all non us-character sets use the quoted-printable or base64 content transfer encoding (convert all characters above 127, to 2 or more bytes, so the individual byte value is less than 128). Email readers, then take these bytes, and convert them back to the original character set. System.Web.Mail does not encode higher end character sets. Instead, it just sends the characters unencoded (commonly known in the email world as 8 bit encoding). Thus, if your email recipient's mail server, or gateway, does not support 8 bit encoding, they will not receive the email. THERE IS NO WAY PROGRAMMATIC WAY OF CHECKING FOR THIS. The only way, is make sure the email message is properly encoded using the quoted-printable (preferred) or base64 content transfer encoding. If you are sending a newsletter, this can be a huge problem, because your newsletter will simply not be delivered, and there is a good chance, you will never know it. As an email vender, I've had customer after customer encounter this problem. And it has always been fixed by using the quoted-printable format. Because this cannot be controlled using System.Web.Mail, you will need to use a third party product like aspNetEmail. The bottom line is this: if you need to send emails, using a higher end character set, DO NOT USE System.Web.Mail. Either roll your own component (if you have the time), or purchase a third party product that properly encodes email messages.

For those people that don't have a choice, and have to use System.Web.Mail, the following is a code snippet demonstrating sending a non us-ascii email.

[ C# ]

MailMessage mail = new MailMessage();
mail.To = "me@mycompany.com";
mail.From = "you@yourcompany.com";
mail.Subject = "this is a test email.";
mail.Body = "Some Chinese characters or text goes here";
mail.BodyEncoding = System.Text.Encoding.GetEncoding( "GB2312" ); //set the proper character set here
SmtpMail.SmtpServer = "localhost";  //your real server goes here
SmtpMail.Send( mail );

[ VB.NET ]

Dim mail As New MailMessage()
mail.To = "me@mycompany.com"
mail.From = "you@yourcompany.com"
mail.Subject = "this is a test email."
mail.Body = "Some Chinese characters or text goes here"
mail.BodyEncoding = System.Text.Encoding.GetEncoding("GB2312") 'set the proper character set here
SmtpMail.SmtpServer = "localhost" 'your real server goes here
SmtpMail.Send(mail)

System.Web.Mail does not natively support sending a web page. However, using the WebRequest class, you can screen scrape web pages, and pass the resulting Html string to the MailMessage class. The following example demonstrates this technique.

Note: Be sure to import the System.Net and System.IO namespaces for this code snippet.

[ C# ]

private void Page_Load(object sender, System.EventArgs e)
{
	MailMessage mail = new MailMessage();
	mail.To = "me@mycompany.com";
	mail.From = "you@yourcompany.com";
	mail.Subject = "this is a test email.";
	string url = "http://www.microsoft.com";
	mail.Body = HttpContent( url );
	mail.BodyFormat = MailFormat.Html;
	mail.UrlContentBase = url;
	SmtpMail.SmtpServer = "localhost";  //your real server goes here
	SmtpMail.Send( mail );
}
//screen scrape a page here
private string HttpContent( string url )
{
	WebRequest objRequest= System.Net.HttpWebRequest.Create(url);
	StreamReader sr =  new StreamReader( objRequest.GetResponse().GetResponseStream() );  
	string result = sr.ReadToEnd();
	sr.Close();
	return result;
}

[ VB.NET ]

Private Sub Page_Load(sender As Object, e As System.EventArgs)
   Dim mail As New MailMessage()
   mail.To = "me@mycompany.com"
   mail.From = "you@yourcompany.com"
   mail.Subject = "this is a test email."
   Dim url As String = "http://www.microsoft.com"
   mail.Body = HttpContent(url)
   mail.BodyFormat = MailFormat.Html
   mail.UrlContentBase = url
   SmtpMail.SmtpServer = "localhost" 'your real server goes here
   SmtpMail.Send(mail)
End Sub 'Page_Load


'screen scrape a page here
Private Function HttpContent(url As String) As String
   Dim objRequest As WebRequest = System.Net.HttpWebRequest.Create(url)
   Dim sr As New StreamReader(objRequest.GetResponse().GetResponseStream())
   Dim result As String = sr.ReadToEnd()
   sr.Close()
   Return result
End Function

You can't do this using System.Web.Mail. Use something like aspNetEmail, which supports automatically embedding images in an email.

The global.asax class uses the Application_Error method to capture errors. Using System.Web.Mail, a webmaster can email themselves every time an error occurs.

The following code snippets demonstrates this technique.

[ C# ]

protected void Application_Error(Object sender, EventArgs e)
{
	Exception ex = Server.GetLastError();
	EmailException( ex );
}

private void EmailException( Exception ex )
{
	MailMessage mail = new MailMessage();
	mail.To = "me@mycompany.com";
	mail.From = "you@yourcompany.com";
	mail.Subject = "An exception occurred.";
	mail.Body = ex.ToString();
	SmtpMail.SmtpServer = "localhost";  //your real server goes here
	SmtpMail.Send( mail );
}

[ VB.NET ]

Protected Sub Application_Error(sender As [Object], e As EventArgs)
   Dim ex As Exception = Server.GetLastError()
   EmailException(ex)
End Sub 'Application_Error


Private Sub EmailException(ex As Exception)
   Dim mail As New MailMessage()
   mail.To = "me@mycompany.com"
   mail.From = "you@yourcompany.com"
   mail.Subject = "An exception occurred."
   mail.Body = ex.ToString()
   SmtpMail.SmtpServer = "localhost" 'your real server goes here
   SmtpMail.Send(mail)
End Sub 'EmailException

You can't. System.Web.Mail does not support encrypted messages.

You can't. System.Web.Mail does not support multipart/related messages.

If you want to directly control each part of the multipart/alternative sections of the email, this cannot be done with System.Web.Mail. However, if you create a Html formatted email, and System.Web.Mail uses the CDO.Message dll, an alternative text/plain part will automatically be created.

If you are using the .NET Framework 1.0, this cannot be done. However, in the 1.1 version, the MailMessage.Fields property was added. This allowed access to the underlying CDO.Message fields.

The following example demonstrates sending your username and password to the SMTP server to provide authentication.

[ C# ]

private void Page_Load(object sender, System.EventArgs e)
{
	MailMessage mail = new MailMessage();
	mail.To = "me@mycompany.com";
	mail.From = "you@yourcompany.com";
	mail.Subject = "this is a test email.";
	mail.Body = "Some text goes here";
	mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate", "1");	//basic authentication
	mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendusername", "my_username_here"); //set your username here
	mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendpassword", "super_secret");	//set your password here

	SmtpMail.SmtpServer = "mail.mycompany.com";  //your real server goes here
	SmtpMail.Send( mail );
}

[ VB.NET ]

Private Sub Page_Load(sender As Object, e As System.EventArgs)
   Dim mail As New MailMessage()
   mail.To = "me@mycompany.com"
   mail.From = "you@yourcompany.com"
   mail.Subject = "this is a test email."
   mail.Body = "Some text goes here"
   mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate", "1") 'basic authentication
   mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendusername", "my_username_here") 'set your username here
   mail.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendpassword", "super_secret") 'set your password here
   SmtpMail.SmtpServer = "mail.mycompany.com" 'your real server goes here
   SmtpMail.Send(mail)
End Sub 'Page_Load

This section will deal with troubleshooting System.Web.Mail and the various exceptions, problems, and questions that arise during programming.

Exceptions generated by System.Web.Mail fall into two categories.
1. Programming/Namespace/DLL exceptions.
and
2. SMTP Protocol exceptions.

Lets talk about Programming/Namespace/DLL errors. System.Web.Mail is actually a wrapper around the COM dlls CDOSys.dll and CDONTS.dll. (See 1.5. Is System.Web.Mail really a wrapper around the COM CDONTS and CDOSYS? for more information ). Thus, all programming exceptions are really COM related exceptions and are usually generated because there is either a problem accessing the CDOSys.dll or CDONTS.dll, or else these dlls are not installed.

The other exceptions that occur are usually not too obvious, but these are SMTP protocol or network exceptions. When these exceptions are thrown, System.Web.Mail is actually working correctly, but there is either a problem accessing the mail server, or there is a problem relaying through the mail server.

It's important to distinguish between these two exceptions. Unfortunately that is usually easier said than done. The most helpful way to check which type of exception is being thrown is to ITERATE THROUGH ALL INNER EXCEPTIONS. I CANNOT STRESS THIS STRONGLY ENOUGH!! 99% of the time, System.Web.Mail throws the "Could Not Access CDO.Message" exception. This message is not too helpful, however, by checking the Exception.InnerException, some additional helpful text is usually found that will shorten your troubleshooting time CONSIDERABLY.

The following code snippet demonstrates checking the InnerException for more information:
[ C# ]

private void Page_Load(object sender, System.EventArgs e)
{
	MailMessage mail = new MailMessage();
	mail.To = "me@mycompany.com";
	mail.From = "you@yourcompany.com";
	mail.Subject = "this is a test email.";
	mail.Body = "Some text goes here";
	SmtpMail.SmtpServer = "mail.fake_domain.com";  //will cause an exception to be thrown
	try
	{
		SmtpMail.Send( mail );
	}
	catch(Exception ex )
	{
		Response.Write("The following exception occurred: "  + ex.ToString() );
		//check the InnerException
		while( ex.InnerException != null )
		{
			Response.Write("--------------------------------");
			Response.Write("The following InnerException reported: " + ex.InnerException.ToString() );
			ex = ex.InnerException;
		}
	}
}

[ VB.NET ]

Private Sub Page_Load(sender As Object, e As System.EventArgs)
   Dim mail As New MailMessage()
   mail.To = "me@mycompany.com"
   mail.From = "you@yourcompany.com"
   mail.Subject = "this is a test email."
   mail.Body = "Some text goes here"
   SmtpMail.SmtpServer = "mail.fake_domain.com" 'will cause an exception to be thrown
   Try
      SmtpMail.Send(mail)
   Catch ex As Exception
      Response.Write(("The following exception occurred: " + ex.ToString()))
      'check the InnerException
While Not (ex.InnerException Is Nothing)
Response.Write("--------------------------------")
   Response.Write(("The following InnerException reported: " + ex.InnerException.ToString()))
ex = ex.InnerException
    End While
   End Try
End Sub 'Page_Load

This section of exception will deal with COM related exception. If you are getting a COM related exceptions its usually one of the following:
A) Either you, the ASP.NET account, or the impersonating account does not have permissions to access the CDOSys.dll/CDONTS.dll.
or
B) Or else the dlls are not installed.

Lets take a look at some of these exceptions.

This is usually permissions or a corruption/not-installed problem.

To check permissions, here are a few suggestions to try. While trying these suggestions, you may want to try the most liberal settings, until it works, and then tighten the settings down to make sure your server is secure.

Suggestion 1.
Add the ASPNET account to the administrators group. Now don't get freaked out on this suggestion. It's only a test. If you add the ASPNET account to the administrators group, and the exception goes away, then you KNOW it was a permissions error, and you can work from there. Just be sure to remove the ASPNET account FROM the administrators group, so you don't have a security hole in your server.

Suggestion 2.
Locate the "Common Files" folder, typically at c:\program files\common files\. Grant the ASPNET account read access to that folder, and subfolders.

Suggestion 3
Try adding the [assembly:PermissionSetAttribute(SecurityAction.RequestMinimum, Name ="LocalIntranet")] attribute to your assembly. More information on the PermissionSetAttribute attribute can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemsecuritypermissionspermissionsetattributeclasstopic.asp

Suggestion 4
If you are using "localhost" for the SmtpMail.SmtpServer property (or if you left it blank), you may want to try the following:
Open up IIS Admin. Locate the SMTP Server, and right-click select Properties. On the Security tab, add the ASPNET account as an Operator. Close the dialoag, and stop/start the SMTP Service. If this works, I don't know how to tell you to fix this problem. Sorry. However, I consider this a security breach, and would recommend you purchase a 3rd party product, and not use System.Web.Mail. Evidently there is something funky with your machine.

Suggestion 5
Open up the registry. Locate the CDOSys.dll and the CDONTS.dll. Grant full control to the ASPNET Account. If you can't locate either of these dlls, then you probably don't have them installed on your system. You need to get them installed.

Suggestion 6
Using Windows explorer, locate the MailRoot folder ( normally found at c:\inetpub\mailroot ). Grant the ASPNET account read/write permissions to this folder, and all subfolders.

Suggestion 7
If none of these suggestions work, you may not have the CDOSys.dll/CDONTS.dll's installed on your server, or else they may be corrupted.

These dlls are usually installed with Outlook, Outlook Express, or Microsoft Office. The CDONTS.dll is installed with the older NT4 Option Pack.

This knowledgebase article may be helpful PRB: Collaboration Data Objects for Windows NT, Collaboration Data Objects for Windows 2000, and Collaboration Data Objects for Exchange 2000 Require Outlook Express

Suggestion 8
I'm outt of suggestions. If I've missed anything, that you found works for you, please email me at dave@123aspx.com . Other than that, I suggest you may want to talk your boss into buying you a copy of aspNetEmail.

This suggestion comes compliments of mkayuri.

Thanks!
Dave
---------------------------------- Appreciate your great work on this error.
I thought I tried everything on this site, kept changing this and that and this and that...
When I used local smtp relay service, it works fine, but my case sends e-mail to the outside SMTP server (instead of localhost SMTP relay service) with SMTP Authentication;
I solved mine with adding the timeout setting;
MailMessage msg = new MailMessage();
...
msg.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpconnectiontimeout", 60);

The default value for smtp connection timeout is 30seconds. I just beefed up that part. I guess, 30 seconds wasn't enough for all SMTP connection (incl. name resolution, user authentication, etc. ).

I've been reading all small prints on this site and contemplating. But, somehow I got this solution so I wanted to say thank you and here's my due. :-)

I hope this might help someone else!

This one comes from James Baker. It's rather interesting, and I wanted to post it, in case it helps someone else.

Here you go.

Cheers!
Dave
--------------------------------------------------------
James writes:
I was getting the dreaded “Could not access CDO.Message” error and I found your site. I’ve come back to it on several occasions as this popped up. I went through every suggestion and nothing seemed to fix it. I only had this problem with *windows* applications, not ASP.NET. Anyway, on my development machine I have Outlook Express installed. I had set up my gmail account with it, which requires authentication/SSL on both inbound and outbound connections. For the fun of it, I removed this account entirely from Outlook Express. This immediately fixed the problem. As a test, I put the account back exactly as it was and the problem reappeared. Removed it again, problem free. I can’t imagine why this setting would affect an independent application, but it certainly did. Just thought I’d mention it. Thanks a million for your site, glad to know I’m not alone.

I had a user send me this suggestion. I'm posting his solution in case someone else runs into this problem. Here is the text from his suggestion.
--------------------------------------------

Ok... seriously! You just gotta add this to the list of things to check. It's [stupid] and it has less than nothing to do with programming (and I would know, I'm a server engineer). Maybe programmers all just know this inherently, but while troubleshooting a client's server, we found that the SMTP service had been inadvertently assigned a specific IP address instead of using "(not assigned)". It was using 192.168.1.22 while the application was set to send mail to the service at 127.0.0.1. The application wouldn't send mail until we changed it back to "(not assigned)"

I know. Stupid, right?

This comes from a poster named "Henry". I thought his solution was good enough, it deserved it's own entry. Here is what he said:
---------------------------------------------------------
I ran into this issue for attachments larger than 4KB. I solved it doing the following under IIS 6:
1. Reregister cdosys.dll
2. Run FileMon
3. Found that w3wp.exe was trying to write to Windows\temp
4. Determined from IIS Manager that the user account for the Application Pool for the specific site was "Network Service".
5. Added Network Service to Security on the folder Windows\temp folder with Modify Rights (needs delete rights or folder starts filling up with tmp files)

Problem solved.

I would like to thank this site and other posters on the web with similar issues for providing the right clues to solve this.

Typically this exception has to deal with the following line of code (or I should say ABSENCE of the following line of code):

SmtpMail.SmtpServer = "mail.your-domain.com"

By default, if SmtpMail.SmtpServer is not set, System.Web.Mail is supposed to use localhost as the default property. However, for some reason this doesn't appear work. If you are using the local SMTP Service to send emails, you may try the following values:

"127.0.0.1"
"localhost"
"the_machine_name_here"
"the_real_dns_name_here"
"the_machine_IP_Address_here"

That should fix it.

The following information was sent to me by someone named "delonge". Some helpful information (they sent):

Wanted to provide some additional information regarding a topic you have listed on SMTP and the SendUsing parameter.

Issue: Number=-2147220502(0x800403EA) App [1002]
Source=CDO.Message.1
Description= -2147220960[0x80040220]The "SendUsing" configuration value is invalid.

Additional Cause: The account running the code (usually a COM+ packaged component) which calls CDO (SMTP) does not have permissions to access the SendUsing configuration of the SMTP Metabase.

Additional Resolution: Run the adadd.vbs with the user account running the component code calling CDO.

This is probably the most common error thrown by System.Web.Mail. If you get this error, the FIRST THING TO DO, is to write out all InnerException messages.
This will tell you the true error and it will be easer to fix. See Checking the Exception (READ THIS FIRST) for more information.

Although this error message implies there is a permission problem, typically there isn't. However, after trying everything else, you may will want to try the suggestions listed at Error loading type library/DLL.

Now, on to some suggestions:

Suggestion 1
Specify a valid mail server for the SmtpMail.SmtpServer property. If that property is not set, at least set it to 127.0.0.1. For example:

SmtpMail.SmtpServer = "127.0.0.1"

Suggestion 2
If you are using "localhost" or "127.0.0.1" as the SmtpMail.SmtpServer, you may not have permissions to relay through the IIS SMTP Service. To allow access, open up the IIS Admin MMC. Locate the SMTP Virtual Server, and right-click, then select Properties. On the Access tab, click the Relay button. In the Relay Restrictions dialog, grant your IP address (127.0.0.1) to the Computers listbox. Close down all dialogs, and restart the SMTP Service.

Suggestion 3
If you are using "localhost" or "127.0.0.1" as the SmtpMail.SmtpServer, make sure Anonymous access is allowd. To allow access, open up the IIS Admin MMC. Locate the SMTP Virtual Server, and right-click, then select Properties. On the Access tab, click the Authentication button. Be sure "Anonymous Access" is the only checkbox checked. Close down all dialogs, and restart the SMTP Service.

Suggestion 4
The email address does not have a valid TO address. After iterating through the InnerExceptions, you may find this error message actually has to do with relaying. Try sending a test email to an email address that exists on the server specified by SmtpMail.SmtpServer. If you can send an email to that server, then it is a relay issue. Talk to your mail server administrator about letting your code relay through the mail server.

Suggestion 5
Use a real FROM address that exists on the SmtpMail.SmtpServer. Do not use something like "asdf@asdf.com", or some other bogus address as your MailMessage.FromProperty. More advanced mail servers will catch this, and will deny relaying.

Suggestion 6
I have no idea why this suggestion works, but I found it on the web. I figured I would mention it, just in case Suggestion 1 did not work. Instead of specifying

SmtpMail.SmtpServer = "127.0.0.1"

try

SmtpMail.SmtpServer.Insert( 0, "127.0.0.1 or your mail server name here")

Like I said, I don't know why this would work, but here is the thread: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF8&newwindow=1&threadm=ePdwqQfZDHA.2136%40TK2MSFTNGP10.phx.gbl&rnum=75&prev=/groups%3Fq%3Dcdo.message%2Bgroup:microsoft.public.dotnet.*%26num%3D50%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF8%26newwindow%3

The following suggestion comes from Duncan Smart. Although I haven't tested this, it looks interesting and may help someone out. One note, use at your own risk, as you will be modifing the IIS metabase.

Cheers!
Dave

The following exerpt is from Duncan:

Having had a look at http://systemwebmail.com/faq I thought you and your readers would find the following useful.

Below is a script we use when deploying our application. When you don't set the SmtpServer property (or set it to null) then CDO tries to use a local IIS SMTP service if installed, and sends emails by simply creating a text file to c:\inetpub\mailroot\pickup\. The "Could not access CDO.Message object" error message is due to CDO not being able to read the IIS metabase to locate the PickupDirectory value - which is where it will write emails to. This script allows ASPNET to look up the PickupDirectory value from the IIS metabase. In addition you might need to grant ASPNET access to the pickup directory itself Inetpub\Mailroot\Pickup.

For more control over MetaBase ACLs then use the MetaAcl.vbs utility: http://support.microsoft.com/support/kb/articles/Q267/9/04.ASP

Hope you, or someone finds it useful!

Duncan Smart
InfoBasis

[ vbscript ]

OPTION EXPLICIT
Dim obj, acl, ace, aspNetAce
Set obj = GetObject("IIS://localhost/SMTPSVC")
Set acl = obj.AdminAcl

Dim aspNetAcePresent : aspNetAcePresent = false


' Find "machine\ASPNET" access control entry
For Each ace in acl.DiscretionaryACL
If endsWith(ace.Trustee, "\ASPNET") Then
aspNetAcePresent = True
Exit For
End If
Next

If Not aspNetAcePresent Then
Set ace = CreateObject("AccessControlEntry")
ace.Trustee = "ASPNET"
ace.AccessMask = &H1 ' Read access
acl.DiscretionaryACL.AddAce ace

' Save changes
obj.AdminAcl = acl
obj.SetInfo

WScript.Echo "ASPNET account granted Read access to
'IIS://localhost/SMTPSVC'."

Else
WScript.Echo "ASPNET account already has access to
'IIS://localhost/SMTPSVC'."
End If


'==========================================================
Function endsWith(str1, suffix)
EndsWith = (Mid(str1,Len(str1)-Len(suffix)+1) = suffix)
End Function

The following suggestion comes from Rob Wilson. Although I haven't tested this, it looks interesting and may help someone out.

Cheers!
Dave

The following exerpt is from Rob:

Brialliant site which was about 3 hours too late for me... My solution to can not access CDO.Message seems to be a problem with office XP. It appears to register C:\program files\common files\microsoft shared\cdo\cdoex.dll which stops cdosys.dll being reregistered using regsvr32.

I must confess to not reading all the faq but as the CDO.Message page didn't mention this solution here it is .... the news item that solved the problem for me is at http://groups.google.co.uk/groups?q=cdosys.dll+office+xp&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=21eJ8.160899%24xS2.12891461%40news1.calgary.shaw.ca&rnum=2

Thanks for the hard work...
Rob

Here is yet another tip for the "could not access CDO.Message" exception.
It turns out that if you install any of the Exchange stuff, it installs the CDOEX.dll. Well, apparently, this dll is now used for all of the CDO.Message stuff from the COM side of things, and overwrites the CDOSYS.dll. Unfortunately, .NET is bound to the CDOSYS.dll, so it blows up when you try to send a message. The trick is to unregister the CDOEX.dll and register the CDOSYS.dll using regver32.exe.

Here is a translated article discussing this in detail.
http://babelfish.altavista.com/babelfish/urltrurl?lp=zh_en&url=http%3A%2F%2Fwww.microsoft.com%2FChina%2FCommunity%2Fprogram%2Foriginalarticles%2FTechDoc%2Fsendmail.mspx

Remember, always use caution when mucking with the registry.

Cheers!
Dave

Ok, here is another gem. I hadn’t heard of this one before. It seems that the CDO.Message exception can also be thrown if you set MailMessage.Priority = MailPriority.High, and do NOT have ADO installed on the server.

It seems that the Priority property depends upon ADO. Kudos to CrystalTech, and David Good.

Here is the complete post regarding this tip.
http://dotnetjunkies.com/weblog/harpua/posts/5190.aspx#5799

Cheers!
Dave

This is an awesome suggestion provided by Elizabeth Patton.

Thanks Elizabeth!
--------------------------------------------------------------------------------------

Thanks for your very useful web site at http://www.systemwebmail.com. I too have just been struggling with the scary "Could not access 'CDO.Message' object" error. Wanted to share my solution so you can add it to your list of suggestions.

Here's the exception we were getting:

System.Exception: Unable to send mail: Could not access 'CDO.Message' object. ---> System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80004005): Unspecified error

--- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
--- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at MyApp.MyApp.Util.SendEmail(MailMessage& objMail)
--- End of inner exception stack trace --- at MyApp.MyApp.Util.SendEmail(MailMessage& objMail) at MyApp.MI.btnServerSave_Click(Object sender, EventArgs e) --------

Here's the setup: ASP.Net web application using local SMTP mail service to send emails, some with attachments, some without attachments. Web app set to use Windows integrated security with impersonation, so web.config has these entries:

All worked fine until we went to the email attachments. Either the "unspecified error" exception was thrown, or on other servers the email was sent but the attachments were corrupted. GIFs, TIFs, PDFs, you name it. Turns out that when handling email attachments, CDO does not entirely assume the impersonation identity. Instead, the aspnet_wp.exe process identity defined in machine.config comes into play, same as it would if you were using anonymous access. This process needs to create its own temp directory, found on my machine under c:\Documents and Settings\\ASPNET\Local Settings. Then the authenticated users need to be able to access this as well. So we granted permissions on that dir to my MYDOMAIN\myusergroup. Problem solved!

Useful background found in Microsoft KB # 317012: http://support.microsoft.com/default.aspx?scid=kb;en-us;317012

This solution comes from Justin Bennit and David G.

Thanks Justin and David!
--------------------------
First from Justin
Something I took a while to track down, which wasn't in your troubleshooting section...

I was unable to get to the CDOSYS, with the scary cdo.message warning…

It turned out, my new NAI VirusScan 8.0 software has "Access Protection" in it, which blocks port 25 by default, thereby giving exactly the same error. Telnet to 25 on the local box identifies the problem by not finding the SMTP server installed on my XP client. I reinstalled it, but no avail. Then thought to check this. 10 seconds later, all email apps worked fine!

Unlike products such as Norton Internet Security, no firewall message/warning is given, so I was unaware the port was being blocked.

Regards,

Justin Bennett

Now from David This might be too specific an issue, but I'll mention it anyway. Setting SmtpMail.SmtpServer using the server name gives:

  Could not access 'CDO.Message' object.
innerexception: The transport failed to connect to the server.
Setting SmtpMail.SmtpServer using the IP address gives:
  Could not access 'CDO.Message' object.
    innerexception: The message could not be sent to the SMTP server. The transport
 error code was 0x800ccc15. The server response was not available

I tracked this issue down to McAfee VirusScan Enterprise 8.0 VirusScan Console, Access Protection, Properties, Port-Blocking tab, Rule:"Prevent mass mailing worms from sending mail" This blocks outbound access to any port 25 on the network. Edit button shows a list of excluded processes to which new processes can be added.

Regards,
DavidG

Most of the exceptions are either from poor network connective or from relaying permissions.

Solving these exceptions will mainly deal with checking

Network Connectivity
Correct SmtpMail.SmtpServer specified
The SmtpMail.SmtpServer is running
Can connect to SmtpMail.SmtpServer using telnet at port 25
You can relay through the mail server

Lets look at some specific exceptions.

Make sure the value specified at

SmtpMail.SmtpServer

Is a valid SMTP Server
Check to be sure the server System.Web.Mail is executing on can connect to the mail server. Some times firewalls or proxy servers can get in the way.
Try specifying the value by IP address. Poor DNS resolution can sometimes hinder name lookups.
Make sure the that the mail server is running at port 25

Typically this is a relay error. Make sure your mail server can relay for your MailMessage.From address. If that address is valid, you may need to allow relaying for your specific IP Address, or first authenticate before sending the email. See
4.3.5 Not a gateway or local host.
or
3.8 How do I authenticate to send an email?
for more information.

System.Web.Mail is working correctly, and is attempting to send the email. However, your SmtpMail.SmtpServer is not allowing relaying. Try one of the following suggestions:

Make sure the MailMessage.From is a valid email address that exists on the SmtpMail.SmtpServer.
Allow relaying for your MailMessage.From address (see your specific mail server documentation for this)
Allow relaying for your IP Address (see your specific mail server documentation for this).
Try authenticated first, before sending the email. Check out 3.8 How do I authenticate to send an email?
If you are using the IIS SMTP Service try allowing relaying for your IP address by:

Opening the IIS Admin MMC
Right-Clicking on the SMTP Virtual Server and selecting Properties
On the Access tab, click the Relay button
Grant 127.0.0.1 (or the IP address used by System.Web.Mail) to the Computers list.
Close all dialogs
Restarting the SMTP Service

This is happening because your SmtpMail.SmtpServer is rejecting addresses.

Make sure all email addresses specified at MailMessage.To, MailMessage.Cc, MailMessage.Bcc and MailMessage.From are valid email addresses.
Make sure you have permissions to relay through the server.
Make sure the MailMessage.From has permissions to relay through the server.

There are a couple of things that might be going on here.

Your SmtpMail.SmtpServer has been black listed by recipients.
Your server has been listed in an Open Relay Database, and you are being blacklisted.
Your System.Web.Mail code is generating 8bit emails, and they are getting rejected/deleted at various gateways. To check if you are generating 8 bit emails, view a generated emails' headers. If the Content-Transfer-Encoding header is set to 8 bit, this is probably the problem. Check out How do I send non US-ASCII emails? for more information.

Check out 3.8 How do I authenticate to send an email?

This is a relay error. Make sure you can relay through the SmtpMail.SmtpServer either by your IP address, by your MailMessage.From address, or if you need to authenticate, check out 3.8 How do I authenticate to send an email?
If SmtpMail.SmtpServer is set to "127.0.0.1" or "localhost", and you are using the built in IIS SMTP Service, you can allow relaying for 127.0.0.1 by

Opening the IIS Admin MMC
Right-Clicking on the SMTP Virtual Server and selecting Properties
On the Access tab, click the Relay button
Grant 127.0.0.1 (or the IP address used by System.Web.Mail) to the Computers list.
Close all dialogs
Restarting the SMTP Service

This is probably a relay error. Make sure you can relay through the SmtpMail.SmtpServer either by your IP address, by your MailMessage.From address, or if you need to authenticate, check out 3.8 How do I authenticate to send an email?
If SmtpMail.SmtpServer is set to "127.0.0.1" or "localhost", and you are using the built in IIS SMTP Service, you can allow relaying for 127.0.0.1 by

Opening the IIS Admin MMC
Right-Clicking on the SMTP Virtual Server and selecting Properties
On the Access tab, click the Relay button
Grant 127.0.0.1 (or the IP address used by System.Web.Mail) to the Computers list.
Close all dialogs
Restarting the SMTP Service

Also, be sure to check the InnerException for any additional, helpful information.

If you are getting this error, and you are adding attachments, you might be adding them incorrectly. You can only create a MailAttachment by specifying an absolute path.

For example, if you are doing something like:

MailAttachment a = new MailAttachment( "test.txt" );
m.Attachments.Add( a );

You will instead, need to explicitly specify the path. So try

MailAttachment a = new MailAttachment( Server.MapPath( "test.txt" ) ); //if this is an ASP.NET app
m.Attachments.Add( a );

or, from a console/winform app try

MailAttachment a = new MailAttachment( "c:\\test.txt" );
m.Attachments.Add( a );

There is something wrong with the SmtpMail.SmtpServer. Typically the disk is full, or the mail store is full, and it can't accept any more email at this time.

This is a network related error. Your application cannot connect to the mail server specified

SmtpMail.SmtpServer

Is a valid SMTP Server
Check to be sure the server System.Web.Mail is executing on can connect to the mail server. Some times firewalls or proxy servers can get in the way.
Try specifying the value by IP address. Poor DNS resolution can sometimes hinder name lookups.
Make sure the that the mail server is running at port 25
If you did not specify a SmtpMail.SmtpServer property, or if SmtpMail.SmtpServer points to "localhost" (or the equivalent), be sure the SMTP Service is running on port 25.
For testing purposes change the MailMessage.From and MailMessage.To properties to an address that exists on SmtpMail.SmtpServer. Some times this exception is thrown, when it really is a relay issue.

This section is dedicated to other issues, questions, or problems that arise when using System.Web.Mail. If you encounter an interesting situation, and come to a solution, I would love to hear it. Please email me at dave@123aspx.com.

Thanks,
Dave

You can't. See 2.3 How do I send an email with attachments? for more information.

This is a difficult question to answer. See any of the previous solutions above. If the OS’s are the same, and you're pretty sure the required dlls are installed, make sure your SmtpMail.SmtpServer will allow relaying from your production machine.

Usually this is an encoding problem. You may need to change the character set of your email. See 3.1 How do I send non US-ASCII emails? for a programming sample and more information.

Usually you have a line in the body that is too long. The email rfc's state that a line should not contain more than 1000 characters. Try inserting a CrLf (vbCrLf for VB.NET or "\r\n" for C#) in your message body to break up long lines.

You may want to try changing the attachment encoding. For example, create your attachments like:

MailAttachment attachment = new MailAttachment( "test.txt", MailEncoding.Base64)
or
MailAttachment attachment = new MailAttachment( "test.txt", MailEncoding.UUEncode)

Also, if you are using this on Windows 2000, there may be a bug in your IIS SMTP Service. Check out
Periods at the Beginning of a Line Are Removed When Placed into the SMTP Pickup Directory
http://support.microsoft.com/?id=286358

There can be a few different issues here. Lets try to briefly cover them.

1. If you open up messages in the badmail directory and you see something like:

Diagnostic-Code: smtp;554 Service unavailable; Client host [xxx.xxx.xxx.xxx] blocked using dnsbl.njabl.org (or some other Open Relay Database )

you are being labeled as a spammer by an Open Relay Database. Contact the Open Relay database that has blocked you for more information.

2. If you see a message like:

Unable to connect to transport….

Your mailserver cannot get out to the network, or else it cannot resolve DNS names. Using nslookup, verify you can correctly resolve DNS names, and perform MX record lookups on the sever. If that works, you may want to either try forwarding your mail to a smart host, or sending directly (depending upon which setting you have checked in the SMTP Service properties).

A smart host, is a mail sever that can forward mail on behalf of your server. If you have an additional mail server available, enter that mail server's IP address, or DNS name in the smart host text box. To get to the smart host text box:

Open the IIS Admin MMC
Right-click the Virtual SMTP Server, and select Properties
On the Delivery tab, click the Advanced button.
Under the Smart Host textbox, enter your smart host.
Either check/or uncheck The "Attempt direct delivery before sending to your smart host.".
Close all dialogs.

You may need to stop and restart the services after changing these settings.

Ok, you are going to *LOVE* this one. ;-)

There is a bug in System.Web.Mail (actually the underlying CDOSYS).. First a little background.

The SMTP RFC implements a technique called "dot stuffing". Basically, any line that starts with a period must be escaped (or 'dot stuffed'), by being replaced with 2 periods.

Then, when the SMTP server recognizes these dot stuffed line, it unescapes the dots, and replaces 2 dots with 1 dot (which is what the original line looked like). However, System.Web.Mail forgets to dot stuff lines. Thus all lines that start with a dot, are NOT dot stuffed, and the single dot (which there is supposed to be 2 dots) is removed (now there isn't any dot starting the line) by the SMTP server. Whew... how's that for an explanation?

Now, since PDFs are simply a marked up text file, and PDF commands start with a dot, that single dot is being removed by the SMTP server, thus being corrupted. If System.Web.Mail replaced all lines starting a dot with 2 dots, then everything would be fine, because the receiving SMTP server would replace the 2 dots with 1 dot.

So, now, how do you fix this? Well, the only solution (that I know of ) is to purchase a reliable 3rd party component such as aspNetEmail. If anyone else knows of a different solution, feel free to post it here.

Still don't believe me, and want to test and verify this is a problem? Run the following code snippet:
[ C# ]

MailMessage m = new MailMessage();
  
   m.From = "dave@aspnetemail.com";
   m.To = "dave@aspnetemail.com";
   m.Subject = "period test";
   m.Body= "this \r\n. is a test";
 
   MailAttachment a = new MailAttachment( "c:\\test.txt" );
   m.Attachments.Add( a );
   
   SmtpMail.Send( m );

[ VB.NET ]

Dim m As New MailMessage()

m.From = "dave@aspnetemail.com"
m.To = "dave@aspnetemail.com"
m.Subject = "period test"
m.Body = "this " + ControlChars.Cr + ControlChars.Lf + ". is a test"

Dim a As New MailAttachment("c:\test.txt")
m.Attachments.Add(a)

SmtpMail.Send(m)

where test.txt consists of

.1
.2
.3
.4
and you will see the periods are removed.

The following is a list of links and resources to help with System.Web.Mail.

The following is a list of community support groups and email lists.

http://groups.yahoo.com/group/aspnetemail/

http://www.aspadvice.com/category.aspx?c=17

microsoft.public.dotnet.general
http://msdn.microsoft.com/newsgroups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.public.dotnet.general

microsoft.public.dotnet.framework
http://msdn.microsoft.com/newsgroups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.public.dotnet.framework

microsoft.public.dotnet.framework.aspnet
http://msdn.microsoft.com/newsgroups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.public.dotnet.framework.aspnet

The following is a list of links and knowledgebase articles to help you better understand System.Web.Mail.

A listing of various tutorials and code snippets found throughout the web.
http://www.123aspx.com/directory.aspx?dir=88

This article demonstrates how to use System.Web.Mail to send an e-mail message in Visual C#. NET.
http://support.microsoft.com/default.aspx?scid=kb;en-us;310273

When messages that are generated with the Microsoft Collaboration Data Objects for NTS (CDONTS) or Microsoft Collaboration Data Objects for Windows 2000 (CDOSYS) contain a period at the beginning of the line and are placed in the SMTP Pickup directory for delivery, the leading period is removed. This may distort the validity of the line.
http://support.microsoft.com/?id=286358

A list of the most common issues seen (and experienced) with sending email from ASP.NET applications
http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=314034

The System.Web.Mail namespace contains classes that enable you to construct and send messages using the CDOSYS (Collaboration Data Objects for Windows 2000) message component.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebmail.asp

This will walk you through the Windows 2000 SMTP service so you can understand its capabilities and learn how to effectively administer it.
http://www.microsoft.com/mind/1299/smtp2000/smtp2000.asp

When you try to send e-mail messages to recipients from certain domains, you may experience the following behaviors:

The e-mail message is not delivered and you receive a non-delivery report (NDR) that contains error code 5.0.0.
The number of domains that you cannot send e-mail messages to increases.
You notice one or more of the following events in the Application log of the Event Viewer:

http://support.microsoft.com/default.aspx?kbid=300580

If you send Simple Mail Transfer Protocol (SMTP) mail by using a Collaboration Data Objects for Windows (CDOSYS) application, a Collaboration Data Objects for Exchange 2000 (CDOEX) application, or System.Web.Mail on a computer where Exchange 2000 Server Service Pack 3 (SP3) is installed, you receive the following error message:

CDO.Message.1 (0x80040220)
The "SendUsing" configuration value is invalid.
http://support.microsoft.com/default.aspx?scid=kb;en-us;816789

This article describes and gives sample code on how to use Collaboration Data Objects (1.1, 1.2, 1.21) to set an alternate "Reply To" recipient of a message. This functionality, when enabled on a message, automatically populates the Recipients collection of the message with a recipient other than the original sender (which is the default) when the recipient of this message selects "Reply".
http://support.microsoft.com/default.aspx?scid=kb;en-us;181408

This article outlines the access rights that are granted to the default process account and describes some situations in which these rights may be too restrictive for certain tasks.
http://support.microsoft.com/default.aspx?scid=kb;en-us;317012

5.2.9 PRB: Collaboration Data Objects for Windows NT, Collaboration Data Objects for
Windows 2000, and Collaboration Data Objects for Exchange 2000 Require Outlook Express Printer Friendly Email This FAQ

Discuss

Collaboration Data Objects (CDO) for Windows NT (CDONTS), CDO for Windows 2000 (CDOSYS), and CDO for Exchange 2000 (CDOEX) require that you have Outlook Express installed on your computer. If Outlook Express is not installed, or if some components are corrupted, you receive random errors. You may receive the following errors:

8007007e (-2147024770), "The specified module could not be found"

800a01ad "ActiveX component cannot create object"
This issue also occurs with System.Web.Mail. System.Web.Mail is a wrapper for CDOSYS and CDOEX.
http://support.microsoft.com/default.aspx?scid=kb;en-us;327219

The following set of RFCs can be used as a reference or starting point for locating email related RFCs at a glance.
A more complete set of email related RFCs can be found at http://www.imc.org.

This set of RFCs deal with sending (SMTP) email. To read email, POP3 or IMAP protocols are used.

http://www.ietf.org/rfc/rfc2821.txt
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:

the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [30]
domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27]
the clarifications and applicability statements in RFC 1123 [2]
material drawn from the SMTP Extension mechanisms [19]

http://www.ietf.org/rfc/rfc2852.txt
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.

This extension should not be viewed as a vehicle for requesting "priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period.

A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond 17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a "delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems.

http://www.ietf.org/rfc/rfc2034.txt
This memo defines an extension to the SMTP service [RFC-821, RFC- 1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. These codes can then be used to provide more informative explanations of error conditions, especially in the context of the delivery status notifications format defined in RFC 1894.

http://www.ietf.org/rfc/rfc3463.txt
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status.

http://www.ietf.org/rfc/rfc3461.txt
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.

http://www.ietf.org/rfc/rfc3462.txt
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.

This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.

http://www.ietf.org/rfc/rfc2554.txt
This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL].

http://www.ietf.org/rfc/rfc2505.txt
This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*).

The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.

The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.

A brief summary of this memo is:

Stop unauthorized mail relaying.
Spammers then have to operate in the open; deal with them.
Design a mail system that can handle spam.

http://www.ietf.org/rfc/rfc2442.txt
This document defines a MIME content type suitable for tunneling an ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g., [RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure. Enabling the transfer of multiple separate messages in a single transactional unit.

http://www.ietf.org/rfc/rfc1047.txt
Over the past few years, the staff of the CSNET Coordination and Information Center (CIC) has often been asked to help determine why a single mail message is being delivered multiple times to its recipients. In the process of tracing the problems of multiple delivery, we have discovered that many duplicate messages are the result of a synchronization problem in SMTP. There is a point in the process of delivering a message where the receiving mailer knows it has accepted the message but the sending mailer is still not sure the message has been reliably delivered. If the SMTP conversation is broken at this point, the sending mailer will be forced to re-deliver the message, even though the message has already been received and delivered by the receiving mailer.

http://www.ietf.org/rfc/rfc974.txt
The purpose of this memo is to explain how mailers are to decide how to route a message addressed to a given Internet domain name. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. Note that this memo makes no statement about how mailers are to deal with MB and MG RRs, which are used for interpreting mailbox names.

http://www.ietf.org/rfc/rfc1869.txt
The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, effective basis for the relay function of message transfer agents. Although a decade old, SMTP has proven remarkably resilient. Nevertheless, the need for a number of protocol extensions has become evident. Rather than describing these extensions as separate and haphazard entities, this document enhances SMTP in a straightforward fashion that provides a framework in which all future extensions can be built in a single consistent way.

http://www.ietf.org/rfc/rfc1870.txt
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.

http://www.ietf.org/rfc/rfc1652.txt
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP.

http://www.ietf.org/rfc/rfc3030.txt
This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (Multipurpose Internet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.

http://www.ietf.org/rfc/rfc1846.txt
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.

http://www.ietf.org/rfc/rfc1985.txt
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.

http://www.ietf.org/rfc/rfc2645.txt
With the spread of low-cost computer systems and Internet connectivity, the demand for local mail servers has been rising. Many people now want to operate a mail server on a system which has only an intermittent connection to a service provider. If the system has a static IP address, the ESMTP ETRN command [ETRN] can be used. However, systems with dynamic IP addresses (which are very common with low-cost connections) have no widely-deployed solution.

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP [SMTP, ESMTP], providing for a secure, extensible, easy to implement approach to the problem.

The POP/IMAP RFCs are used for reading email from the server. To send email, SMTP must be employed. See the previous RFCs for sending email.

http://www.ietf.org/rfc/rfc2298.txt
This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.

http://www.ietf.org/rfc/rfc1731.txt
The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command.

http://www.ietf.org/rfc/rfc2342.txt
IMAP4 [RFC-2060] does not define a default server namespace. As a result, two common namespace models have evolved:

The "Personal Mailbox" model, in which the default namespace that is presented consists of only the user's personal mailboxes. To access shared mailboxes, the user must use an escape mechanism to reach another namespace.

The "Complete Hierarchy" model, in which the default namespace that is presented includes the user's personal mailboxes along with any other mailboxes they have access to.

These two models, create difficulties for certain client operations. This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. This allows a client to avoid much of the manual user configuration that is now necessary when mixing and matching IMAP4 clients and servers.

http://www.ietf.org/rfc/rfc2359.txt
The IMAP extension described here assumes a particular means of using IMAP to support disconnected operation. However, this means of supporting disconnected operation is not yet documented. Also, there are multiple theories about how best to do disconnected operation in IMAP, and as yet, there is no consensus on which one should be adopted as a standard.

http://www.ietf.org/rfc/rfc3348.txt
Many IMAP4 [RFC-2060] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a

visual clue (such as a "+") to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked the hierarchy list is expanded to show the child mailboxes.

Several IMAP vendors implemented this proposal, and it is proposed to document this behavior and functionality as an Informational RFC.

There is interest in addressing the general extensibility of the IMAP LIST command through an IMAP LIST Extension draft. Similar functionality to the \HasChildren and \HasNoChildren flags could be incorporated into this new LIST Extension. It is proposed that the more general LIST Extension draft proceed on the standards track with this proposal being relegated to informational status only.

If the functionality of the \HasChildren and \HasNoChildren flags were incorporated into a more general LIST extension, this would have the advantage that a client could then have the opportunity to request whether or not the server should return this information. This would be an advantage over the current draft for servers where this information is expensive to compute, since the server would only need to compute the information when it knew that the client requesting the information was able to consume it.

http://www.ietf.org/rfc/rfc2683.txt
The IMAP4 specification [RFC-2060] describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.

http://www.ietf.org/rfc/rfc2971.txt
The ID extension to the Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) protocol allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete.

http://www.ietf.org/rfc/rfc3502.txt
This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND".

http://www.ietf.org/rfc/rfc3503.txt
The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.

This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products.

http://www.ietf.org/rfc/rfc3516.txt
This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content- transfer-encoding.

http://www.ietf.org/rfc/rfc2476.txt
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA].

However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).

Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality.

Separating messages into submissions and transfers allows developers and network administrators to more easily:

Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail
Implement authenticated submission, including off-site submission by authorized users such as travelers
Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission
Detect configuration problems with a site's mail clients
Provide a basis for adding enhanced submission services in the future

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.

http://www.ietf.org/rfc/rfc1939.txt
On certain types of smaller nodes in the Internet it is often impractical to maintain a message transport system (MTS). For example, a workstation may not have sufficient resources (cycles, disk space) in order to permit a SMTP server [RFC821] and associated local mail delivery system to be kept resident and continuously running. Similarly, it may be expensive (or impossible) to keep a personal computer interconnected to an IP-style network for long amounts of time (the node is lacking the resource known as "connectivity").

Despite this, it is often very useful to be able to manage mail on these smaller nodes, and they often support a user agent (UA) to aid the tasks of mail handling. To solve this problem, a node which can support an MTS entity offers a maildrop service to these less endowed nodes. The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. Usually, this means that the POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it.

POP3 is not intended to provide extensive manipulation operations of mail on the server; normally, mail is downloaded and then deleted. A more advanced (and complex) protocol, IMAP4, is discussed in [RFC1730].

For the remainder of this memo, the term "client host" refers to a host making use of the POP3 service, while the term "server host" refers to a host which offers the POP3 service.

http://www.ietf.org/rfc/rfc2244.txt
The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.

http://www.ietf.org/rfc/rfc1056.txt
Pcmail is a distributed mail system providing mail service to an arbitrary number of users, each of whom owns one or more workstations. Pcmail's motivation is to provide very flexible mail service to a wide variety of different workstations, ranging in power from small, resource-limited machines like IBM PCs to resource-rich (where "resources" are primarily processor speed and disk space) machines like Suns or Microvaxes. It attempts to provide limited service to resource-limited workstations while still providing full service to resource-rich machines. It is intended to work well with machines only infrequently connected to a network as well as machines permanently connected to a network. It is also designed to offer diskless workstations full mail service.

http://www.ietf.org/rfc/rfc1204.txt
Operating systems for personal computers do not provide a mechanism for user authentication. However, such a mechanism is crucial for electronic mail system since authenticating message sender's identity is important in preventing mail forgery. Hence, adding personal computers to an electronic mail network requires an agent (message posting server) to authenticate sender's identity and then submit mail to the message delivery system (e.g., Sendmail, MMDF) on behalf of the sender at a PC. The Netix Message Posting Protocol is developed to be the interface between the message posting server and the PC (client). The protocol is designed to use TCP and is based on the command and reply structures defined for Simple Mail Transfer Protocol (RFC 821) and File Transfer Protocol (RFC 959).

http://www.ietf.org/rfc/rfc1339.txt
This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified

http://www.ietf.org/rfc/rfc1734.txt
This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. The authentication and protection mechanisms used by the POP3 AUTH command are those used by IMAP4.

http://www.ietf.org/rfc/rfc1957.txt
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind

http://www.ietf.org/rfc/rfc2384.txt
[POP3] is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient.

A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources.

A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. [ACAP] is one case where a string encapsulation of elements required to access network services is needed. For example, an [IMAP4] message store is usually specified in ACAP datasets as an [IMAP-URL].

This memo defines a URL scheme for referencing a POP mailbox.

http://www.ietf.org/rfc/rfc2449.txt
This extension to the POP3 protocol is to be used by a server to express policy descisions taken by the server administrator. It is not an endorsement of implementations of further POP3 extensions generally. It is the general view that the POP3 protocol should stay simple, and for the simple purpose of downloading email from a mail server. If more complicated operations are needed, the IMAP protocol [RFC 2060] should be used. The first paragraph of section 7 should be read very carefully.

http://www.ietf.org/rfc/rfc3206.txt
This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP- CODE) is defined.

http://www.ietf.org/rfc/rfc2195.txt
While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access. This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.

http://www.ietf.org/rfc/rfc3501.txt
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.

IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.

IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.

IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.

The following set of RFCs deal with message formats used by email clients. Both for reading and composing email related text.

http://www.ietf.org/rfc/rfc2822.txt
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.

http://www.ietf.org/rfc/rfc2049.txt
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other than US-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other than US-ASCII.

These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US- ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME- related facilities. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. Appendix B of this document describes differences and changes from previous versions.

6.3.11 RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Printer Friendly Email This FAQ

Discuss

http://www.ietf.org/rfc/rfc2183.txt
This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.

This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and [RFC 822]. The information presented herein supplements but does not replace that found in those documents.

This document is a revision to the Experimental protocol defined in RFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the File Transfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values.

http://www.ietf.org/rfc/rfc2557.txt
HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI.

In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure.

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure.

http://www.ietf.org/rfc/rfc2854.txt
This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC 1942 and RFC 2070, and to remove HTML from IETF Standards Track.

http://www.ietf.org/rfc/rfc2392.txt
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.

http://www.ietf.org/rfc/rfc2646.txt
Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap." (See section 3.)

Attempts to deploy new media types, such as Text/Enriched [RICH] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.

What is required is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain.

http://www.ietf.org/rfc/rfc2387.txt
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use.

http://www.ietf.org/rfc/rfc3066.txt
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags.

6.3.18 RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations Printer Friendly Email This FAQ

Discuss

http://www.ietf.org/rfc/rfc2231.txt
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide

(1) a means to specify parameter values in character sets other than US-ASCII,

(2) to specify the language to be used should the value be displayed, and

(3) a continuation mechanism for long parameter values to avoid problems with header line wrapping.

This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set.

http://www.ietf.org/rfc/rfc2017.txt
This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). URLs provide schemes to access external objects via a growing number of protocols, including HTTP, Gopher, and TELNET. An initial set of URL schemes are defined in RFC 1738.

http://www.ietf.org/rfc/rfc2076.txt
This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.

http://www.ietf.org/rfc/rfc2388.txt
This specification defines an Internet Media Type, multipart/form- data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form.

http://www.ietf.org/rfc/rfc2376.txt
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.

http://www.ietf.org/rfc/rfc1524.txt
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined by RFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and the Multipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system.

http://www.ietf.org/rfc/rfc1896.txt
MIME [RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched MIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described in [RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed.

http://www.ietf.org/rfc/rfc1428.txt
Protocols for extending SMTP to pass 8bit characters have been defined [3] [4]. These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extended SMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.

http://www.ietf.org/rfc/rfc1740.txt
This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non- Macintosh systems access to data in standardized formats.

http://www.ietf.org/rfc/rfc1741.txt
This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile [FALT94] for maximum interoperability.

http://www.ietf.org/rfc/rfc1767.txt
Electronic Data Interchange (EDI) provides a means of conducting structured transactions between trading partners. The delivery mechanism for these types of transactions in a paper world has been the postal system, so it is to be expected that electronic mail would serve as a natural delivery mechanism for electronic transactions. This specification permits formatted electronic business interchanges to be encapsulated within MIME messages [Bore92]. For the specification effort, the basic building block from EDI is an interchange.

This specification pertains only to the encapsulation of EDI objects within the MIME environment. It intends no changes in those objects from the primary specifications that define the syntax and semantics of them. EDI transactions take place through a variety of carriage and exchange mechanisms. This specification adds to that repertoire, by permitting convenient carriage through Internet email.

http://www.ietf.org/rfc/rfc1844.txt
This document presents a checklist that facilitates evaluation of MIME capable E-mail User Agents. It is by no means a conformance or interoperability (both strictly defined and measurable quantities) checklist, but rather an interworking (practical perspective) checklist that is aimed at the users and system managers.

http://www.ietf.org/rfc/rfc1153.txt
High traffic volume large mailing lists began to appear on the net in the mid-70s. The moderators of those lists developed a digest message format to enclose several messages into one composite message for redistribution to the mailing list addressees. This format reduces the mailer load in proportion to the number of messages contained within a digest message, and conserves network bandwidth by reducing the size of the headers of the enclosed messages.

This RFC documents the digest message format so that others may follow this format in creating (digestifying) and separating (undigestifying) digest messages to maintain compatibility with the programs expecting this de facto standard. Any editorial functions performed at the discretion of a digest moderator, such as discarding submissions, editing content to correct spelling and punctuation errors, inserting comments, and reformatting paragraphs to conform to width conventions are beyond the scope of this memo.

This memo describes the de facto standard Digest Message Format. It is not meant to supersede nor replace the generic message encapsulation format described in RFC 934. It merely documents a particular message encapsulation format that existed well before RFC 934 was published and continues to be the format of choice for digest messages.

http://www.ietf.org/rfc/rfc1864.txt
Despite all of the mechanisms provided by MIME [1] which attempt to protect data from being damaged in the course of email transport, it is still desirable to have a mechanism for verifying that the data, once decoded, are intact. For this reason, this memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. The Content-MD5 header may also be placed in the encapsulated headers of an object of type message/external-body, to be used to verify that the retreived and decoded data are the same data that were initially referenced.

MD5 is an algorithm for computing a 128 bit "digest" of arbitrary- length data, with a high degree of confidence that any alterations in the data will be reflected in alterations in the digest. The MD5 algorithm itself is defined in [2]. This memo specifies how the algorithm may be used as an integrity check for MIME mail.

Complete FAQ