Annoying prepackaged software feature of the day
Now that I've got a milter interface in postoffice, I've been playing around with some of the prepackaged sendmail filters out there, and have discovered some really annoying packaging arrangements. The clamav milter rpm that you can get for r*dh*t linux is packaged annoyingly, in that the out of the box configuration sends "helpful" bounce messages to the (forged) From: address on a virus, but that feature can be worked around by simply hacking the rh-specific /etc/sysconfig/clamav-milter.conf (or whatever it's called) file. But even after fixing that so that it doesn't attempt to do bounce messages, but just drops a fat chance, bucko! on the virus daemon, it does it in a way that reveals just a little bit too much information.
VIRUS (something) DETECTED BY CLAMAV - HTTP://WWW.CLAMAV.NET
I may be old fashioned, but I'd rather not have my AV solution broadcast the way it detected the virus, just in case J. Random virus-dork is analyzing bounces to see how they can make their squalid software more infectious.
On the other side of the verbosity argument, there's the milter for spamassassing, which blocks nigerian 419 spam with a simple
Blocked by Spamassassin, which is perhaps a little too terse for my tastes. I'd like to see some indication about just what spamassassin thinks the spam is, like
The simple solution for me will be to simply rewrite spamass-milter and clamav-milter to be less or more verbose (and then if I build r*dh*t rpm packages, I can get rid of the dumb sendmail dependency; postoffice has already proven that you don't need sendmail to communicate with a sendmail milter, so I can toss that dependency out with the wash. But it would still be lovely if I could take advantage of someone else's code without having to rewrite it to suit my needs.
Comments
<advertisement>
Well, your first problem is that you installed Postfix. You should have installed <a href=“http://www.pell.portland.or.us/~orc/Code/postoffice”>postoffice which already does all of that (except for the white/blacklisting of virtual users.)
</advertisement>
I’ve decided that syntax highlighting is teh 3v1l; the people who think that syntax highlighting is the greatest thing since sliced bread are invariably very young and have good vision, so (I’m thinking in particular of the vi clone vim, which r*dh*t ships as their standard vi, but things like color ls are just as bad) the whole idea of being able to turn the noxious “feature” off don’t even pass through their heads, and thus I end up ftping the offending files over to a non linux machine for editing because the non-linux machine runs a real honest to g-d vi instead of one of those cheesy clones.
Comments are closed
Amen. My friend and business partner is entralled with packaging systems. I hate them. The package binaries are invariably compiled with the wrong options for the reason I want the package.
I just fought this for a Postfix installation. And I’m not done. I still don’t have smtp authentication working. I still don’t have spamassassin or clamav or greylisting working (The issue here is granting whitelist/blacklist priveleges to the virtual users.)
And I have yet to have a package set the configuration defaults in a useful way. My best example off this is xemacs syntax highlighting default. I have my font size set quite high as the default, but if I allow font highlighting, function declarations are so small there are not readible.
I would much, much rather install from src. That, too, has it’s issues, though. Dependency hell. Calling for specific versions of shared libraries by non-standard names, for instance. If a binanary needs some one-use library, then why pretend it’s a standard shared library? Sigh. My LiveJournal client (logjam) is such a beast. It calls for very specific libraries. It didn’t need to. I ended up symlinking to the existing versions of the “real” libraries and it works just fine.
I wish I was fast enough at coding to just write all of it myself. :)