Well, to answer your question, spamdyke is aimed at... me. And mail administrators like me, I suppose. :)
Some history: The first time I installed qmail, I used the qmail handbook by Dave Sill. All of my previous Unix mail experience was with Sendmail, so I didn't understand anything about qmail's design or configuration. I didn't even know what the term "toaster" meant (I'm still not 100% certain about that word...). I just followed the book's instructions, which said (IIRC) to use netqmail 1.03, vpopmail, qmailadmin, vqadmin and ezmlm. I prefer working at the command line and I'm (obviously) a programmer, so patching and compiling didn't bother me. I was just surprised at the necessity -- I hadn't manually installed a major system component like a mail daemon since I switched to RedHat 4 from Slackware in 199x. I wouldn't have bothered with qmail at all, but I wanted to host multiple domains on the same box and I was sick of Sendmail's lousy virtual domain support. Anyway, _after_ qmail was installed and in production, I learned about some additional patches to add things like virus scanning, SpamAssassin, etc. However, when I tried to apply and install them, everything broke. No inbound or outbound email, angry users, long nights, etc. I finally managed to restore the system to its former state and swore never to touch a working qmail installation again. That's still my motto, BTW, despite everything I've learned about qmail since that incident. It's just easier (and safer) to build a new server and swap it into position. Now here I am, running a mail server I'm scared to update. Is there a new version of vpopmail available? I don't know. I'm not even sure what version I'm using. Have some of the patches been updated to fix security holes? How would I possibly find out? I can't remember where I got most of them (or even which ones I used). I don't care anyway -- I'm not going to install them, because I'm hosting Real Email for Real Customers and my time is too precious to pick fights with qmail that I'll probably lose. So welcome back to the Bad Old Days of Linux system administration. This is why "rpm" and "apt-get" were created but DJB's bullheaded obstinacy renders those tools useless. That's why I say spamdyke is targeted at me. I want filtering and logging but I'm not willing to recompile qmail to get those things. I want a package that is small and self-contained, so I can upgrade it (or use rpm/yum/up2date/apt-get) without fear of losing my job. When I first created spamdyke, I wanted it to (eventually) replace every qmail patch, because it meant fewer patches would have to be applied to new qmail installations. Nowadays, in the presence of maintained and preconfigured qmail distributions like QmailToaster, that need is somewhat lessened and I can concentrate on features that aren't available through patches (or are difficult to use or are broken). At the same time, I don't want to forget about the mail administrators running 8 year old qmail installations that they're scared to touch. :) -- Sam Clippinger Michael Colvin wrote: > This will sound strange after all the "Suggesting" I've done recently but... > :-) > > I think Sam's idea/concept for SpamDyke, if I understand it correctly, is > ideal. Make something that is easy to install, adds functionality to a > basic Qmail install without a lot of patching. I think having a completely > STOCK qmail install, adding something like SpamDyke that can do all the > filtering in front of qmail, would make the complete package better. Face > it, a lot of people don't use qmail because they are scared of all the > patches, and the fact that it isn't "Maintained", which, is actually kind of > funny..They consider postfix "Maintained" because it gets occassional > updates...Yet, even with things like SpamDyke and the various patches/smtp > additions, the don't consider Qmail "Updated", because the auther isn't > bundling the changes himself... > > Anyway... Most people tha run Qmail are likely running, netqmail, qmail > with jms's patchs, or qmailrocks, or a stock qmail. Those with jms's > patches and netqmail have most of what's built into SpamDyke, by > modifying/changing the smtp to rblsmtp, as I understand it. So, instead of > an outside application doing that scanning and handing it off to an smtp > daemon to process, the smtp daemon does the processing...Not sure which is > better. > > Qmailrocks has it's downsides, so in that case, SpamDyke definetely adds > some much needed additions, and makes them easy to implement. Obviously, > with a stock qmail install, this is also true. > > So, who is SpamDyke *REALLY* geared towards? Not a retorical question, I'm > actually curious. I've found it very helpful and very effective. As I dig > beyond "Qmailrocks" into other variations of installing qmail, I'm finding > most of SpamDykes functions, or at least the ones I'm using, implemented > directly in Qmail via patches. Perhaps avoiding the patches is the benefit. > How often do we really upgrade the core functionality of qmail...The stuff > that would need to be recompiled should we upgrade something? Qmail's core? > Not in years. Vpopmail? Yea, occassionally, if you want to, or if a > bug/exploit is discovered..(When was the last time tha happened?) > Qmail-queue? Probably more than the others, but still seldom, and not a big > deal to do... > > Anyway... Enough rambling. I need to figure out how I'm going to implement > all these cool toys in qmail. :-) > > Michael J. Colvin > NorCal Internet Services > www.norcalisp.com > > > > > > > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Sam >> Clippinger >> Sent: Friday, May 16, 2008 9:29 AM >> To: spamdyke users >> Subject: Re: [spamdyke-users] yet another wishlist... :-) >> >> Actually, I've been thinking about adding queuing in two >> stages for other reasons. Queuing just the message header >> would allow spamdyke to filter based on header lines like >> Subject (and log them as well). It could also check the IP >> addresses from Received lines against DNS RBLs (SpamAssassin >> does this). If spamdyke were to queue the entire message, it >> could do more filtering like limiting message sizes or >> stripping/blocking attachments. Running virus and spam >> checkers would just be a nice side benefit. >> >> I know this functionality is available elsewhere -- that's >> why I haven't added it yet. But as I've stated before, I >> don't mind reimplementing something if I think it would be >> more convenient or better in spamdyke. >> If spamdyke could make it possible for an existing qmail >> server to use SpamAssassin, for example, the administrator >> might be willing to try it. If his only other choice is to >> recompile and risk breaking everything, he won't do it. >> >> Don't worry -- none of this is being added to the list for >> the next version. If it happens at all, it would be several >> versions away. >> >> -- Sam Clippinger >> > > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
