The CBL - Composite Blocking List

Linux/Unix/xBSD non-mail server software problems

With Perl's Net::SMTP module or any module using it, you'll want to insert a "hello" setting in the Net::SMTP->new() calls (it defaults to "localhost.localdomain"). Eg:

my $myname = 'mail.example.com';
my $smtp = Net::SMTP->new($destinationhost, Hello => $myname);

If you're using fetchmail: older versions of fetchmail (eg: 6.2.5) almost always use "localhost". The latest version (as of 2006/02/22 is 6.3.2) will use "localhost" if the gethostname() function fails. You should upgrade to the latest version, and make sure that hostname returns the fully qualified domain name of your machine. For 6.3.2 and later, if you have already followed the instructions in Linux/xBSD hostname repair fetchmail should be behaving properly.

Apparently the "MXLookup" plugin for SpamPal helos as localhost. Turn it off until you can get a fixed version. It is unknown as yet whether a fixed version is available.

The Perl CheckUser module defaults to improper "HELO" and "MAIL FROM" strings: "localhost.localdomain" and "check@user.com" respectively. The former is illegal, the latter impersonates user.com - they probably don't like that. [Besides, by not using your own domain, some spam filters will lie to your RCPT TO.]

You will need to change $Helo_Domain = to be "<DNS name of your server>" and change $Sender_Addr to be something in _your_ domain (eg: "check@<mydomain>")

If you are running the "Voltage SecureMail" appliance/gateway (voltage.com), it has some issues with its default configuration. Contact the vendor for instructions on how to fix it.

It's not one of the above, now what?

There are many many possibilities. Many more that even we haven't run across before. Just because we don't enumerate a software package that you could possibly be running doesn't mean that the listing was in error. Just that we've not been able to describe it completely yet.

  1. Email Autoresponders that don't use the right name.
  2. Email address verifiers (many of the developers of these things should be taken out and shot).
  3. Sendmail's "milter-sender" has been known to issue "localhost" if there are DNS issues. The latest versions permit you to hardcode your machine name.
  4. Mamba (PHP application) is subject to "malicious code drop", which can lead to rootkits/spambots being installed and operating. Check for unknown running processes, and suspicious directories under /tmp, especially those starting with ".". Scanning web server logs for "tar.Z" will often find the attempts.
  5. PHPNuke (PHP application) is subject to a variety of issues, including open proxy. Make sure you're running the latest version, and check out all of the CERT advisories.
  6. Other web-based mail sending mechanisms/scripts, even such things as account existance verifiers (eg: Perl's CheckUser).
  7. Net::SMTP defaults to a bad HELO.
  8. YaBB (perl Bulletin board package) apparently is an unrestricted open (and non-closeable) proxy. The only effective approach is to remove it utterly. Look for and remove "yabb" directories under "cgi-bin" directories. Especially user-installed. [This is usually installed by a spammer who has obtained hosting service from you, and uploaded this software. You should be able to see them spewing in the web server logs.]
  9. SSH brute force password guessing attacks, leading to being rootkitted. Look for modified system binaries (especially ps, sh, login), and suspicious running processes or logins. Check SSH logs (often /var/log/auth.log) for runs of password guessing attacks. If you're rootkitted, perhaps the safest approach is to reformat the disk and reinstall the operating system - an effective "rootkit" has buried the backdoors so completely, you have no way of trusting even basic programs such as "ls" or "cat". Then secure your SSH passwords better.
  10. SMTP AUTH/POP compromises, eg: weak passwords. Look for unusual numbers of SMTP or POP authentications.