Hi. I've been using spamd in blacklist only mode for several years in FreeBSD but gave greylisting a try today and I use version 4.1.2. I've been studying the OpenBSD man pages as well as FreeBSD's and whatever information Google turned up. A general reflection is that it's a little hard to grasp from the man pages how all the components work together (spamd, spamlogd, spamd-setup, spamdb, pf) especially when you're only used to blacklisting like I am. But everything seems to be working just fine now. However, I'm confused about the purpose of spamd-setup in greylisting mode. * There is no longer a <spamd> table to fill with blacklisted IP addresses. * Addresses being whitelisted in spamdb are automatically moved to <spamd-white> even if I don't run spamd-setup. * spamdb does NOT get populated with any blacklisted IP addresses when I run spamd-setup. So exactly what does spamd-setup do in greylisting mode? Do I need it? One more question. If I want to blacklist an IP address manually I assume I use "spamdb -T -a ip-address". That creates a SPAMTRAP record in the database at least. Is this the same as blacklisting? If it is, why doesn't the various blacklists in spamd.conf show up here then? How are those lists handled in greylisting mode? Thank you. /Morgan
I just had to do the same (on OpenBSD, though). I do find the man pages quite complete, to be honest. It may be not a step-through guide on all topics, but once I took myself the time to actually read it all through, yes, as explained in spamd(8): "spamd regularly scans the /var/db/spamd database and configures all whitelist addresses as the pf(4) <spamd-white> table" This is required so that whitelisted IPs can bypass spamd entirely using No, because you don't need it. Everything that is not in the state of spamd-setup(8) "The spamd-setup utility sends blacklist data to spamd(8), as well as No, if you'd like to blacklist an IP manually, you can either do so by using a custom pf table (e.g. mywhite) that omits redirection from that table to spamd. Or, the way we do it, we compile our own list and configure/load it in spamd.conf(5): "The spamd.conf file is read by spamd-setup(8) to configure blacklists They are loaded using spamd-setup and fed into spamd(8). Hope that helps, -- Stephan A. Rickauer ----------------------------------------------------------- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 Zurich Web www.ini.uzh.ch
Thank you for your answers Stephan. Please bear with me because I come from the land of blacklisting only :-) In general I'm very pleased with the BSD man pages but when I try to learn new functionality I find myself looking for details I probably only can get if I read the actual source code and I understand its place Yes, but what does that mean? Does spamd keep an internal list of blacklisted IP addresses and why is it not in the spamd database in that case (which seems a natural place for it)? Can I see it somewhere and Ok, that is of course obvious now when I read it :-) Still curious of _how_ it's actually done. Does this somehow has to do with the fdescfs filesystem that has to be mounted? I believe I read somewhere that the interaction with the tables are done through this filesystem. Why not use the API that pfctl use? I really feel like a jerk asking these I understand the states GREY and WHITE but what exactly is TRAP and SPAMTRAP if they're not the blacklisted addresses? I read the section GREYTRAPPING in spamd(8): "When running spamd in default mode, it may be useful to define spamtrap destination addresses to catch spammers as they send mail from greylisted hosts....<snip>" I haven't slept tonight so I simply don't understand what this paragraph is saying or what its purpose is? Can I enter "fake" email addresses here and if a GREY host happens to send a mail to this fake address, that host gets blacklisted? How big is the chance that it would try a fake random address I enter here...? (LOL, I can imagine you have a good Yes :-) "Blacklist data" - is that the IP addresses collected from the I can still maintain a local blacklist file that I load in spamd.conf as I have done since I started using spamd then? I was excited for a while that I could drop that file and enter the IP addresses permanently in the spamd database instead but the local file is fine with me since I know how it works. I just feel uncomfortable not being ...
This is where you may find a major source of entertainment. Yes, you can enter bogus addresses in the traplist. Yes, the easiest way to decide what to put in your traplist is to harvest from the joejob-generated bounce messages that keep piling up. For good measure, you can publish your list of spamtraps on the web and sit back and laugh at tail -f /var/log/spamd. My spammer traps are at <http://www.bsdly.net/~peter/traplist.shtml>, a series of blog posts about this very topic starts with the post <http://bsdly.blogspot.com/2007/07/hey-spammer-heres-list-for-you.html> and my newest spamd entertainment can be found at my still-fresh "Name and Shame Robot" page, <http://www.bsdly.net/~peter/nameandshame.html>. The name and shame part means essentially now that we have a list of IP addresses that have verifiably tried to deliver mail to our spamtraps, it is trivial to extract the log data of each of those addresses' actions from our spamd log. To the extent that the admins involved actually can be bothered to look, it's also a bit clearer evidence that they may have, er, potential for improvement than if we were just using the raw list of IP addresses. Socially responsible sysadmins, y'know. I infer from certain characters in your name and message headers that you're .se based, so my almost-done Norwegian writeup about the name and shame robot at <http://www.bsdly.net/~peter/nameandshame_no.txt> might provide some entertainment despite the funny spelling (I'm pondering compressing this to a third of the size for publication in one of the IT rags, and yes, I may even rewrite this in English given enough round tuits). - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd: 188.8.131.52: disconnected after 42673 seconds.
Simply lovely. The creativity of the developers never stops to amaze me. :-) And yes, I'm .se. I'll make sure to read the links you referred to. Still have 3 days left on my vacation so they will come in handy... thanks again for your help! /Morgan
I (and others) use variations on a slightly different approach... When spammers apparently started to generate their target addresses from parts a'la: AnastasiabeetRansom AnastasiacartonGrover : SavannahenthusiastGrover SavannahkobayashiRansom i found the SPAMTRAP mechanism too simple since it uses exact matches of the addresses and the spammers generated addresses had too much variation. A "greyscanner" script has the possibility to be more "intelligent". In my case I use a modified greyscanner script [original]: http://www.ualberta.ca/~beck/greyscanner/ my modifications are extended DNS checks and mail address checking using an address pattern file. I use newsyslog to make the maillog rotation process /var/log/maillog.0 to find "User unknown" lines. Hosts mailing to unknown addresses are removed from spamd-white. Unknown addresses are saved in a sort -u file. The saved unknown addresses are then processed to find address prefixes and postfixes into a file a'la: ^Anastasia ^Savannah Grover$ Ransom$ My modified greyscanner script then use these prefixes and postfixes for address validation when processing the spamdb database. I can publish the scripts if anyone is interested. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
I'm interested to see your scripts
Those script sound very interesting. I'd love to see them. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd: 184.108.40.206: disconnected after 42673 seconds.