Download (direct link):
Top Sendmail Problems (And Solutions)
As with most client/server setups, mail experts see the same problems on a regular basis. With over 10,000 servers on line, Rackspace Managed Hosting sees a lot of Sendmail issues, and as a result has identified these as some of their top problems. Luckily for you, they've also supplied the solutions!
Dealing with Spam
Though spam itself isn't a Sendmail or PostFix problem, it's certainly an issue. Fedora Core includes the popular tool SpamAssassin, which many mail administrators have chosen to implement. SpamAssassin's not perfect, but with a 99%+ spam rejection rate, it certainly cuts down on the flood of unsolicited e-mail that cloaks the legitimate messages coming through your system.
Learn more about SpamAssassin through the documentation on your system with the command more /usr/share/doc/spamassassin-2.60/README, spamd.
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 asformmail.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.
Note Many mail server administrators use blacklists from spamcop.org or mail-abuse.org, or the open relay checker at ordb.org, to block incoming mail from IP addresses on such lists. If your IP is on one of these lists, then your users may not be able to successfully send e-mail to others on the Internet from your system. This makes you feel bad. You should occasionally check these lists to see if any of your servers or IP ranges are listed to stop such blacklisting problems from blindsiding you and reducing your organization's productivity.
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.lP>
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 Flat/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 Flat/Fedora-based systems, with:
# service iptables save
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]