From owner-freebsd-stable@FreeBSD.ORG Tue Dec 19 17:46:27 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 C811D16A40F for ; Tue, 19 Dec 2006 17:46:27 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from corellia.vindaloo.com (corellia.vindaloo.com [64.51.148.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 728CD43C9F for ; Tue, 19 Dec 2006 17:46:27 +0000 (GMT) (envelope-from chris@vindaloo.com) Received: from yavin.vindaloo.com (yavin.vindaloo.com [172.24.144.34]) by corellia.vindaloo.com (Postfix) with ESMTP id B4A045C47; Tue, 19 Dec 2006 12:46:26 -0500 (EST) Received: from [172.24.145.69] (endor.vindaloo.com [172.24.145.69]) by yavin.vindaloo.com (Postfix) with ESMTP id 5449724C4D; Tue, 19 Dec 2006 12:46:26 -0500 (EST) Message-ID: <45882572.7040707@vindaloo.com> Date: Tue, 19 Dec 2006 12:46:26 -0500 From: Christopher Hilton User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: JoaoBR References: <200612191227.kBJCRRLJ054427@lurza.secnetix.de> <4587D1B6.6060500@andric.com> <200612191146.45521.joao@matik.com.br> In-Reply-To: <200612191146.45521.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org 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 17:46:27 -0000 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. -- Chris