From owner-freebsd-questions@FreeBSD.ORG Tue Sep 18 07:56:45 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2122F16A41A for ; Tue, 18 Sep 2007 07:56:45 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id A744913C47E for ; Tue, 18 Sep 2007 07:56:44 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from TEDSDESK (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id l8I7uVvI082678; Tue, 18 Sep 2007 00:56:32 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Jay Chandler" , Date: Tue, 18 Sep 2007 00:56:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <46EF206B.90908@sequestered.net> Cc: Subject: RE: SMTP Error from my server? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 07:56:45 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Jay Chandler > Sent: Monday, September 17, 2007 5:49 PM > To: freebsd-questions@freebsd.org > Subject: Re: SMTP Error from my server? > > > > > This idea works fine for normal email addresses, but fails miserably > > with certain types of automated email which is not intended for people > > to reply to, and it also tends to lose out with TDMA > > (http://tmda.net/). More importantly, it also fails to work with > > itself-- other people using "sender verification callouts" cause a > > loop of failed deliveries, as neither side trusts the other. > > > The larger problem as well is that it doesn't scale. Someone forging a > From header out of a botnet could easily DDoS a smaller server > completely off the net if enough people implemented this system. > verizon.net implements this system and they are pretty big. They put in checks to the setup to prevent these scenarios from happening. I don't like these systems myself as a gatekeeper but it isn't true that these systems cannot scale. They can scale fine - at the cost of greatly increased complexity of the logic in the system. I will point out that Network Address Translation - a technology that people take for granted and scale up all the time - has a far worse increase in complexity (espically in implementations that handle translation of all the normally not translatable protocols) I would actually love to see someone implement sender-callback-verification as a module in Spamassassin, where callback checks could be assigned a point value. In other words, failing sender-callback wouldn't automatically get a message blocked - but failing would increase the point value of the message to make it more likely to be considered spam. > Antispam measures that are in and of themselves abusive aren't generally > considered to be good ideas. It all depends on the implementation. A good implementation of sender callback is no worse than a good implementation of greylisting, and a bad implementation of sender callback is as bad as a bad implementation of greylisting. Ted