Blacklisted IP Address

If you have a spammer on your system or you have allowed your system to be used as an open mail relay, you may find that your IP address has been blacklisted by an antispam organization. Note that being tagged as an open relay by entities such as www.ordb.org does not always mean that your SMTP daemon is open to the external world. Sometimes, things such as mail scripts on web servers have been identified as a possible opening for SMTP relaying abuse, such as formmail.pl. Just having such a file on your system can soil your reputation and brand you as an open relay or spam source. Several Rackspace techs use this quick check to quickly scan a system for this common-though vulnerable-web CGI file:

   # find / -name "formmail*" -print 2>/dev/null

This scan may take a couple of minutes, but if this finds any instances of the formmail file, you can see whose file it is, remove it, and let them know that they cannot install that web CGI on your system for security reasons.

Being blacklisted will cause a lot of e-mail bounces, delivered with various error messages, which can increase the traffic load on your server significantly.

Do you have a web user who has done something like upload a formmail script and has gotten you blacklisted? Maybe you have a regular user who just decided to try his or her hand at sending out spam from your system for some extra cash. Obviously, the first step to resolving this type of problem is to get rid of your spammer or problem web user, or to shut down the open relay if there is one. Next, you need to talk to your upstream provider; both of you should contact the blacklisting organization and ask them to release your IP from the blacklist after you've provided proof that the issue is resolved. However, this appeal process can often take days, or even weeks. A stopgap solution used by Jorge Arrietta, a Support Sys-Admin and RHCE at Rackspace Managed Hosting, involves redirecting your outgoing e-mail through an additional IP address using iptables. This is a good way to keep your critical mail flowing while your blacklist appeal process is pending. To do this, follow these steps:

1. Add a new IP address to your server that is not blacklisted.

2. Modify your MTA's configuration to send SMTP traffic over the new IP address, rather than the one that's blacklisted.

   While you can do this in your MTA's configuration files, it's easier to define a new outgoing SMTP rule with iptables on Linux. Use this command (replacing <new.IP> with the new IP address):

   # iptables -t nat -A POSTROUTING -p tcp --dport 25
   -j SNAT--to-source <new.IP>
   

   We recommend that you use iptables because you don't need to make permanent changes to your MTA configuration files. When the blacklist problem is fixed, you can flush the tables with ptables -F or /etc/init.d/iptables restart and return to normal.

If resolving the blacklist issue is taking longer than you expected and you need to reboot the system, you need to save the new setting to /etc/sysconfig/iptables. Before you do this, however, back up your current boot-time iptables settings with the command (on Red Hat/Fedora-based systems):

   # cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables-BAK

Make any iptables changes you want, and then save the currently running iptables settings into your boot-time settings with the command:

   # iptables-save > /etc/sysconfig/iptables

or, on Red Hat/Fedora-based systems, with:

   # service iptables save
   Saving firewall rules to /etc/sysconfig/iptables:   [ OK ]

Mail Server Misconfiguration

AOL, Yahoo!Mail, HotMail, and other popular webmail hosts and ISPs have begun to bounce more and more of their incoming messages back to the originating domain. These messages are bounced for a number of reasons. If the bounce messages claim that your mail server is misconfigured, it may be due to a new method of detecting spam sources. Many service providers now use tools such as nslookup and dig to check the DNS entries of sites attempting to send mail to their users. If the forward and reverse DNS entries do not match, the message is sometimes rejected as potential spam.

For example, assume that the result of the command

   $ nslookup yourdomain.org

is 10.1.1.2. The result of nslookup 10.1.1.2 should then be yourdomain.org in order to match. However, if the result of nslookup 10.1.1.2 is something like www.yourdomain.org or mail.yourdomain.org, or the command returns nothing at all, there is a good chance that your outgoing e-mail will be rejected.

To resolve this problem, configure your DNS servers to return matching information for both forward and reverse DNS checks.

Mail Bounces Due to Dynamic IP Configuration

Another reason for the mail bounces described in the previous problem may be that your IP address is dynamic, rather than static, as with most dial-up, cable modem, and ADSL-based home or SOHO Internet connections. Spammers often try to spam through home broadband on dynamic IP addresses as their IP will eventually change, so this allows them to stay one step ahead of the blacklisters. As a result, big providers such as AOL and others just reject e-mail that is relayed directly from a dial-up or broadband dynamic IP range, but will usually accept mail from that provider's legitimate mail server(s). This is a particular problem when sending e-mail to AOL customers, as AOL enforces strict rules on source IP ranges as well as forward and reverse DNS checks.

For example, assume that a user is sending mail from a home office mail server connected to the Internet through a cable modem using the DHCP-assigned IP address 66.69.100.144. A reverse lookup on this IP may fail, or it might return a value such as cs6669199-144.satx.rr.com, which indicates a home user or a block of IPs known to be assigned dynamically. Since the address cannot be linked to an identifiable person or a machine without administrative-and in some cases legal-involvement, the message is therefore rejected.

The fix here? Never run a mail server on a dynamic IP address. We assume that those reading this book are able to use permanent or static IP addresses for their e-mail servers. If not, at least look into your provider's business offerings, which may offer some type of reprieve from this low-end connectivity. This problem is generally one that affects home users rather than administrators, but it's good to know why it happens. If you find that your office is actually on a noncommercial ADSL dynamic IP and is having this type of problem, at least now you can explain to your users (and your cheap boss) why all company e-mail is being bounced.