From owner-freebsd-stable@FreeBSD.ORG Tue Dec 19 18:53:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8AF816A416 for ; Tue, 19 Dec 2006 18:53:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A08B543CD4 for ; Tue, 19 Dec 2006 18:53:08 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kBJIoeHC044828 for ; Tue, 19 Dec 2006 15:50:41 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Tue, 19 Dec 2006 16:52:48 -0200 User-Agent: KMail/1.9.4 References: <200612191227.kBJCRRLJ054427@lurza.secnetix.de> <200612191146.45521.joao@matik.com.br> <45882572.7040707@vindaloo.com> In-Reply-To: <45882572.7040707@vindaloo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612191652.49110.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: OpenBSD's spamd. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 18:53:24 -0000 On Tuesday 19 December 2006 15:46, Christopher Hilton wrote: > 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. > > The tarpitting features of spamd are handy. Bob Beck, the author IIRC, > watched connections to his spamd and noticed that the when tarpitted, > the spammers and only the spammers were disconnecting from his machine > and giving up on delivering the spam at all after ever shorter > intervals. When the spammers got down to 3 seconds of tarpitting before > they disconnected he added a feature to spamd that allows you to tarpit > all inbound smtp connections for a configurable period of time (default: > 10 seconds). > > So imagine being able to eliminate a portion of the spam that you get. > This is spam that never gets to your MTA. It doesn't cost you CPU cycles > in SpamAssassin and procmail or clamav. And all you pay is three seconds > of the your firewall's time. > opss, so your spamd must be ports/mail/spamd then, thank's for clarification I dont know if it is a good solution even if it works. I am completly=20 satisfied using sendmails ClientRate and greeting delay features and I do n= ot=20 need an additional software to take care of. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br