Ok, the first public version of SPF-socketmapd is here. :) This new SPF
socketmap daemon is a radical break with earlier Milter approaches based
on Sendmail::Milter (consequently, SPF socketmapd no longer requires a
thread-enabled Perl).
SPF socketmap daemon is very stable (for one, because I used the socket
map frame I already made for SRS-socketmapd). It leaks no memory of any
kind, only uses 8 MB, is non-blocking and high-speed; and since it forks,
the children no longer have to worry about possible unsafe re-entrant
calls.
SPF socketmapd, as its name suggest, communicates with sendmail (8.13.x)
via a socket map. And though I included an m4 in the distro, I will
quickly explain the process. SPF socketmapd uses the "check_mail" hook
(that is, the check MAIL FROM hook, for clarity), stores the result in a
macro, and, if applicable, uses that macro to construct the proper
Received-SPF header. That is pretty much it. :)
As for the (optional) Received-SPF, sendmail H lines only allow for
headers to be added that are not already present. That, in a nutshell,
sucks. Because, using m4 only, it means we cannot add our own Received-SPF
header if one is already present in the headers. To get around it, you
need to patch ONE line patch in the sendmail/conf.c file. Look for
"received" string (with double quotes) and define flags for received-spf
header:
{ "received-spf", H_TRACE|H_FORCE, NULL },
That will force sendmail to always add the "Received-SPF" header if we ask
it to, regardless of whether it already exists (like standard Received
headers).
It saddens me that it had to come to this; but, unless you use a Milter
again (which we really want to avoid), there is simply no other way to
have sendmail accept a duplicate Received-SPF header (at least not until
such time that sendmail.org considers Received-SPF an accepted
trace-header; maybe when SPF becomes 'official'?).
Still, I feel the new socket map approach is really the way to go. It is
so much more cleaner than the threaded Milter approach, and is very easy
to install, and you can have it up-and-running within 5 minutes (certainly
if, temporarily, you just use a custom header, like X-Received-SPF, or
Received-myhost-SPF).
N.B. You may have to manually move the Received-SPF H line: m4 does not
allow for the insertion of this header at the exact wanted position:
precisely above the Received header added by the MTA itself.
As for the SPF socketmap daemon itself, you run it as follows:
../spf-socketmap.0.27.pl spf-user
Where "spf-user" is the user you want SPF socketmapd to run as.
You can find SPF socketmapd at:
http://srs-socketmap.info/spf/SPF-socketmapd.0.27.tar.gz
Good luck!
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx