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

[ message continues ]

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

[ message continues ]

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 ...
[ message continues ]

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[29949]: 85.152.224.147: disconnected after 42673 seconds.

[ message continues ]

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

[ message continues ]

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

[ message continues ]

I'm interested to see your scripts

[ message continues ]

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[29949]: 85.152.224.147: disconnected after 42673 seconds.

[ message continues ]