As any sysadmin responsible for mail systems will know, sometimes email gets relayed that shouldn’t. In this post, we will walk through the process of dealing with a SPAM email abuse report. It’s key to ensure these are dealt with in a timely manor as it will effect the SMTP servers reputation and therefore its ability to send email.
Contents
The initial report
There are a number of ways you may notice SPAM email abuse, however in this case abuse has been reported to us from an external source (eg: Anti-SPAM vendor or ISP).
Track the source
First of all, we need to track the source of the SPAM messages. Normally you would see all the mail servers in the message headers, with the newest entries appended to the top. This allows you to work back through the mail flow to trace the source server. In this example, all internal mail server headers have been stripped off by the external gateway before finally leaving the sending domains control. While this may seem strange, it prevents external parties from identifying DNS host names, IP addresses and software versions of internal mail servers.
In this example we will track the message through Exchange 2010’s built in Message Flow Troubleshooting. In the event your using another mail server, the principle is the same but you will need to use the relevant tools. Eg: for Exim take a look at /var/log/exim/mail.log.
You will see from the above, we are able to trace both the receive as the message comes to Exchange from the server, and then the send as it leaves to head for the externally facing mail gateway. This allows identification of the source server and will also provide a good indication of how big the issue is, including how long this has been happening, how many messages have been sent, who they have gone to and so on.
Now we have confirmed the initial report as true, and tracked this to a WWW server we will investigate further. Once on the affected server we find that SMTP server logging is disabled, we already have what we need, but will enable that to assist with future diagnostics. Simply tick the box and ensure you set an appropriate limit and rotation for your environment on the log file.
Contain the issue
Now the server has been identified, contain the flow of mail by stopping the affected SMTP service and verify there is no more email leaving the mail infrastructure.
Identify the vulnerability
By examining the content of the email message reported as SPAM, and looking at the sites hosted by the server in question, identify the vulnerability. In this case, its a web form that allows a website user to email a 3rd party, with no CAPTCHA or authentication protection. This box also allows more than one ‘friends’ address to be allowed, up to around 200 in fact, simply by comma separating entries.
Repair the fallout
Once the web form has been repaired or removed, you will need to perform a number of remedial tasks.
First off, clear any SPAM messages from the queues on all your mail servers, eg: application server, mail relay and external gateway.
For Exim servers, please see my earlier post: Delete mail from an exim mail queue
Next, check the damaged reputation of the domain name, DNS host entry of the mail gateway, and IP address of the mail gateway.
Tools such as DNSstuff & SenderBase are a great help here. Do a quick search for email blacklists and double check to see if your listed.
If the IP/domain is on any lists, follow the process for requesting removal.
Lastly, restart any email services that were halted during the initial phases of the investigation. You should also run a series of checks to ensure there is nothing further wrong with the environment.
Helpful Resources
