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
