Stopping Outgoing Spam

Stopping incoming spam is largely a matter of configuring your mail server and ancillary programs to detect spam and block it. Stopping outgoing spam presents a different set of challenges. In principle, you could apply tests similar to those used to detect incoming spam to messages your server relays for authorized hosts, or to mail that originates on the server itself. In fact, large ISPs may employ such tests. Most smaller sites, though, use two methods to minimize the risk that they'll become spam sources:

Clearly Stating Acceptable Use Policies The first step in preventing your system from becoming a spam source is to clearly articulate an acceptable use policy (AUP) and to ensure that all of your users understand this policy. On a very small network, such as a home network, this task can be done informally. For most business sites, it's best done through a formal document of some sort. Users must understand that any mail sent to more than a handful of recipients is suspect. (Of course, not all mass e-mail is spam; true opt-in newsletters, mailing lists, and so on are not spam. Unfortunately, many spams claim to be these legitimate forms of mass e-mail, which muddies the waters.) Your policy should state what action will be taken in case of an AUP violation.

Anti-Relay Configurations One source of spam is hijacked mail servers. Spammers frequently look for open relays, which they can use to send mail to any recipient. Spammers do this because they can rely on the open relay to do most of the work, limiting their connect times and keeping their own ISPs' mail servers out of the loop, minimizing the chance that they'll be caught before their spam run is complete. The preceding sections, "Running Sendmail," "Running Postfix," and "Running Exim," all described relay configurations. You should use as limited a relay configuration as your system can manage. For workstations, this means that the system should relay only local e-mail.

For most small networks' mail servers, the system should be configured to relay only the local network's mail.

Many websites offer advice on helping you keep your mail server from becoming a source of spam. One of the best of these is the Mail Abuse Prevention System (MAPS) Transport Security Initiative (TSI) site, http://mail-abuse.org/tsi/. One helpful test you can perform is a third-party relay test of your system. MAPS operates an automated relay test. To use it, type telnet relay-test.mail-abuse.org from the system you want to test. Initiating a Telnet connection in this way causes the MAPS server to perform a series of relay tests on your mail server. You'll see them run in your Telnet session, followed by a summary of any problems found. The MAPS TSI website also provides advice on securing a variety of mail servers.

If you become a spam source, chances are you'll hear complaints quickly enough. Correct the problem immediately. If necessary, take your mail server offline while you fix the server. Note, though, that a complaint doesn't necessarily mean your system is really to blame. Most spammers routinely forge their return addresses, and some deliberately or accidentally pick valid hostnames as return addresses. Recipients who don't look at the mail headers, or who don't know how to interpret them, may complain to the forged return address.

If you find that mail from your site is bouncing because your system is on a blackhole list, investigate further. It's possible that your system is an open relay or one of your users has been abusing your server. It's also possible that your server's IP address used to belong to a spammer. In this case, contacting the blackhole list maintainer should result in quick removal from the list, clearing up problems. A few blackhole lists don't contain actual spammer IP addresses, but just addresses that the list maintainers believe shouldn't be sending mail directly. The largest such class of addresses is those assigned by ISPs to end users, typically as dial-up IP addresses for Point-to-Point Protocol (PPP) connections. The reasoning is that end users should relay mail through their ISPs' own mail servers, which should not appear on blackhole lists. If you're using such an account, the easiest solution is to configure your mail server to relay through your ISP's mail server. Of course, if your ISP's mail server is unreliable or appears on another blackhole list, you have a problem. This problem's roots, though, are firmly planted in your ISP's soil, so the best solution may be to change to another ISP.

Team LIB

Team LIB

^ previous

0 0

Post a comment