Nowadays many companies and organizations (non-profits, units of governmental and educational institutions, etc) believe that running their own mail servers has become an impossible task, due both to the large amount of inbound spam and to the continuous attempts by spammers to send outbound spam through their mail servers. Companies often lack in-house technical resources to configure and run a mail server properly and deal with these threats. For these reasons, many organizations decide to outsource their email service to external entities.

However, outsourcing does not come without costs, even when the outsourced service appears to be "free". Hidden costs include:

• Another organization can see the content of all messages. In some cases, the contents of messages are stored on the outsourcing company's servers indefinitely. External access to unencrypted emails poses privacy and confidentiality issues. Furthermore, the outsourcing company may be located in another country and be subjected to different regulations and obligations.

• In some cases, the outsourcing company's terms and conditions allow it to search the content of emails to aid in targeting advertising, which poses even greater privacy and confidentiality problems.

• The organization no longer has control of its own email security. Server-based encryption and authentication is managed by the outsourcing company, requiring end-to-end encryption for sensitive communications.

• Large companies with many customers are often a target of cybercrime attacks aimed at stealing customer data, and some of these attacks have succeeded.

• Inspection of SMTP transaction logs may be impossible for the end user. Troubleshooting failed deliveries and other email problems requires interacting with an external support desk. Support desks are sometimes slow to respond. First-line support, in particular, might lack the training and access to fix any but simple problems, requiring escalation and further delays.

• Sharing a mail server with other organizations can cause delivery issues when a user at another organization sends spam through that mail server. When the outsourcing company fails to detect and block spam, or is slow to terminate service to spammers, the likelihood of problems increases substantially.

These disadvantages are important. For small organizations that need reliable, confidential email systems, the choice of whether to outsource or not can be a tough one.

Running a secure, spam-filtered mail server for a small organization is not terribly difficult, if these guidelines are followed:

• Choose a good ISP or hosting provider
• Reject as much inbound spam as possible
• Prevent outbound spam
• Monitor the logs!

In the remainder of this article we discuss each of these points in turn.

Unfortunately people and companies rarely consider how an ISP or hosting provider handles spam and abuse issues when choosing what company to use for Internet service or to host a server. ISPs vary tremendously in how well they keep under control spam and abuse on their network. When you manage your own mail server, it is critically important that your ISP does not allow spam and abuse to flourish on its network. If it does, then you may encounter delivery issues when sending email. Your servers might also come under increased numbers of hacking attacks because many hackers concentrate their efforts on networks that lack effective spam and abuse policies or a properly-staffed and competent abuse department. Furthermore, if a security hole has allowed your server to become a vehicle of abuse, you would really appreciate your ISP to notify you in a professional and timely way rather than ignore the issue.

To verify that an ISP or hosting company is properly handling spam and abuse on its network, you can use use a number of resources to check the reputation of its IPs and domains, and determine how well it responds to abuse reports sent to its RFC-mandated abuse contact email address.

First, you can check the CBL Statistics by Domain list to see if the ISP is on it, and if so at what ranking. A small or medium-sized ISP or web host should not appear on this list. A large ISP or web host should not be highly ranked if it does appear. A high ranking indicates that the ISP sends a great deal of spam from malware-infected servers, or hosts malware on its servers that can infect other computers. An ISP whose networks do not appear or are not highly ranked usually has sufficient abuse management resources and good practices, enabling it to detect compromised servers and end-user computers. Such ISPs also act quickly to notify infected users, fixing problems rather than allowing them to linger.

Second, the SBL has two resources for vetting an ISP or host. You can check the SBL's World's Worst Spam Support ISPs page to see if the ISP is listed. If it is, avoid it. An ISP that appears on this list is either ignoring spam and abuse on its network or is actively complicit. If the ISP does not appear on the list of worst spam supporters, check for open SBL listings within the ISP's IPs by opening the following URL, substituting the ISP's domain name for "example.com":

http://www.spamhaus.org/sbl/listings/example.com

Some ISPs use multiple domain names. In most cases the Spamhaus database will automatically redirect the search to the correct domain name, and display the SBL listings for that ISP. Only top-level networks show up in the SBL; ISPs that obtain their IPs from another ISP or network service provider (NSP) usually do not appear under their own names. If you can't find an ISP that you are considering, before you assume that they run a clean network, you should try searching for the domain name of their upstream provider or upstream providers.

The results page for this type of search displays a short synopsis of all active SBL listings assigned to that ISP with their creation dates. A large ISP often will have a few listings, but even large ISPs should have only a few SBLs, and the listing dates should be recent (within the past week or two at most). You might also see a few informational SBL listings: listings for a single IP that ends with ".0/32". Don't ignore these SBLs just because they do not block active IPs. Informational SBLs document real problems on IPs that Spamhaus is not listing outright to prevent large numbers of false positives. They are not less serious than other SBLs.

If an ISP has more than a few SBL listings, or has SBL listings that are weeks or months old, then you can usually conclude that the ISP is not effectively preventing and managing abuse on its networks.

Third, you can check the following recommended third-party resources to find out whether a specified IP or domain is listed in public blocklists (ours and others) and to assess the reputation of a specified IP range or domain:

• MX Toolbox Blacklist Check. Check IPs and domains to see if they are listed in blocklists (Spamhaus and many others).
• SenderBase. Check IPs and IP ranges for overall reputation.
• SenderScore. Check IPs and domains for overall reputation.

Finally, you should test the abuse contact email address (the "abuse@" email address at the ISP's domain) to see whether it exists and whether you receive a timely response. You can do this by sending email to that email address asking a question about an abuse-related issue. For example, you could ask what resources the host has in place to help customers whose servers are hacked or compromised. If the ISP fails to answer the email within a few days, or if the message is rejected for any reason, they may also ignore other email to their abuse contact. If the ISP answers, that should be definitely taken as a good sign.

Remember that, in addition to accepting spam and abuse complaints, the abuse team at an ISP should take proactive measures to ensure that it finds out about any spam or abuse on its network and can take quick action to stop it. A good ISP abuse team subscribes to feedback loops -- automated near-real-time spam reports offered by a number of large ISPs and anti-abuse organizations. A good ISP abuse team also configures its network to discourage spam, watches its network for signs that an IP or server is sending more email than it should or receiving high levels of traffic to unexpected web URLs or unexpected ports. An abuse team is expected to handle spam complaints and abuse reports, and supervise issues until they are resolved.

For example, if a server at an IP address on the ISP's network is infected by spam-sending malware, an abuse desk should see the spike in traffic from that server. If the spam is sent to a large ISPs that offers a feedback loop, or to honeypot email addresses owned by a reputation service, the abuse desk should notice the increased spam in the feedback loops that it subscribes to. A power user (such as somebody who runs their own mail server) might also report the spam to the ISP abuse contact. Because of these and other resources, the ISP abuse team should be aware of the situation and able to shut down the infected server quickly to prevent further spam and further risk to innocent users until the server is secured.

Look with suspicion at ISPs whose abuse issues are handled by the same team that handles ordinary customer support issues. Effective management of abuse requires a different skill set than customer support. The goal of a customer support representative is to resolve problems that the customer has with the service. The goal of an abuse team is to resolve problems that the customer is causing to the community. Because of the different and possibly even conflicting focus of the two teams, abuse and customer support functions should be separate even at a small ISP. A medium-sized or large ISP should have a completely independent team responsible for security and abuse. This team should work in close contact with administration and sales, and be able to terminate abusive customers and prevent repeated signups of such people.

Consider changing your ISP if your current ISP does not appear handle abuse and security issues properly. You do not want to find your email blocked because your ISP tolerates spam and abuse on the same network that you use. Like driving a car without insurance, ignoring abuse issues appears cheaper initially, but can prove to be extremely expensive in the long run.

The Spamhaus Project offers several IP address and domain databases that, if properly used, lower the amount of inbound spam reaching mailboxes to a very low level, without blocking any significant amount of legitimate mails. If mail volumes are not very high (see the usage terms), these databases can be freely used.

It is, however, very important that they are used properly. This boils down to:

• Using the IP-based SBL, XBL and PBL databases at the SMTP connection level against the source IP address initiating the connection (this is the DNSBL normal usage);

• Using the domain-based DBL database at the SMTP level, ideally checking three things: the sender domain (MAIL FROM), the name of the connecting server according to HELO and the name of the connecting server according to reverse DNS. One should choose a mail server software that supports these checks;

• Have software linked to the mail server that does a further analysis of the mail contents (both headers and body), looking for IP addresses and domains appeared in Received lines and in the body as URLs and checking them against the SBL, XBL and DBL databases. Quite often, the results of these checks are combined with other checks to build a "spam score" for the message which is then used to decide whether to deliver the message in the normal user mailbox, or in a separate folder, or to throw it away altogether.

All these three components should be considered as absolutely necessary. No new installation should be made without these three components in place.

See also: Effective spam filtering.

Emission of spam is caused by either a person or unit within the organization that decides to send spam, or by a security problem that allows other people to send spam from your IP address. The first case does not have a technical solution, however, all employees working in marketing should be fully aware that all the email addresses used for bulk mailings should have specifically requested to receive emails about your products or services through a confirmed opt-in procedure (for further informations see our mailing lists page and the Marketing FAQs). In this note we want to address the second case, which is far more common.

The overwhelming majority of spam caused by security problems falls into one of the following four categories (that sometimes partially overlap):

1. Malware trojans & viruses
Malware programs are downloaded on computers using a variety of tricks and are then used by criminals for various nefarious tasks. Sending spam is just one of them.
While scanning the machines using antiviruses is always a good thing, nowadays a lot of malware manages to escape detection by constantly changing. The best thing to do is to set up things so that they are simply unable to send mail outside thanks to firewalling. Our CBL FAQs give several suggestions in this direction, giving a special attention to the case where NAT is used and trojans may have a direct negative impact on your legitimate mail flow. Basically you should not allow any machine which is not the mail server to initiate SMTP connections (port 25 as the destination) toward external hosts. Only the mail server should be able to send mail. This measure will make trojans that bypass the mail server simply ineffective.


2. Open relay
Your mail system should not behave as an open relay, that is, allowing anyone in the world to connect to the server and send mail to anyone in the world. We have recently published The return of the open relays dedicated to this problem. The main issue discussed in this article is that today's firewalls and other protection boxes are often responsible for open relay setups, rather than the mail server itself. But testing for an open relay is extremely easy and should always be done, every time the mail system configuration is modified. If the test is passed, you do not have this problem.


3. Compromised accounts
A very common reason for the emission of spam from your mail server is the existence of passwords that are known to spammers, either by guessing, phishing or malware spying. Spam through compromised passwords: can it be stopped? is an article dedicated to this problem. Keep the strength of your users' passwords under control, and make sure that your server writes the account name in the logs whenever a mail is sent using SMTP AUTH authentication (unfortunately, some mail server software products do not do this using the default configuration). It also helps to have the account information in the headers of outbound messages.
If your mail server allows it, define per-user limits in the amount of mails that can be sent using authentication in a certain amount of time.
Besides mail servers, all the devices in your LAN (including routers) should not have accounts with the default or a very simple password, independently from the protocol they use (telnet, ftp, ssh, etc): any unauthorized login is a potential source of abuse.


4. Compromised web servers
Many security problems resulting in emission of spam occur on the web space. If abusers have the capability of uploading web pages without authorization on a web server, they can upload abusive contents they advertise using spam, but they can also upload, say, PHP scripts that act as mail cannons but are driven through HTTP commands. Sometimes malicious files are uploaded using FTP and compromised passwords, making the issue similar to the one discussed in the previous paragraph.
Again, keeping good security of web applications and user passwords should help to prevent this occurrence. The article Stop spammers from exploiting your webserver! discusses the main issues related with the web server security. The real winner is to make it impossible for the web server to send mail directly, forcing all outgoing mail generated by web applications to pass through a SMTP wrapper using authentication and writing relevant injection informations into the message headers.

Spend a small fraction of your time, or set up automated mechanisms based for instance on email counts and fraction of undelivered messages, to keep your mail server monitored. Discovering a problem and taking corrective actions quickly and before the IP address or domain reputation starts to deteriorate may actually save you time and decrease the impact of an incident on your normal mail flow.

Do not forget that spam sent through a web server will leave traces in the web server logs rather than the mail server logs, and that spam sent by malware normally bypasses the mail server and leaves no traces in any logs.

We believe that an in-house mail server remains a viable solution for small organizations, and it should be the preferred one when privacy/confidentiality issues are considered important. While it remains true that there must be a system administrator knowledgeable in operating the mail system, this task should not be considered overwhelming once the points above are given consideration. All considered, running your own mail server may turn out to be a very good investment.