Qmail Listings on the CBL

Most CBL listings of Qmail result from one or more of the following issues:

• Generic rDNS
• Qmail naming
• Qmail "late bounce" issues.

Generic rDNS

See this link

Qmail naming

When installed, qmail seems to "freeze" the host name (fully qualified domain name, aka FQDN) that it knows itself by doing a DNS lookup on the IP that it thinks itself is.

If this name is generic (eg: dynamic.4.5.5.7.example.com), or the IP/DNS has changed since installation, the CBL _may_ detect the IP as behaving suspiciously.

The CBL expects real mail servers to name themselves in a non-generic fashion. To have a name like "mail.example.com", not simply be part of some large provider generic allocation pool. This helps differentiate themselves from the millions of machines in these pools that are in reality, end users on cable or dialup connections, and should NOT be running mailservers, and are infected with a piece of spam or virus emitting malware.

One way to check this out is to send an email to helocheck@cbl.abuseat.org. That will cause an immediate error (don't panic, it's supposed to), and the error message will tell you what the HELO was.

If the helo/ehlo appears generic (eg: 1.2.4.5.example.com) or isn't a fully qualified domain name (eg: localhost, localhost.localdomain, smtp, friend etc are NOT FQDNs), you will need to set the mail server's name properly.

How to fix Qmail naming

If you're running a MultiTech firewall filter (eg: "RouteFinder VPN"), or Plesk - both of which use qmail, or just "bare" qmail, check the file /var/qmail/control/helohost and /var/qmail/control/me (directory location may vary depending on operating system).

To be certain that things are set correctly, edit both the "me" and "localhost" files to have your mail server's fully qualified domain name. If localhost file doesn't exist, correcting the "me" setting should suffice on its own. Now restart qmail.

Update: the current version of the Multitech firewall appliance (eg: RF660) appears to reset the qmail configuration to this invalid state when it's rebooted. Contact Multitech for a fix.

Late bounces (also known as blowback)

One of the most difficult issues today in email is the issue of sender notification of email problems.

When a user misspells an email address, you want the mail server to tell the user that the address was wrong, so the user can fix it. Similarly, if a filter misfires on a valid message, you want the sender to find out so that they can fix it.

Doing this right has become an extremely important issue with email today. The reason is that every virus, and almost all spam forges the alleged sender of the email. Thus, unrestrained bouncing back to the alleged sender mailbombs innocent third parties. In fact, in some environments, bounce backs (due to "no such user" or naive virus/spam filters) causes more trouble than the real viruses do.

Mail servers can inform the sender of a rejection in one of two ways:

Perform an immediate reject _during_ the SMTP conversation from the sending mail server to the recipient's mail server. This is called "inline rejection".

Accept the email, then compose a new "bounce" email back to the alleged sender.

To understand the difference between the two, it's important to realize that almost all spam or virus emitting packages connect directly to the recipient's mail servers, but aren't real mail servers, and do not process SMTP rejection codes.

Thus in the former, the spamware/virus receives a rejection code, gives up on that recipient address, and goes on to try to spam/infect someone else.

In the latter, as far as the spamware/virus is concerned, the message has been received because the recipient's mail server accepted it. However, the recipient's mail server is busy making up a new email message to send back to the alleged sender of the virus/spam.

In short, accept-then-bounce is evil, and should not be done.

If your mail server does accept-then-bounce, then you are part of the problem not part of the solution.

In today's world, very few mail servers do accept-then-bounce.

One major offender was AOL.

When a high volume spammer hit AOL, the resulting blowback would quite literally blow smaller mail providers off the Internet for days at a time. We participated in discussions with AOL about this. They took VERY little convincing once they realized the magnitude of the problem. It was a major undertaking, but they did it.

AOL restructured their mail farms in 2004/2005 over a period of 18 months to eliminate blowback - after realizing that they were crushing other systems due to pure 'weight'.

The only popular mail server commonly available today that does accept-then-bounce is Qmail.

There is a rumor, apparently being spread by some Qmail enthusiasts) that accept-then-bounce is required by the RFCs (Internet SMTP standards, most notably RFC2821).

This is nonsense. At best, RFC2821 _permits_ accept-then-bounce, however, in today's Internet it is no longer tenable.

Qmail does late bounces for a very specific reason: since it was architected and implemented long before spam became a serious problem, Daniel J. Bernstein (DJB) implemented Qmail in a highly efficient, but inflexible way. Specifically: the SMTP listener does only one thing - accept email, and enqueues it. It's up to later processes in the pipeline to detect such things as non-existant users or spam and viruses.

Adding to the problem is that Qmail is essentially dead - there is no further development on the project as a whole, users of it are stuck with an old core, and lots of ad-hoc and sometimes conflicting patches.

In other words, an obsolete design, and no ongoing coordinated maintenance. This is probably not a good thing to base a business on.

Certainly, Qmail is fast. Blindingly fast. And it has its cadre of disciples. But this sacrifices many things - late bounce is not the only thing that causes other people problems with Qmail [eg: its propensity to create so many open connections to a given domain's mail server that it crashes].

Now - to what this means in practise: There are a number of DNSBLs that simply blacklist any IP that hit their spamtraps. The CBL is currently restricted to only listing "generic patterning HELOs" when it hits the CBL spamtrap. But in future, that will be broadened to the other CBL detectors on real mail servers. SpamCop, for example, will list on a single spamtrap hit. It would just take one spammer forging domains in the SpamCop trap to result in a continuous listing (denial of service) of your IP. There are other lesser known DNSBLs that also do that.

It's simply a matter of luck that the spammers hitting you don't have the spamcop's trap domain in their lists. Yet. It could happen any time.

So, regardless of the fact that the CBL should no longer detect your IP now that the HELO probably won't be generic, you have a severe risk of further blacklisting by other DNSBLs simply from the spam blowback problem.

The Canadian FASTF BCP discusses this in some detail. I was present in a MAAWG session (Mail Anti-Abuse Working Group, a consortium of email providers, ESPs and ISPs) where it was clear that BCPs will be forthcoming on this subject. [There is a IETF BCP on virus bouncing as well - in short, _don't_ bounce viruses under any circumstances.]

What should you do?

Ideally, you should upgrade to a modern well-behaved mail server. Since Qmail installations are UNIX/Linux, postfix, exim or sendmail are freely available, and each behave well in this regard. All of them have ample performance for almost all requirements, and are currently supported.

For example the postfix mailing list, is quite active and "official patches" are almost instantly available from the author of Postfix or other experts.

Switching mail server software may be difficult. In that case, we strongly recommend immediately requiring one of the Qmail patches (perhaps badrcptto) that will have the Qmail SMTP listener query for user existance in real time.

Furthermore, if you stick with a mail server that cannot do spam and virus filtering during initial SMTP conversation, and must do it after accepting the email, you must turn off any "bounce spam or virus" feature. This also applies to spam/virus appliances such as Barracuda that aren't on your SMTP perimeter.

Below, we've included a more general paper that spamshield (another DNSBL) answers similar issues with.

---

As far as we can see, you received this SpamShield notice due to "blowback" : accept, then bounce, because the mail is not deliverable for any reason:

unknown user

recognized spam/virus

secondary MX that has no view of valid usernames on a primary MX, but accepted mail for it: solutions for this problem exist (common LDAP database, full userdb exports, forward-SAV checks)

While technically compliant with RFC2821, accept&bounce is operationally not sustainable at this point - like open smtp relays (which are, hard to believe, RFC2821 (and 821) compliant!) - thus, while you may believe that your MTA is working "properly" - that's not at all the view of forgery victims (individuals and systems) everywhere.

Your MTA is, unwillingly, participating in a DDoS (distributed denial of service) attack: blowback has become DDoS a long time ago: See http://www.ricefowler.com/blowback.html for some disturbing numbers for a domain.

For some MTAs (like Postfix), blowback is a matter of configuration detail for single hosted domains (a problem with the catch-all handling, often under customer control), rather than for the entire server.

As applicable, please reconfigure your MTAs to reject in-line in any scenario, to stop DDoS'ing us and others: it may not