Email slaves

Things are better now, and not because the volume of incoming email has gone down - on the contrary it's more rampant than ever. No, what's happened is that the volume is so great that the CTO can't read it any more, so he/she now has a team called technical communications whose job it is to read the emails. They'll read each message, filter messages that can receive a standard reply and redirect others to the appropriate department. Only what's left after that goes to the CTO.

However, the overall volume of incoming mails is continuing to increase at what appears to be an exponential rate, and as a consequence so does the percentage that survives the corporate filtration process. Soon, the CTO will be back to spending all day reading emails again. What will happen then? A second team to re-filter the output from the first one?

What's needed is a technique to reduce the volume of incoming mails. There's one thing I need to make clear at this point - while it's okay to reduce the level of email, you should never attempt to stop it completely. Always provide a mechanism for people to communicate with you, otherwise you might miss out on that important email from Dell where it says it wants to bundle your software with every computer it sells. Or worse, you could miss an email from a customer who's experienced a bad service from your company.

It's important to divide email into three categories. First, there's genuine and useful business email. Second, there are requests for information and the like - the ones where you'd normally cut and paste a standard reply. Finally, there's spam, or unsolicited commercial email. Let's take them in reverse order by starting with spam.

Various anti-spam measures which you can incorporate into your email server and mail client software have been covered before, but what we can do here is give you a few hints to make your site less of a spam magnet.

The most common way for a spammer to find your email address is to detect it embedded within the HTML code of your Web site, where usually it will be found within a mailto: link (though it could equally exist as plain text, or even in a hidden field as with a typical form mail Perl script). What the spammers do is to use a 'leeches and spiders' technique to prowl the Web looking for these embedded email addresses.

Leeching is where the spammers piggyback onto existing search engines to look for information. For example, if they want to spam makers of ice cream, they might search for 'ice-cream manufacturer' through a search engine to find a list of likely corporate sites. The problem is that most search engines don't index HTML code, so they won't find email addresses embedded within tags. To get around this spammers bring out their pet spider - often custom written - and point it at the sites returned by the Web search, programmed to seek any pages called 'contacts' or even 'email' and try to find valid addresses on those pages. Find one and bingo, there's another spam victim.

So how can you keep these spiders and leeches from your door? The answer is never to show an email address on a Web page - rather than using a mailto: link, provide a Web-based form for visitors to contact your sales, support, HR or whatever department. This also has the advantage that it will always work, whereas mailto: links require a correctly-installed email client, and thus are prone to failure.

If you're hosted on a Unix box, you'll probably use a standard Perl form mailing script that looks like the following.

#!/usr/local/bin/perl
$mailprog = '/usr/lib/sendmail';
$recipient = 'info@mydomain.com';
use CGI;
$query = new CGI;
foreach $field ($query->param) {
  foreach $value ($query->param($field)) {
    $mail_content .= &Quot;$field: $value\n";
  }
}
open (MAIL, "|$mailprog $recipient") || die "Can't open $mailprog!\n";
print MAIL "From: $query->param('email')\n";
print MAIL "Subject: Form Submission\n\n";
print MAIL "The following information was submitted via a form.\n.";
print MAIL "$mail_content";
close (MAIL);

On an NT box running IIS, the equivalent code would be something like:

recipient = "info@mydomain.com"
for each f in request.form
for v = 1 to request.form(f).count
mail_content = f & ": " & request.form(f).v & vbCrLf
next
next
Set objMail = CreateObject("CDONTS.NewMail")
objMail.From = request.form("email")
objMail.To = recipient
objMail.Subject = "Form Submission"
objMail.Body = mail_content
response.write objMail.Send
Set objMail = Nothing

The important thing to note is that in both cases the recipient's email address is stored within the processing code, rather than being embedded within the HTML form. If you need a more generic email-handling script, capable of emailing several departments, it would be trivial to tokenise the supported addresses. Thus you might set a 'usage' field within the form to be sales or HR and then expand these to suitable email addresses within your script code.

Another trick that works well on some sites is to set up a 'spam magnet' on the front page - a hidden email address which normal users won't see (white text on a white background, for example), but which points to a black hole where all messages are deleted. The theory behind this is that the leeches and spiders' merchants will spot this on your front page and then go away, rather than scouring every dark recess of your site.

That's the spam dealt with, at least partially. So how can you reduce the volume of genuine email that a site generates? This really goes back to the role of the CTO's technical communications department. Part of its job was to filter those emails that can receive a standard reply, and the trick is to move some of this functionality to the Web site itself.

You'd start by including a fairly comprehensive FAQ section, but not forgetting that a great number of users simply can't or won't read FAQs, and will still email you with the most mundane of questions. What you need is a contact form that anticipates some of these questions, and you'll probably need to make it multilayered. The first level might sort out the buy/sell/information/contact queries, and then the next level might extract some detail from them about exactly what item they're asking for. Work out the structure for this process by chatting with whoever currently answers your general corporate emails - they'll know the common questions and can probably supply you with existing cut and paste replies.

Once your script has this information it will be able to provide the stock answers automatically, which you could either present as a Web page or email directly back to the user. If you want to try to hide the fact that these are machine-generated answers, you need to add a human touch. Reply to the question by email, but with a delay of anywhere between 30 minutes and a couple of hours. The email you send should appear to have come from a person, with its From: address pointing back to a real email account. It will look all the more believable if you personalise it.