I’ll bet that if you have worked with classic ASP for any extended period of time, you found yourself either downloading someone else’s COM-based SMTP component or writing your own to send e-mail messages. The native ASP scripting languages didn’t offer any way to send an e-mail from a server-side script.

But with ASP.NET, Web developers have full access to the .NET Framework libraries, which is a change for the better. Let’s take a look at the new built-in e-mail support in ASP.NET, and then look at a practical example: Sending yourself alerts of 404 errors on your site.

SMTP as simple as it gets
How simple is it now? If the server happens to be running an SMTP service, adding the ability to send e-mail programmatically is as simple as one line of code. Just call the static Send method of System.Web.Mail.SmtpMail and pass it four string arguments: the from address, the to address, the subject, and the message body, as below:
”My Subject Line”,
”My Message Body”);

What if your server isn’t running an SMTP service? Actually, it’s not that much harder to set up: You just need to add one line before the call to Send. Set the static SmtpServer property of System.Web.Mail.SmtpMail to an SMTP server you can use, as below:
System.Web.Mail.SmtpMail.SmtpServer = “mail.domain.com”;

Then call the Send method as I did in the previous example.

Too good to be true?
The SmtpMail class has two fairly significant shortcomings:

  • ·        You cannot use the class to send e-mail if the SMTP server requires authentication.
  • ·        SmtpMail is not a native .NET class; it is just a wrapper for the COM-based Collaboration Data Objects (CDO) API.

The latter problem is particularly disappointing; it would have been preferable to have the brains at Microsoft use their own .NET sockets classes to build a .NET SMTP class, much as Sun makes the platform-independent javax.mail package available for Java developers. However, these two limitations won’t affect the majority of you, since most SMTP servers do not have authentication activated, and since you are most likely running a Windows server that has CDO installed already.

Putting SmtpMail to use: 404 errors
A Web site owner’s goal should be to have no self-inflicted 404 Page Not Found errors, such as those caused by moving pages around after people have bookmarked them. I find these errors to be embarrassing enough that I want to know about them immediately rather than browse the server logs every so often and hunt for them. The sooner I hear about them, the more quickly I can fix them.

Of course not all these errors are self-inflicted; it’s entirely possible that a browsing user mistyped a URL, or is making guesses about where something might be. In this way, 404 errors can be instructive as they give a sense of what visitors are doing and expecting, yet another reason to keep track of them.

The 404Handler.aspx page
I’ve written a sample 404Handler.aspx page (see Listing A) that sends an e-mail alert, including the bad URL, when the page is loaded. First, I check the client browser’s user agent; if it’s a spider or crawler poking around causing 404 errors, I might not want to bother myself with an e-mail alert. The string returned by Request.UserAgent is searched for occurrences of the word spider or crawler. If these words are found, I assume a spider is causing the error, and the function exits without sending an e-mail alert.

Assuming the agent is not a spider/crawler, the entire Request.RawUrl string is included in the message body, and an alert e-mail is sent to admin@mysite.com from a dummy e-mail address (404@mysite.com). The Request.UrlReferrer is also included so I can see if the bad link is coming from another page on my site.

Trapping the errors
How you trap a 404 error is going to depend on how much control you have over your Web server. If you have access to the Web server, you can use the Internet Services Manager, view your site’s properties, and change the Custom Error Pages options to point to your alert-generating .aspx file.

If, on the other hand, your site is hosted, you probably have access to an HTML document—often named 404.htm—which you can customize so that your visitors do not get the standard, ugly 404 error pages. In this case, simply put in some client-side JavaScript code, like that found in Listing B.

The code performs a redirection to the 404Handler.aspx page and includes the originally requested and referrer URLs as part of the query string. These should be included as part of the redirect URL because the value of Request.UrlReferrer will be the 404.htm, which isn’t very useful. Since the 404Handler.aspx puts its entire URL into the e-mail alert, I’ll be able to see the original referrer by looking at the query string.

Parting shots about relative paths
A few warnings: If you are sending 404 occurrences directly to the 404Handler.aspx file, you should keep in mind that the virtual path will be the path requested in the bad URL. That can easily break relative references to things like style sheets and images in the HTML parts of your .aspx page. You may end up with a 404 page that has ugly, broken, image placeholders all over it.

With this in mind, it may be better (though slower and less direct) to use a redirection technique like my client-sideJavaScriptexample in Listing B. By redirecting the browser with client code, such as that shown below, you’ll avoid the potential problems posed by relative paths entirely.

What I’ve shown you isn’t the world’s most sophisticated way of tracking and alerting yourself of 404 errors, but it’s a fast, simple method that alerts you quickly, which gives you a chance to fix something right after it happens. Of course you aren’t limited to using SmtpMail just for 404 error alerts; you might think of a dozen other site occurrences that warrant a quick e-mail message to yourself or your administrator. With only one or two lines of code required for implementation, you know the capability is there and ready when you need it.