ASP email handling

Here it is again:

Set objMail = CreateObject("CDONTS.NewMail")
objMail.From = "me@mydomain.com"
objMail.To = "you@yourdomain.com"
objMail.Subject = "Email from a Web page"
objMail.Body = "Blah blah blah..."
objMail.Send

This month however, we needed to use ASP code to read email rather than for sending it, and we can show you just how easy the email processing code is and suggest a few other applications.

The first thing you need to do is to make sure that you've got Microsoft's SMTP service installed, which you'll find as part of the NT 4 Option Pack. An important gotcha, which we've discovered through trial and error, is that this service really doesn't like to co-operate with any other SMTP servers on the same machine, even if you have them installed on different IP addresses: as far as port 25, the SMTP connection port, is concerned, this service wants the machine all to itself.

When you've completed the Option Pack installation you'll find that within your inetpub directory there will be a subdirectory called mailroot (assuming of course that you accepted the default paths and names during the setup process). Within this mailroot directory are various other subdirectories used for processing incoming and outgoing SMTP email: Pickup and Queue are used for the sending process, and Badmail is where anything that gets bounced by the remote server will end up. The directory we're interested in though is Drop, which is where any incoming emails will appear.

Before that can happen though there are a couple of things that you need to set up. First, you must announce to the great wide world that this server is now accepting SMTP email, and to do this you have to associate it with a domain name. This means adding one, or possibly two, records within your DNS system. The main one is an MX record - the bit that actually tells other servers where to send your incoming SMTP traffic. Let's say your domain is called flintstones. com, then its MX record would be of the form:

MX 10 mail.flintstones.com

MX marks this out as a mail exchange record, 10 is a priority (which we'll come back to in a moment) and mail.flintstones.com is the server with which you'll be accepting SMTP mail. Note that it's illegal to use an IP address as the machine name, so you need to set up a CNAME record such as:

mail A 194.70.234.203

So what was that priority all about? Well, think what would happen if your mail server went down for a while: most, but not all, of the sending servers would try for a few hours and then give up. Would you want all that email to be lost? Would you want your clients to see 'bounce' messages? Probably not. So what you can do is have one or more 'backup' mail servers that will accept this email for you and then forward it onward when your main server returns from the dead. It's sensible to have your mail backup handled off-site, either by your ISP or a corporate friend. All you have to do is list this next mail server with a lower (that is a higher number) priority:

MX 10 mail.flintstones.com
MX 20 maggie.simpsons.com

This now tells the outside world that you're accepting incoming emails addressed to anyone at flintstones.com, and that if the Flintstones aren't at home then drop the mail off at the Simpsons. The problem is that if you try this you'll find that it still isn't working, because you've forgotten to tell the server itself that it belongs to the Flintstones. The sending server will connect to your machine and say 'Do you accept SMTP email' and your server will say 'Sure'. Then the sender will say 'OK, I've got an email for fred@flintstones.com', at which point your server will say 'Bog off, he doesn't live here' and slam that big stone door shut.

To fix this you need to fire up the IIS Internet Service Manager, and below all of the usual FTP and WWW stuff you'll find Default SMTP Site: expand out its Domains section and you should find a Default Local entry with the name of your machine. Right-click Domains, select New Domains, choose Local, and then type in the name of your domain. At this stage it's probably wise to stop and restart the SMTP service, and then you'll be set and ready to go.

To see if it's all working, send a test email from somewhere outside your network to "anyone@yourdomain.com" and within a few minutes (possibly a few seconds) you should see a file appear in that Drop directory hanging off your mailroot. The filename will be a random looking number with an EML extension. If you have Outlook Express installed you'll be able to view this file by clicking on it: otherwise, just open it up in Notepad and you'll see that it's a perfectly normal email file.

Try sending email to lots of different addresses at yourdomain.com and you'll find them all together in this same folder. If there were just one of you this wouldn't be a problem and you could probably use the Drop directory as your inbox, but for most organisations this simply won't work, which is where you return to the ASP code. Take a look at the following:

Set objSession = CreateObject("CDONTS.Session")
objSession.LogonSMTP "fred", "fred@flintstones.com"
Set objInbox = objSession.Inbox
If objInbox.Messages.Count > 0 Then
  Set colMessages = objInbox.Messages
  For iLoop = 1 to colMessages.Count

    Set objMessage = colMessages(iLoop)
    from_name = objMessage.sender.name
    from_address = objMessage.sender.address
    when_sent = objMessage.TimeSent
    subject = objMessage.subject
    body = objMessage.text
    'now add some code to process/display messages
    objMessage.delete
  Next
End If

set objMessage = Nothing
Set colMessages = Nothing
Set objInbox = Nothing
objSession.Logoff
Set objSession = Nothing

You'll see that Microsoft's CDO (Collaborative Data Object) allows you to process this incoming email as a series of objects, and that it also takes care of message security. What the above code does is to read through the messages in the Drop directory and retrieve just those addressed to fred@ flintstones.com. You'd continue by processing each email (possibly to display it or to save it elsewhere on your server) and then delete the message from the Drop folder. There's one major failing with this code however, and that is it will ignore any attachments. However, take a look at the following:

Set collAtt = objMessage.Attachments
for i = 1 to collAtt.count
  set objAttach = collAtt.Item(i)
  objattach.writetofile(c:\mail\att\& collAtt.Item(i).name)
next
set collAtt = nothing
set objattach = nothing

Processing attachments really is that simple. Obviously this would need some major expansion to be useful in a live environment though.

Now you've seen how to process incoming email and attachments using ASP, you're possibly thinking 'So what, I could read my email using Outlook/Eudora/Ameol/, so why would I need this ASP/CDO stuff?' Well just suppose you could read your email from within Web pages - say if you're doing a world trip and relying on local cyber cafés for your contact with friends and loved ones (though to be honest it would be far easier to just get a Hotmail account) . To see the real use for this code you'd need to think laterally.

Imagine that you've set up a Web site for a client, and it wants to be able to add its own content to certain pages. Text is no problem as it can be typed into a form, but images can be more problematic. You probably don't want to give this client FTP access to the server in case it deletes the whole site by mistake and, besides, many corporate firewalls won't allow staff to make FTP connections. You could use one of the various file-upload components available, but these tend to be very browser-dependent and also pose a slight security risk. However, by using the techniques we've just shown you, you could easily produce a system that lets the client simply attach the image to an email message to 'images@corporatesite.com', and will be dropped automatically into the correct place within the site. They might even specify where to place the image by including the path within the message subject line.

In terms of security you could simply check the sender's name, but that isn't very robust. A better option is to agree on a codeword with the client, which sits within the body of the email: something based on a combination of words and numbers. This isn't industrial-strength security but it's enough to keep casual interlopers out. So there you have it: you're no longer limited to sending emails from your Web site, you can now send emails to it.