Date: Tue, 19 Dec 2006 14:36:02 -0800 From: "jdow" <jdow@earthlink.net> To: <freebsd-stable@FreeBSD.ORG> Subject: Re: OpenBSD's spamd. Message-ID: <00b801c723be$106ce980$0225a8c0@wednesday> References: <200612191227.kBJCRRLJ054427@lurza.secnetix.de> <4587D1B6.6060500@andric.com><200612191146.45521.joao@matik.com.br> <45882572.7040707@vindaloo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Christopher Hilton" <chris@vindaloo.com>
> JoaoBR wrote:
>>
>> why the spam daemon should introduce an artificial delay
>> (tarpit) if this can be done already before like Oliver
>> said, it would only eat up and slow down threads between
>> both daemons (smtp + spamd) and overall spamd doesn't even
>> talk directly to the remote smtp
>>
>
> Spamd does talk to the remote smtp. It does this until it determines
> that the remote smtp is RFC compliant in the area of retrying mail. On
> the first delivery attempt it sets up a time window for the delivery
> tuple: (server, sender, recipient). If it receives another delivery
> attempt within this time window it modifies a PF table which allows
> further delivery attempts to bypass spamd and talk directly to your
> actual smtp daemon. Without this entry remote smtp daemons talk to your
> spamd.
Features aside I see a huge problem with something called spamd. That
is the same name as the daemon mode for SpamAssassin. It's not good
to have duplicated names that way. It makes life difficult when you
want to run both tools on the same system.
{o.o}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00b801c723be$106ce980$0225a8c0>