The RA SPP Plugin collection
This package provides several plugins meant to be used with a qmail patched using qmail-spp (http://qmail-spp.sf.net).
They cover diverse areas, and are meant to be written according to the following principles:
Good performance
They are written whenever possible in C, and try to be short and direct.
Good logging
They should inform the user of what they do. No email should ever be rejected without logging something. Also, all plugins logs include the PID of the qmail-smtpd process, so you can easily group all events of a connection.
Security
Since writing in C exposes oneself to the dangers of memory corruption, I have tried to use, whenever it makes sense, the Better String Library, to avoid problems. While this makes the plugins larger, it also makes me feel more comfortable.
Also, for most plugins, it should be possible to run them as a very unprivileged user or in a chroot jail. This is not yet implemented, but it is worth thinking about.
Current version is 0.2.2 (See Changelog)
The plugins included are:
rblchecks (you can see an article I wrote about it, too)
There is also a public SVN repository with much newer (hopefully better) code at goglecode.
Changelog
-
2006-05-11 version 0.2.2
Fixed stupid bug in ipthrottle plugin (was sending a debug message to the client)
-
2006-04-21 version 0.2.1
Fixed Makefile, maybe it now builds with older gcc.
-
2006-04-08 version 0.2
Fixed rcptchecks to detect vpopmail domains correctly
Spelling errors pointed by Pawel Foremski
Small documentation fixes
-
Version 0.1
Original non-release ;-)
ver 0.2 does not compile with older GCC
please fix!
mail:/dist/current/ra-plugins-0.2 # gcc --version
2.95.3
mail:/dist/current/ra-plugins-0.2 # make
gcc -Wall -g -Os -o authchecks authchecks.c bstraux.c bstraux.h bstrlib.c bstrlib.h
In file included from authchecks.c:23:
bstrlib.h:173: parse error before `.'
bstrlib.h:173: stray '' in program
[snipped a lot of similar errors]
Edited By Siteowner
Sorry, those files are not my code.
Maybe you can point it out to the author at http://bstring.sf.net
On my debian 3.1 it cannot compile!
Why?
vmail1:/usr/local/src/qmail/spp-plugins/ra-plugins-0.2# make
gcc -Wall -g -Os -o authchecks authchecks.c bstraux.c bstraux.h bstrlib.c bstrlib.h
gcc: compilation of header file requested
bstrlib.c:1391: warning: type defaults to `int' in declaration of `instr_fnptr'
gcc: compilation of header file requested
make: *** [authchecks] Error 1
vmail1:/usr/local/src/qmail/spp-plugins/ra-plugins-0.2#
Thank's
Interesting.
Maybe both compilation errors are caused by the same thing.
I have uploaded a 0.2.1 version that changes the Makefile so it doesn' t try to build the .h files.
On gcc 3.4, that works, maybe on earlier versions it doesn't.
Please check it and let me know if it works now.
Thank's.
Now it is
ipthrottle.c:27:19: relay.h: No such file or directory
i have changed
include to
include "relay.h"
and now i get
make
gcc -Wall -g -Os -o ipthrottle ipthrottle.c bstraux.c bstrlib.c -lrelay
bstrlib.c:1391: warning: type defaults to `int' in declaration of `instr_fnptr'
/usr/bin/ld: cannot find -lrelay
collect2: ld returned 1 exit status
make: *** [ipthrottle] Error 1
:-(
Read the docs for that plugin: it requires relayd (and it's librelay).
If you need ipthrottle, then install that.
If you don't, use make -k so it goes on and builds whatever plugins it can :-)
Perhaps it's not common config but on my server sometimes I'm using .qmail-XXX files inside vpopmail domain directory. Because rcptchecks does not "support" this kind of "accounts" i had to patch it. If you're interested diff is avaible at http://mirek.czuwaj.net/pat....
Miroslav: awesome! I'll make a new release with this patch soon!
hardcoderbl - love it! But ...
Ive notices a number of spam messages getting through where they have multiple "recieved from:" sections in the mail header.
Often the chain of servers starts at a blocked servers IP. When I check the logged messages I see that hardcoderbl checked one of the servers at the top of the chain and accepted it. Rather than checking the servers at the start of the chain. This may relate to the info that qmail-spp is passing.
If you have any suggestions on how to improve the checking, I'd really appreciate it.
Here is an example:
The log showed : accepted 203.96.152.182
But the chain starts at 202.156.242.116 which is listed in dynablock.njabl.org.
Return-Path:
Delivered-To: davidg@ttc4it.co.nz
Received: (qmail 1487 invoked by alias); 2 Nov 2006 19:08:58 -0000
Delivered-To: rach@ttc4it.co.nz
Received: (qmail 1483 invoked from network); 2 Nov 2006 19:08:58 -0000
Received: from linda-3.paradise.net.nz (203.96.152.182) by host-192-170-100.2.thebook.... with SMTP; 2 Nov 2006 19:08:58 -0000
Received: from smtp-2.paradise.net.nz (tclsnelb1-src-1.paradise.ne... [203.96.152.172]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id for rach@ttc4it.co.nz; Fri, 03 Nov 2006 05:28:28 +1300 (NZDT)
Received: from [202.156.8.10] (cm116.gamma242.maxonline.co... [202.156.242.116]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 762BB160B1E3 for ; Fri, 03 Nov 2006 05:28:25 +1300 (NZDT)
Dave: There is a reason for it.
When any of the RBL checkers do their thing, the only known IP is from where the connection is actually coming from.
This is a good thing, because if you check the first IP, noone will send you email ;-)
That first IP is probably the user's home IP, and **all** of them are in dynablock, because they are home or dynamic IPs.
If the user is sending you mail via his ISP's server, he is doing the right thing, and RBL leaves him alone.
I've got some spam here today... The spammer used my domain in upper case, so rcptchecks doesn't cosidered it local.
To correct this, i add the following to line 82:
btolower(smtprcptto);
Renato: Thanks for the message, I have it fixed in 0.2.9, which of course is not released yet :-(
Are you still developing these plugins? If not, do you have any recommendations for actively-developed SPP plugins?
The SVN version is pretty mature and stable, and variations of it have been used in production for years.
Sadly the whole qmail ecosystem seems to have shriveled and died, so this is mostly a legacy product.