Consulting djbware Publications
≡  

Fight Spam with s/qmail

This page provides information about my personal settings, how I fight spam with s/qmail.

Message bounces due to SPF

You probably have reached the Web site by means of a bounce message, providing this URL and telling, that you email has been rejected (failed to reach the recipient) due to misconfigured SPF record in the DNS.

Since December 2016 s/qmail (my MTA) is able to understand SPF records in the DNS and to act on the provided information.

How to circumvent this situation?

s/qmail's activity charts

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:

My sslserver settings

First, I have set up qmail-smtpd by means of my IPv6 enabled sslserver:

#!/bin/sh
QMAILDU id=`id -u qmaild`
QMAILDG id=`id -g qmaild`
HOSTname="mail.fehcom.net"
export SMTPAUTH=""
export UCSPITLS=""
. /var/qmail/ssl/env
exec softlimit -m 180000000 \
sslserver -sevn -R -l $HOSTNAME -c 10 \
-x /var/qmail/etc/tcpd.smtpd.cdb \
-u $QMAILDUID -g $QMAILDGID 0 smtp \
rblsmtpd -W -r ix.dnsbl.manitu.net \
/var/qmail/bin/qmail-smtpd /var/qmail/bin/qmail-authuser true 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="50"
:deny

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:

sslserver: deny 2933 mail.fehcom.net:217.172.188.134:25 :58.60.240.100::1569

Note: This only works if tcpserver/sslserver is told do a DNS A lookup (tcpserver -h)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 50 seconds.

After 50 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 s/qmail'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 s/qmail's control/badhelo:

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

s/qmail'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 s/qmail's badhelo mechanism works:

Accepted Sessions

This diagram shows:

Authenticated Sessions

(START)TLS 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 qmail-smtpd'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

s/qmail'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

s/qmail 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 s/qmail'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 ''

 

Höhn, December 5th, 2016.