Ok, that's what i'm just looking at. ;) Just setting up another XEN Virtual machine to check it out. I'll have to read the docs anyway. So don't worry. :)
Sam Clippinger schrieb: > Actually, the QmailToaster project I'm thinking of is hosted at: > http://www.qmailtoaster.org/ > It's basically a set of SRPMs you can download, build and install to get > a fully functioning, fully patched qmail server. It's pretty slick. > They have an active mailing list with some pretty knowledgeable people. > Best of all, they release updates for important packages like > SpamAssassin and ClamAV, so you can easily stay on the latest version. > > Also, I should mention that my example configuration directory was wrong > (oops). To configure spamdyke for "domain.com", you should actually > create a file named "_recipient_/com/domain". When in doubt, read the > docs, don't take my word for anything. :) > > -- Sam Clippinger > > David Stiller wrote: > >> Yes i looked at the sources and as far as i saw, that's very >> complex analysis, wich isn't necessary in my case. As my server is >> connecting to the internet, the module from Haggybear is rotating >> downloads of an update-script, ignoring that it should use a proxy >> and times out but doesn't recognize. >> I just need to know, who spammed, wich senders are important and >> black- or whitelist them. >> I'll modify my version to use the below mentioned config-dirs. As >> i'm always programming shell-scripts, it won't be hard to make it >> compatible to other systems, like QmailToaster. >> BTW, is "http://www.shupp.org/toaster/"; meant with that, or something >> else? >> >> Sam Clippinger schrieb: >> >>> This sounds like a great project to me -- it's exactly what I had in >>> mind when I added support for configuration directories. >>> >>> Specifically, if your tool updates the configuration file named >>> "_recipient_/domain.com", the changes will only affect recipients in >>> domain.com. That way, your users can do anything they want (including >>> completely disabling spamdyke's filters) and it will only affect their >>> mail. This is a much better solution than allowing any user to edit the >>> server's global configuration and affect everyone's mail. Not every >>> filter can be activated or deactivated through configuration directories >>> but most of them can (whitelists, blacklists, graylisting, rDNS filters >>> and others). >>> >>> You should also check out the Plesk control panel that Haggybear is >>> working on. That code may already include the features you're trying to >>> build: >>> >>> http://www.haggybear.de/component/option,com_docman/task,doc_details/gid,21/Itemid,54/ >>> >>> BTW, if you build your tool to also work on non-Plesk servers, you'd >>> probably find a large audience for it (especially on the QmailToaster >>> mailing list). >>> >>> -- Sam Clippinger >>> >>> David Stiller wrote: >>> >>> >>>> Hi all, >>>> >>>> i've written a Spamdyke GUI for Plesk for my customers, so that they all >>>> have their own responsibility, >>>> if they want to use greylisting and are able to maintain their black-and >>>> whitelists. It's nice, as they all can see, what's >>>> really happening in the mailsystem and keep away spammers and welcome >>>> their customers... Rejecting >>>> mails without letting the customers know, is near the border to being >>>> illegal in Germany, because the customers >>>> can make me, or my company responsible for missing mails. >>>> >>>> But one problem i have is the logic of where i keep those lists. At the >>>> moment i just save them to the Plesk >>>> database and dump them regularly by cron-job to special files called >>>> customer_blacklist_ip, customer_blacklist_rdns, >>>> and so on, which are used by spamdyke. That's a good way to write them >>>> with root and keep all privileges healthy >>>> and i can let it send a report to me, what has been done. >>>> >>>> Do you think it's a good politic to activate them globally? I understand >>>> it in the way that every whitelisted entry >>>> should be a possible "good" sender for the others too. The critial point >>>> are the blacklists: >>>> Of course i avoided that they add known IP's, i.e. my mail server's >>>> network and local IP's and also created >>>> a button to check the reverse data. As far as i know, thats a way the >>>> "big" providers do it, i mean tagging >>>> mails manually as spam or ham. >>>> >>>> Am i right? >>>> >>>> Greetz, >>>> David >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> spamdyke-users mailing list >>>> [email protected] >>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>>> >>>> >>>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
