Reducing Spam for Publicly Disclosed Email Accounts

Written by Paul Cunningham on May 7, 2009

inboxSometimes it seems as though a lot of effort is put into hiding email addresses, keeping them private, and screening them heavily for any trace of spam or unwanted email.  Of course at the end of the day email is an important business communication channel and needs to be open and usable to provide any value to an organisation.

While Bob in Accounting has few dealings with people outside of the business and doesn’t mind a strong spam filter protecting his email account, there is a good chance that Helen in Sales doesn’t feel the same way.  The sales team wants to receive new opportunities via email without the risk that a spam filter will block a message and lose them a valuable lead.

Oftentimes this means that an email address is publicly advertised on websites and marketing literature so that sales enquiries can be received.  Something nice and generic like sales[at]contoso.com is used, and the Sales team asks the email administrator to make sure no genuine enquiries are blocked.Although most spam filtering methods such as connection filtering are not likely to block a genuine sales enquiry there is a greater chance that content filtering will.  To avoid this possibility some organisations I’ve dealt with have simply excluded their publicly promoted email addresses from any kind of filtering.

This approach certainly achieves its goal – no genuine sales enquiry will be rejected as long as emails to sales[at]contoso.com are never checked for spam.  Of course the trouble with this is that since it is a publicly disclosed email address it is more likely to attract spam.  Spammers will simply harvest the address off the company website and start bombarding it with junk emails. The problem now becomes sorting out the genuine enquiries from the spam.  To solve this problem an organisation needs to take a different approach to offering email contact to the public at large.

One approach is to make use of email obfuscation anywhere that an email address is being displayed on the company website.  Email obfuscation uses server-side code on the web server to conceal email addresses from spam harvesters while still making them accessible for regular visitors.  It is an effective approach but requires coding to be used anywhere an email address is going to be displayed.

Another approach is to use a contact form instead of displaying an email address.  A contact form gives a visitor a preset series of fields (such as name, email address, phone number, and a space to write their question or request) to fill out, and the web server then sends the enquiry on to an email address within the company.  Because the receiving email address is not displayed anywhere on the form it is safe from harvesting by spammers.

However, contact forms themselves can also be exploited by spammers.  If the form is coded in an insecure manner it could be used to send spam to the company, or to other recipients on the web, or even to send viruses in file attachments.  To avoid these issues the form developer must use techniques such as input validation and CAPTCHAs to prevent exploitation.

Provided that the contact form is securely coded this method has the opportunity of allowing an email administrator to simply trust all emails originating from the web server’s IP address.  The risk then becomes preventing the web server itself from being exploited as an open relay.

As you can see preventing spam to publicly disclosed accounts is not a simple undertaking.  The best approach in my opinion is to use contact forms that send to an undisclosed email address, and to subject that email address to the same anti-spam filtering as all other email communications.  To reduce the likelihood of genuine enquiries being lost I recommend either using an anti-spam product that has easy to use end-user quarantine management, or alternatively configure the anti-spam product to only tag suspected items instead of blocking them entirely so that the end user can sort likely spam from genuine emails with greater ease.

About Paul Cunningham

Paul lives in Brisbane, Australia and works as a technical consultant for a national IT services provider, specialising in Microsoft Exchange Server and related messaging systems.
  • (required)
  • (required)