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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
