Hi Chad

>What I don't get is how you got spamd to pickup the white listed 
>entries on both boxes?  AFAIK spamd does not look at the logs, simply 
>puts entries in, does not read them.

I must admit I haven't deliberately studied it, but I was going on the
contents of man (8) spamlogd which says:

spamlogd manipulates the spamd(8) database in /var/db/spamd used for
     spamd(8) greylisting.  spamlogd updates the /var/db/spamd whitelist
en-
     tries whenever a connection to port 25 is logged to the pflog(4)
inter-
     face.  The source addresses of inbound connections are whitelisted
when
     seen by spamlogd to ensure that their entries in /var/db/spamd do
not
        expire if the connecting host continues to send legitimate mail.
The     destination addresses of outbound connections are whitelisted
when    seen by spamlogd so that replies to outbound mail may be
received        without initial greylisting delays (see GREYLISTING in
spamd(8)).

Maybe the critical phrase is when "logged to the pflog(4) INTERFACE"

I just assumed that cross logging would enable spamlogd to pick this up
on other boxes - but now I'll have to examine whether this is truly the
case. It may have occurred on the other box as a result of manually
synchronising the whitelists and blacklists on the individual boxes, and
then updating the in-memory tables with "pfctl -t spamd -vT add
xxx.yyy.zzz.www" and
"pfctl -t spamd-white -vT add aaa.bbb.ccc.ddd"

To find the whitelistings in my /var/log/spamd file I just use a simple
grep like "grep whitelisting /var/log/spamd" in the combined spamd log
file. For clever buggers like every other user of OBSD except myself, it
would be a relatively trivial exercise to script this to update both the
personal whitelists and the in-memory pf tables (and perhaps use some
mechanism to automatically update on other mailservers (maybe NFS
sharing or something???)

>I think I would want grey listed tuples included as well.  If behind 
>the primary MX were say 3 boxes and the load balancer was not always 
>directing the sending MTA to the same box running spamd, the sending 
>MTA could get delayed for a very long time.  While load balancers have 
>persistence, those usually have a timeout period, which MTA retries 
>will probably exceed.

I can't specifically think of a way to add the grey listing tuples to
another machine, because AFAIK spamdb only accepts the -a (add) and -d
(delete) flags. I examine the grey lists with "spamdb | grep GREY" but
how it might be passed to a spamdb database on another machine I'm not
sure. It might be possible to directly manipulate the database through
some means, but I'm reaching the limits of my 65 point IQ level here.

Sorry I can't be of any more specific assistance at present, but I have
problems typing and remembering to breathe simultaneously.

Cheers
Phillip

Reply via email to