i hate spam, i said that already, and last weak i got over 200 spams on a single day. then i decided that it's time to implement my long-time plan of firing up spamassassin on my two old servers, and to do it right and run it as a sendmail milter.

there's multiple spamassassin milters out there. the one which is free and in debian is a savannah-hosted project called spamass-milt and according to some of my friends it sucks badly. the alternative from snert is not free enough for debian but has better stability reports. this is the story of the journey that was necessary to get this stuff built and running.

the obvious approach...

i try to apt-get install spamassassin from testing, as the one in stable is way to ancient. no luck, it needs a newish htmlparser which needs lots of newer shite which needs lots of other extras which sucks.

...thwarted, but BF&I...

ok, let's build it locally, then. apt-get source. muttering about "when in doubt use brute force (and ignorance)". yeah, right: building the bloody thing needs newer debhelper needs newer debconf needs newer libc and lots of other bla. no thanks, not on this server i don't want to play with the latest maybe-stable-but-not-quite-certain-for-sparc libc6.

...don't work. let's detour a bit!

(your honour, i plead that this happened late, after a beer or two)

now i tried to finagle with pbuilder (forgetting about the resulting shlib-dependencies dooming the idea from the start) and build it in there, not soiling the rest of the system with newish-unstable libs. the stable versions of pbuilder and debootstrap are ancient, so trying testing: needs a newish debootstrap which in turn pulls in a newer libc and associated garbage which i wanted to avoid in the first place. damn! and building pbuilder: needs lots of xsl shite, so no go. another useless attempt: build new debootstrap as that would have brought in the new libc and doesn't need much build-deps, then go for testing pbuilder. finally it dawns to me: gah, useless idea - bad shlib-deps in the resultanyway...

backtrack and so

so now it's: build it locally after trying to go for the full build deps, loooong list:

debhelper/testing debconf-utils/testing debconf/testing dialog/testing libncursesw5/testing,

which pulls in

debconf-english intltool-debian liblocale-gettext-perl libncursesw5 libtext-iconv-perl linux-kernel-headers po-debconf

and upgrades

debconf debconf-utils debhelper dialog libc6 libc6-dev locales

fuuuck, that's worse than trying to get the spamass binary package in the first place! think again about building libhtml....no go, that's perl 5.8 only and 5.8 has /way/ too much potential for problems for me to upgrade right now. end of day one.

less beer, more brain, still sucky

hatehatehate. the libc6 ds-revision is to be pulled in, but that one is annoying and sucky - don't want to have it on a server. most of the other dependencies of spamassassin we can talk about, but which one of those packages pull in the new libc? grep-dctrl helps finding out that libncurses is to be blamed, which is needed by dialog - which has build-deps on libncurses >=5.3, so building it locally is no go at the moment.

to summarise: at this point i'm about four layers away from spamassassin, thinking about building certain packages locally so that no too-new libraries are pulled in. spamass---debconf---dialog---libncurses <---- you are here. now look at building libncurses5w: wants 64bit libs and compiler on sparc, WTF?!? what a mess, i've commented stuff indebian/control, let's see. builds for multiple hours on an SS5, had to fiddle with debian/rules too as dh_movefiles looks for too much stuff to move around, but finally i have sparc debs of all this trash. YES! now what did i want to do with this?

another day later...

woohee, somebody added patches to spamassassin to make backporting possible again! (2.61-2 in unstable right now): the htmlparser issue is gone, but still needs debconf better than 1.2...the testing-debconf needs a newish dialog (or whiptail, but the same libc-problem as with dialog persists - yes i detoured once more and looked at that avenue, too).

but with libncursesw5 (locally built) i can get dialog/testing, and now i can get debconf debhelper and debconf-utils from testing, too, so spamassassin might be installable after all - do i need spamc (which would be a problem...)? yes i do, bummer.

still not assassin

ok, the status is that i can now install spamassassin/unstable, almost: spamc is needed >>2.30 or so. the stable one is 2.20, and spamc is C and needs to be compiled. shiiiiiite. ha, looking around i find out that one one of my server sparcs i had a spamc 2.55 package lying around. good enough! (the situation else would have been dire: building spamass locally with all the extra dependencies to be pulled in...and i hate sloppyness, don't want to tweak things using equivs or other dirty tricks)

eeeeeventually...

we can build milter-spamc: libdb3-dev also needed, and something called libsnert. bastard programmer, hardcoded paths, hierarchy in tarballs, library with almost-standard toolsuite rewritten from scratch. gaaah. install script is outright dangerous, must do that by hand... a bit later: hmm, seems to work. one patch necessary to get rid of subject rewriting, submitted. newer spamassassin needs different settings (no more use_terse_report...) than what i had to start from, but that's now done, too. more later: some fiddling with daemon failures etc: seems that socket MUST be removed before the milter daemon is re/started, or no comms will work. much later: hmm. this adds spamass headers /internally/, mostly ignoring what spamass actually generates - or is the spamd protocol so foolishly defunct? anyway, it makes debugging and customizing /very/ ugly. also the spamass report with spamc is different from what's generated in the headers of a mail, grrr. unelegant: the status header is not as nice as the one spamass generates, so i've put some extras into report, and run the milter-thingie with -A. but, now i got to the stage where both my aging sparcs do the spamkilling for me - and they outright reject all spam above a certain threshold, yay! (of course i know that this is not a global remedy for spam but it feels better not to just eat the shit without feedback/complaint - irrational i know.)

future? what future?

maybe i'll also add milter-sender by the same author: that thingie queries the purported MXes for the MAIL FROM address on the fly and looks whether these know about the address. if not the mail message is rejected before it has been transferred :-) nice, not a perfect fix either, but again better than eating all that spam and growing ulcers without any feedback to the bastards.