From: "Christopher Hilton" <[EMAIL PROTECTED]>
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}
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
