Apparently I am sufficently serious and annoyed by both spam and the hasslement of accomplishing my objective that I’m sticking to it, in abeyance of my previous sour declaration.

My objective is to get a server-side spam filter, or “milter” as the kids would have it, installed on my mail server so that all incoming mail gets vetted. Cursory research revealed that Spam Assassin is the Bayesian weapon of choice. Forthwith, the links I’ve been haunting in search of the wise words of early voyageurs into OS X serveration.

One person, as noted earlier, has actually accomplished my goal.

Unfortunately for me, the world has turned, and the versions of sendmail and SpamAssassin there employed are both superannuated. Currently, I’ve been able to get everything to work as desired up through the compile of the milter proper, which barfs on something I haven’t noted yet but which appears to be different than Numbski’s compile problem.

Or maybe it is, as he had problems with a function called “new_poll()” while mine also have to do with polling:

spamass-milter.cpp:86:24: subst_poll.h: No such file or directory
spamass-milter.cpp: In member function

Savannah: Project Info – SpamAssassin Milter Plugin and mailing list archives are my next stop.

Previously was having trouble getting sendmail to unzip – it was because I stubbornly persisted in attempting to use a non-commandline product, Stuffit Extractor, to do the job. Once I broke down and typed “tar xvf filename” all was well. Silly me – expecting a GUI tool to do a man’s work!

Monkeying around wth my sendmail has led me to seek to disentangle the gordian wiki that is the documentation – or lack thereof – of the beloved SquirrelMail, a PHP-based webmail system that relies on IMAP to manage email on the server. Unfortunately for me, in previous incarnations, SM had no clearly documented capacity to handle secure communications with sendmail or the uw-imap family of mail demons. Sufficiently curious about what’s failing, I’ve joined the support list, which did not apparently show a record of my specific problem. The PHP part of the program looks like it’s working just fine, but it does not successfully establish communications with the IMAP demon, desite currently supporting the needed protocols.

Secure connections are no longer an option, but rather the default in most of these projects. This has had the salutory effect of requiring the casual user, such as yours truly, to seek the wisdom of such masters of clarity and open, clear communication as the PGP corporation, which, in their defense, did explain to me how to resolve a bug in their free version, once I was aware that they did not, in fact, provide support for the free version.

(I should explain I actually was a good boy ages ago and setup a bunch of security stuff server side, albeit grumpily. Mmmm, brussels sprouts and lima beans!)

So.

I think that hits most of the links I’ve been pawing through lately – it feels rather like digging around trunks of other people’s old clothes. One of the special qualities of the open source support mailing lists is the testiness of many of the knowledgeable users in response to support questions from, well, those less knowledgeable.

It’s understandable, sure.

But I’d venture to guess each nastygram on the support list of a given opensource project translates directly into increased shareholder value at a certain large, friendly software provider across the lake from where I live. Hm, I wonder – could there be any legislative pressure aimed at UW-developed projects such as pine and uw-imap?