Sam Clippinger wrote: > With regard to recipient validation, it's probably feasible to make > spamdyke use external helper scripts. But since three or four > configurations are most common (plain qmail, vpopmail, vpopmail+MySQL, > Plesk), those situations need to be handled by a stock spamdyke > installation. Maybe that means incorporating the code directly into > spamdyke, maybe it just means providing pre-built scripts to do the > work, I'm not sure yet. Perhaps spamdyke could incorporate code to > cover the most common situations and provide the ability to call > external scripts for more exotic configurations?
Putting some validro scripts/sources in a /contrib would do just the same without tampering into spamdyke. Just like you have a big bunch of authenticator helpers included into squid. 98% of people will just choose one and compile it. The rest can write it's own code. > > With regard to address farming, I understand the concept but I'm curious > how common it really is (or how common we think it is)? My impression > of modern spammers is that they scrape addresses from web pages > (especially mailing list archives and domain registrations) or get the > big ISPs to sell their addresses, then just send mail indiscriminately. > Do they really conduct dictionary attacks to find new addresses? I know > it's possible but since they don't care about bounces or SMTP rejections > (I see them send to the same stupid invalid addresses endlessly), is > anyone really farming? It's not just about farming. It is also about helping spammers keep their mail db up to date. Fully rejecting invalid recipients helps them clean up their db and send spam more efficiently and it's harder to filter. Not all spammers maintain them of course but it is an issue... > > I'm not sure I understand your suggestion about log queuing, sorry. :) I was just thinking about way to help people implement custom filters while not changing/tampering too much in spamdyke. A possible approach would be to enable it to do special logging/queuing of events. Think about it as a special non-syslog logging facility from a programmers point of view. Less need to make it human readable, you can add more info that you usually do not want to hog up your system log files and you can remove them after doing your stuff with it. There are multiple wayt to implements it. A few of them: - one file for every event (needs fast processing but allows fast response) - dedicated and rotated logs files (less responsive but need less IO) - named pipe (no hdd, fast response, but depends on the analyzing system to be alive). Regards Bgs > > -- Sam Clippinger > > Bgs wrote: >> Many mails, one sum up answer :) >> >> rcpt validation >> --------------- >> I think the best approach is not building into spamdyke a zillion >> methods to do it, but make it able to call an outside application to get >> the list. >> >> 1) spamdyke could periodically (configurable) re-run the application to >> refresh the list. >> 2) send HUP/USR1 or alike to interactively update >> 3) You can have whatever way to construct the list, you could even daisy >> chain multiple ones. >> >> Simplest approach is: run the application that outputs an email list. >> Wildcards are the only things to think over IMHO. >> >> Of course it would be nice to have a /contrib in spamdyke with the most >> popular applications. This could be user contributed too. >> >> >> Address farming >> --------------- >> >> This is a story that has two sides. farming vs. better filtering. An in >> between option would be to have a 'silently-drop' option for invalid >> addresses. Invalid addresses 'go to /dev/null'. Of course you will loose >> legitimate mistyped address bounces, but with smtp you can't have >> everything :/ >> >> 1) filter invalid rcpt >> pro: less spam >> con: mail address farming >> 2) do not filter >> pro: no farming >> con: additional spam >> 3) silently filter >> pro: no farming, less spam (better than 1) because of no farming) >> con: no legitimate bounce >> >> >> blacklisting and alike >> ---------------------- >> >> Following the rcpt validation line, I have a suggestion. Instead of >> building different approaches into spamdyke (custom scripts brought into >> the code), it might be feasible to have a log queuing mechanism in >> spamdyke. It would just queue information somewhere and leave the logic >> to the admin. Custom filtering, *list building, etc. methods can be >> constructed and the same app can also update spamdyke-s config. >> >> Just my .02$-s >> >> >> Regards >> Bgs >> _______________________________________________ >> 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
