Inbound spam to domain/email users

Inbound spam is the scourge of the modern internet and, the inconvenience to users aside, can cause serious performance and resource issues on the server. These can affect both the server overall and the timely deliver of clean email in particular.

The best way to tackle inbound spam is at the entry point into the server - the MTA, i.e. exim the SMTP server of choice for cPanel. By blocking spam before it has even entered the server you save both on server resources used when delivering the email in addition to 3rd party tools to help detect spam further along the email relay process.

To do this you need to do work at the RCPT stage of the SMTP protocol. This occurs during the transaction between the sender and recipient SMTP servers and comes before the actual body of an email arrives on a server. The primary form of spam attack is the Dictionary Attack:

A common technique for spammers to use is what is known as a dictionary attack on a domain. A dictionary attack, in our context, is a single SMTP connection that attempts to send email from a spam source to a random set of names on our domain, e.g. bob@ourdomain.com fred@ourdomain.com harry@ourdomain.com, in the hope that one of the many hundreds that we try will get a hit and deliver our spam.

This technique is used by spammers mainly because most people don't advertise their email addresses (due to spam!) and they want to access this untapped market.

To prevent this type of spam getting through, it is essential that you do not use the Default Address (catchall) feature within cPanel to receive emails wherever possible. You should always setup specific Forwarders (aliases) for any email addresses you use and set the Default Address to :fail: for each domain.

By using :fail: exim will automatically reject email at the SMTP RCPT stage and make dictionary attacks redundant. Additionally, you can use exim ACLs to block such spammers who repeatedly perform dictionary attacks to further relieve the server of the load from dealing with them

Another preventative measure is to enable the WHM options:

WHM > Exim Configuration Editor > Verify the existance of email senders.
WHM > Exim Configuration Editor > Use callouts to verify the existance of email senders.

These two options have exim check that any server that attempts to relay email to your server can actually receive email in reply. This is part of the RFC requirements of an SMTP server and the inability of a server to do so indicates a likely spammer.

There are numerous other checks that you can also perform at the SMTP RCPT stage in exim ACLs. Examples are using RBL checks to reject email from IP addresses that originate from IP addresses that are know to harbour spammers, e.g.:

deny message = Message rejected - $sender_fullhost is in an RBL, see $dnslist_text
!hosts = +relay_hosts
!authenticated = *
dnslists = bl.spamcop.net : sbl-xbl.spamhaus.org

You can also check the format of email headers to ensure that they're RFC compliant, which many spam servers are not. A typical example is checking the SMTP HELO/EHLO protocol command to ensure it's correctly structured, e.g.:

deny message = HELO/EHLO set to my IP address
condition = ${if match {$sender_helo_name}{11.22.33.44} {yes}{no}}

(where 11.22.33.44 is your servers main IP address)

deny message = EHLO/HELO does not contain a dotted address
condition = ${if match{$sender_helo_name}{\\.}{no}{yes}}

Finally, once the email has passed through these hoops, you can implement a 3rd party application to scan emails and tag them as likely spam. cPanel has an inbuilt solution that uses SpamAssassin to score email likely to be spam. You can then have such emails filtered to a special account or the client can filter such emails based on the email header record modifications made by SpamAssassin.

An alternative is to use a more thorough tool such as MailScanner which can be very effective at scoring spam emails.