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?
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? I'm not sure I understand your suggestion about log queuing, sorry. :) -- 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
