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?
- If you are the owner of the domain, check your SPF record and adjust it to the standards as detailed by OpenSPF.
- If you are simply a user of email system, please inform the postmaster or the administrator of this systems, forwarding the bounce message to him.
s/qmail's activity charts
- 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 sslserver settings
First, I have set up qmail-smtpd by means of my IPv6 enabled sslserver:
QMAILDUID=`id -u qmaild`
QMAILDGID=`id -g qmaild`
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:
The indiviual settings and their consequences will be detailed along with the MRTG graphs.
This diagram shows all SMTP connections on sslserver:
- connections ok -- accepted SMTP connections.
- connections deny -- rejected SMTP connections due to unqualified addresses.
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:220.127.116.11:25 :18.104.22.168::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
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
- I don't neither do a virus nor spam scanning of those (potential) emails,
- it protects you during that time, because I block the spammer's resources.
- sessions ok -- accepted SMTP sessions.
- sessions deny -- rejected SMTP sessions due to a bad SMTP greeting.
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:22.214.171.124:69-155-203-42.unitewireless.com H:friend F:firstname.lastname@example.org T:email@example.com 'A'
I also have a small set of lines in s/qmail's control/badhelo:
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:
- First, the control/badhelo match is done and
- second, the (more costly) DNS lookup is facilitated.
This diagram shows:
- originator -- accepted SMTP due to a Authentication of Relayclient condition.
- recipient -- none-Authentication, none-Relayclient case but either control/rcpthosts and control/recipients was ok.
- accepted -- accepted authenticated SMTP sessions.
- rejected -- unsuccessfully required authenticated (REQUIREAUTH) SMTP sessions.
Of course, this makes only sense using sslserver together with the appropriate certifcates (I certainly have to renew my own):
- accepted -- accepted STARTTLS SMTP sessions.
- rejected -- unsuccessfully required STRARTTLS SMTP sessions.
Note: There is currently no mean, to tell if the ESMTP server's certificate as rejected by the client.
This diagram tells how many SMTP sessions have been rejected due
- Relay -- not allowed (control/rcpthosts) and rejected relaying attempts.
- HELO/EHLO -- rejected HELO/EHLO greeting due to control/badhelo or any other BADHELO="..." condition.
Sample out of qmail-smtpd's log:
Reject::SNDR::Invalid_Relay: P:ESMTP S:126.96.36.199:eu3.internet.bs H:188.8.131.52 F:firstname.lastname@example.org T:email@example.com
Reject::SNDR::Bad_Helo: P:ESMTP S:184.108.40.206:cc676383-b.zlr1.dr.home.nl H:localhost F:firstname.lastname@example.org T:email@example.com '*'
In X.400 terms Originator is the Return-Path name provided MAIL FROM <return-path> command, ie. firstname.lastname@example.org.
Two cases are shown in that diagram:
- Badmailfrom -- not allowed due to control/badmailfrom condition with the many facetts SPAMCONTROL is able to (wildmat, split-horizon, badmail-from-unknown).
- DNS MX -- rejected due to unsuccessful DNS MX lookup of the provided Originator's hostname part ("badhosts.com").
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:
- Badrcptto -- not allowed Recipient due to control/badrcptto condition.
- Recipients -- rejected due to an unsuccessful lookup in the RECIPIENTS database.
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:
- BadMIME -- rejecte due to whitespaces in the attachment or a match in control/badmimetypes.cdb.
- BadLOADER -- rejected due to a control/badloadertypes.cdb condition.
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.
- Virus -- rejecte due to a positve virus identification (by means of clamscan).
- Spam -- rejected by help of SpamAssassin and a (per virtual domain) defined spam score (Note: This feature has been currently disabled.).
Sample out of s/qmail's log:
Reject::DATA::Spam_Message: P:ESMTP S:220.127.116.11:nv-76-4-233-210.dhcp.embarqhsd.net H:nv-76-4-233-210.dhcp.embarqhsd.net F:email@example.com T:firstname.lastname@example.org ''
Höhn, December 5th, 2016.