Blue Flower

Stop spamassassin/spamd (ie: you don't want it to be running during the upgrade).

Run "sa-learn --rebuild", this will sync your journal. if you skip this step, any data from the journal will be lost when the DB is upgraded.

Run "sa-learn --sync", which will cause the db format to be upgraded. If you want to see what is going on, you can add the "-D" option.

Test the new database by running some sample mails through SpamAssassin, and/or at least running "sa-learn --dump" to make sure the data looks valid.

Start running spamassassin/spamd again.

Monday, 06 July 2015 00:32

How to bypass Spamassasin for certain source IPs

Written by

Sometimes messages come across that list that Spamassassin considers spam.
Then the question is should I relearn it as ham, or leave it as spam,
because it obviously has characteristics of a spam (because someone
has FW'd a real spam), but also has characteristics of a ham as well.
The recommendation from the Spamassassin folk is to not have spamassasin
scan emails from this list.

I checked out the header and saw that the messages always come from ( ). I edited /etc/tcp.smtp and added:, QMAILQUEUE="/var/qmail/bin/qmail-queue"

After rebuilding the tcp.smtpd.cdb file, this told qmail-smtpd to skip and to just run qmail-queue right away. This
worked, and I was now not scanning the message for spam. However, its
bypassing clamav as well. This was not acceptable.

I checked out the source of and found this as
part of the sub spamassassin and sub spamassassin_alt routines:

#Only run SA if mail is from a "remote" SMTP client, or QS_SPAMASSASSIN
#is defined via tcpserver...
if (defined($ENV{'RELAYCLIENT'}) && !defined($ENV{'QS_SPAMASSASSIN'})) {
&debug("spamassassin: don't scan as RELAYCLIENT implies this was
sent by a local user");
&minidebug("SA: don't scan as RELAYCLIENT implies this was sent by a
local user");

So I added the following peice right below the above code:

if (defined($ENV{'IGNORE_SA'})) {
&debug("spamassassin: don't scan as IGNORE_SA is set");
&minidebug("SA: don't scan as IGNORE_SA is set");

Make sure you change it in both routines.

Saved the file, edited /etc/tcp.smtp to instead say:,IGNORE_SA="yes"

Recompile tcp.smtp.cdb, and you're done! Now any mail coming from that
IP will bypass your spam filters. Since that server is run by apache and
the spamassassin guys, I figure its save to bypass the spam filter for
other mails that may possibly come from there.

Hope this might be useful to someone..

Special thanks to Roman Volf
Also avalabile as a patch at

Monday, 06 July 2015 00:31

SPF Checking with SpamAssassin 3.x

Written by

To install SPF, do the following:

If you are using John Simpsons qmail-smtpd-run script SPF Checking is now done within his script at the SMTP level. See his web page for additional configuration information.

cd /downloads/qmailrocks/
tar xvzf Mail-SPF-Query-1.997.tar.gz
cd Mail-SPF-Query-1.997
perl Makefile.PL && make && make install

You can test this installation (and that PER5LIB is set correctly) with perl -e 'require Mail::SPF::Query'.

Now we can let spamassassin check for SPF headers

Sunday, 05 July 2015 17:12

Correcting SpamAssassin and Qmail-Scanner Problems

Written by

Without Set-UID enabled in Perl (All distos) and the libwww-perl module (For RedHat or Fedora Users) installed, SpamAssassin and Qmail-Scanner inevitably don't work properly. Usually this is indicated by qq temporary problem 4.3.0 or simply by spam subjects not getting tagged.

The solution proven to work on FreeBSD, RedHat and Fedora 2 is to make sure that these modules are installed and then reinstalling ClamAV, SpamAssassin and Qmail-Scanner.


# chmod 4511 /usr/bin/suidperl

The above command enables setuid which is disabled by default,or

Enter the line "ENABLE_SUIDPERL=true" in /etc/make.conf. If that file does not exist, create it. After doing a cvsup on ports which is explained here, go to /usr/ports/lang/perl5.8 and run make deinstall && make reinstall.

For RedHat or Fedora Users

rpm --Uvh /downloads/qmailrocks/patches/rpms/perl-suidperl-x.x.x-xx.x.i386.rpm
to install the setuid module for perl
search or your favorite rpm repository for perl-libwww-perl

Install the RPM and afterward run updatedb to be sure your rpm database is consistent.

For Debian Users

Run apt-get install perl-suid

Once you have both modules installed and enabled continue with or reinstall qmailrocks step 14 and 15 to install Clamav, Spamassassin and qmail-scanner with setuid enabled.

Friday, 17 June 2016 16:46

Enabling SpamDyke for qmail

Written by

Spamdyke is a filter for monitoring and intercepting SMTP connections between a remote host and a qmail server. Spam is blocked while the remote server (spammer) is still connected; no additional processing or storage is needed. In addition to all of its anti-spam filters, spamdyke also includes a number of features to enhance qmail. Best of all, using spamdyke does not require patching or recompiling qmail!

Lets install the port.

# cd /usr/ports/mail/spamdyke
# make install clean

Make sure the following boxes are checked:


Now we need to edit the spamdyke.conf to enable logging.

# vi /usr/local/etc/spamdyke.conf

Now change the following values under logging.


Now lets create the directory and set permissions:

mkdir /var/log/qmail/spamdyke
chown -R qmaild:wheel /var/log/spamdyke

I have re-written the qmail-smtpd/run file as of 6/21/16. If you have downloaded that file before this date you will need to copy the new file over. To download it here is what you will need to do:

# cd ~root
# mkdir qmail
# cd qmail
# fetch
# tar zxvf scripts4.tgz
# rm scripts4.tgz

Now you'll want to edit the new smtpd_run. Please pay attention to anything you have already enabled and uncomment the lines. For instance if you're using validrcptto you'll want to un-comment the appropriate validrcptto lines, etc.

# vi smtpd_run

Change the IP first

Under the RBL section uncomment the following line:

RBLCMD2="/usr/local/bin/spamdyke -f /usr/local/etc/spamdyke.conf"

exit the file then we will copy it over:

# cd /service/qmail-smtpd
# cp run
# cp ~root/qmail/smtpd_run run
# chmod 755 run

and then restart the qmail-smtpd service.

# svc -t /service/qmail-smtpd

Now check the service and make sure it's running.

# svstat /service/qmail-smtpd
/service/qmail-smtpd: up (pid 20708) 12 seconds

Optional: Adding Spamdyke recipient validation

Parts of this article were modified from this page:

It's impossible to overstate the complexity of qmail's recipient validation procedure. It is inexcusably complex, far beyond the point where anyone can be certain qmail's implementation is correct (and secure) in all cases. If you want to get a glimpse at how bad it is, take at look at the flowchart here. You'll see the flowchart is big, but the number of possible configurations is describes enormous: there are just under 165 thousand different paths through it (even more if the loops are followed multiple times). Fully testing spamdyke's reject-recipient filter requires checking every one of those paths -- this takes weeks to finish using spamdyke's test scripts. spamdyke-qrv begins its work at step 7 in the flowchart (steps 1, 2, 5 and 6 are assumed to have been performed by spamdyke before spamdyke-qrv was started).

spamdyke-qrv is intended to be run as root by marking the binary "setuid root". This is necessary because spamdyke typically runs as a non-root user and doesn't have access to all of the files needed to validate an address without root access.

Now lets start the installation:

# cd /usr/local/bin
# ln -s gcc46 gcc
# ln -s g++46 g++
# cd /usr/ports/distfiles/
# tar -xzvf spamdyke-5.0.1.tgz
# cd spamdyke-5.0.1/spamdyke-qrv
# ./configure --with-excessive-output --with-vpopmail-support VALIAS_PATH=/usr/home/vpopmail/bin/valias VUSERINFO_PATH=/usr/home/vpopmail/bin/vuserinfo
# Make
# make install

Check the install with:

spamdyke-qrv -v -v username

Monday, 06 July 2015 01:02

Setting up a secondary qmail server

Written by

The purpose of this document is to provide information for the user to make a decision about creating a backup mail server. The first question should be how many messages will be arriving on a daily basis? The next question is how important are my messages to my company or organization? Managing servers can be hard but if your messages are lost or bouncing when your server is down than a secondary or queuing server is the answer. The purpose of this is to have the secondary
server sitting in front of your qmail server just passing the messages along. When (and if) you are having a problem with the qmail server the secondary server will queue the messages.

Ensuring the setup of the secondary server is quite simple; Just a very minimal qmail setup on a freebsd will work fine. All you need to do is install FreeBSD 10.2 and make sure ports are updated. Then run the following steps for just the secondary server:

Preinstall Checklist (Excluding Apache and Mysql)
Installing Qmail
Installing Daemontools 
Installing UCSPI-TCP 
Installing Autorespond 
Disabling Sendmail
Configuring Qmail 

Additions to Configuring Qmail:

When you edit the smtpd_run file please adjust following settings:

This is to announce your hostname This is optional.


You can turn on GREETDELAY. GREETDELAY will not only save you for spam mails, but unlike Greylisting and/or filtering a la SpamAssassin, this is the only mean to really reduce the overall amount of spam because the timeslot required for the spam sender to deliver messages (whether successfully or unsuccessfully) is raised from typically one second to (<=) GREETDELAY seconds. I typically have good luck with a value of 15.


You can disable mfcheck:


Disable validrcptto by commenting the following lines:


NOTE: If you would like your queuing server to filter valid emails, You could setup a cronjob to fetch the validrcptto.cdb file to your secondary server and then restart qmail-smtpd. You would need to enable validrcptto in the qmail guide.

I typically turn off the 3 following SPF settings:


Disable qmail-scanner


You will also need to run through the Setting up SSL Certs and starting Qmail guide as well. Even though you're not relaying mail you still need to have a certificate setup for qmail. You can skip the sections for creating the qmail-smtpd-ssl service.

We need to do a few things first to make sure messages arrive correctly:

Make sure /var/qmail/control/rcpthosts has a list of your qmail domains

Now setup the correct routing with /var/qmail/control/smtproutes per the examples below:

If you want to route mail from one domain to another, you would do it like so:

If you want to route all mail and then you should have the line like:

At this point qmail will be installed. I have created a new qmailtcl that just controls qmail-send and qmail-smtpd. You can download it here:

# cd /var/qmail/bin
# mv qmailctl bak_qmailctl
# fetch
# tar zxvf qmailctlqueueonly.tgz
# rm qmailctlqueueonly.tgz

Now we can restart qmail

# qmailctl restart

Once this is done you can change your MX record to the secondary server and then it should pass the messages directly to your qmail server.

Page 9 of 23