Fight Spam with Qmail/SPAMCONTROL

This page provides information about my personal settings, how I fight spam with Qmail 1.03/SPAMCONTROL 2.5.x.

My current email situation can be viewed here. You find the following MRTG diagrams created with my qmail-mrtg and organized in the following table:

• qmail-send: This is the standard qmail-send MRTG output.
• qmail-smtpd (totals): All attempts to reach the qmail-smtpd instance on mail.fehcom.net via SMTP.
• qmail-smtpd (rejected): All emails, which have been rejected due to various reasons.

My tcpserver/sslserver settings

First, I have set up qmail-smtpd by means of SuperScript's sslserver and enable authentication thru Bruce Guenter's checkvpw:

#!/bin/sh
QMAILDUID=`id -u qmaild`
QMAILDGID=`id -g qmaild`
HOSTNAME="mail.fehcom.net"
export SMTPAUTH=""
export UCSPITLS=""
. /var/qmail/ssl/env
exec softlimit -m 180000000 \
sslserver -sevn -Rp -l $HOSTNAME -c 20 \
-x /var/qmail/etc/tcpd.smtpd.cdb \
-u $QMAILDUID -g $QMAILDGID 0 smtp \
/var/qmail/bin/qmail-smtpd /usr/local/bin/checkvpw true maildir 2>&1

My tcpd.smtpd rule base

The tcpd.smtpd rule base work independently, whether tcpserver or sslserver is used. The following (essential) ingredients are defined:

127.0.0.1:allow,RELAYCLIENT=""
=stoneport.math.uic.edu:allow,BADMIMETYPE="",BADLOADERTYPE="M",QHPSI="clamdscan"
=:allow,MFDNSCHECK="",HELOCHECK="A",BADMIMETYPE="!",BADLOADERTYPE="M",QHPSI="clamdscan",\
QMAILQUEUE="/var/qmail/bin/qmail-queue.scan",GREETDELAY="80"TARPITCOUNT="3"TARPITDELAY="999"
=:,RBLSMTPD="-We don't accept mails from MX with missing DNS A or PTR RR."

The indiviual settings and their consequences will be detailed along with the MRTG graphs.

All Connections

This diagram shows all SMTP connections on sslserver:

Thus, I do not accept SMTP connections from "unqualified" addresses; a succesful DNS A lookup resulting in any FQDN is required.

Nearly all cable-net provider and ISP's have set up their nets that this is the case for any client. But I certainly will not accept SMTP connections from dubious sources:

rblsmtpd: 78.138.171.130 pid 28307: 553 We don't accept mails from MX with missing DNS A or PTR RR.

Note: This only works if tcpserver/sslserver is told do a DNS PTR + CNAME lookup (tcpserver -hp)and also requires to have a propper name resolution. I use dnscache of course...

All Sessions

A EMSTP (RFC 2822) sessions starts with the EHLO greeting string by the client; a SMTP (RFC 822) session starts either with a HELO or with a MAIL FROM.

The significant difference between the number of inbound SMTP connections and the residual amount of SMTP session is due to the GREETDELAY of 80 seconds.

After 80 seconds most of the bot-net SMTP clients installed on PCs are not willing to carry on the SMTP session, thus they never ever starting a (E)SMTP session. This binds tcpserver/sslserver + qmail-smtpd resources in my case but happily stops 70% of spam. However, this is a very good investment because

1. I don't neither do a virus nor spam scanning of those (potential) emails,
2. it protects you during that time, because I block the spammer's resources.

As can be seen from the tcpd.smtpd rule-set, I use SPAMCONTROL's badhelo ability and require, that the provided HELO/EHLO greeting string is a resolvable FQDN.

This avoids to receive emails from spurious sources like this well-known spam candidate:

Reject::SNDR::DNS_Helo: P:ESMTP S:69.155.203.42:69-155-203-42.unitewireless.com H:friend F:reginald@funeasy.biz T:erwin@fehcom.de 'A'

I also have a small set of lines in SPAMCONTROL control/badhelo:

*fehcom.de
*fehcom.net
*localhost*
aristotle.superscript.com!

SPAMCONTROL's badhelo implementation works in split-horizon manner; thus I do not accept EHLO/HELO greetings with my own address. In addition, I don't accept any variation of *localhost* for the greeting. Actually, as a subscriber of Superscripts ucspi-ssl email list, I had to whitelist their helo greeting: "aristotle.superscript.com!".

I don't know, whether they did use the name of the antique Greek philosopher Artistoteles by mistake, or what happened. However, the example shows nicely, the way SPAMCONTROL's badhelo mechanism works:

Accepted Sessions

This diagram shows:

Authenticated Sessions

(uups, there is still a typo in the qmail-smtpd.mrtg conf file)

STARTTLS Sessions

Of course, this makes only sense using sslserver together with the appropriate certifcates (I certainly have to renew my own):

Note: There is currently no mean, to tell if the ESMTP server's certificate as rejected by the client.

Rejected Sender

This diagram tells how many SMTP sessions have been rejected due

Sample out of SPAMCONTROL's log:

Reject::SNDR::Invalid_Relay: P:ESMTP S:217.172.47.37:eu3.internet.bs H:217.172.49.35 F:bobbylinster@yahoo.com T:rogerfalter2006@yahoo.com

Reject::SNDR::Bad_Helo: P:ESMTP S:217.121.213.107:cc676383-b.zlr1.dr.home.nl H:localhost F:powerfirming.com@freehealthstuff.com T:feh@fehcom.de '*'

Rejected Originator

In X.400 terms Originator is the Return-Path name provided MAIL FROM <return-path> command, ie. spammer@badhosts.com.

Two cases are shown in that diagram:

Rejected Recipient

In SMTP/ESMTP mail, the provided Forwarding or Recipient address ("RCPT TO: <recipient>") is really the only information you can trust (see man forgery); the content of all other SMTP commands (and the header oft the email of course too) can be faked.

Here, you get the following information:

Rejected Base64

SPAMCONTROL's WarLord implementation allows to detect certain Base64 encoded MIME attachments which are known to be dangerous for in particular Windows Mail clients:

You see:

Rejected Data

SPAMCONTROL includes the QHPSI mechanism als well as the ability to use a qmail-queue replacement by means of the qmail-queue Extra mechanism and subsequently to do a virus scanning during the SMTP DATA phase.

You see:

Sample out of SPAMCONTROL's log:

Reject::DATA::Spam_Message: P:ESMTP S:76.4.233.210:nv-76-4-233-210.dhcp.embarqhsd.net H:nv-76-4-233-210.dhcp.embarqhsd.net F:yuovr@afamilyjournal.com T:erwin@fehcom.de ''

Cologne, September 13th, 2009.

[Impressum]

[FEHCom]

[top]