From owner-freebsd-questions@FreeBSD.ORG Wed Mar 14 03:30:25 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F391016A400 for ; Wed, 14 Mar 2007 03:30:24 +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 A1DFC13C457 for ; Wed, 14 Mar 2007 03:30:24 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from [172.24.144.91] (dhcp-1b.vindaloo.com [172.24.144.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by corellia.vindaloo.com (Postfix) with ESMTP id B618F5CA1; Tue, 13 Mar 2007 23:30:23 -0400 (EDT) Message-ID: <45F76C4B.5070905@vindaloo.com> Date: Tue, 13 Mar 2007 23:30:19 -0400 From: Christopher Sean Hilton User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Chad Leigh -- Shire.Net LLC" References: <20070311200829.31802.qmail@simone.iecc.com> <0AC225E6-E55D-4C20-9A00-2EDD95985848@shire.net> <20070311165028.S44863@simone.iecc.com> <45F57936.3030601@usm.cl> <1173830431.1588.34.camel@dagobah.vindaloo.com> <30DC016D-CA46-44D1-A12D-00BDD723A71D@shire.net> In-Reply-To: <30DC016D-CA46-44D1-A12D-00BDD723A71D@shire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Marcelo Maraboli , User Questions Subject: Re: Tool for validating sender address as spam-fighting technique? 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: Wed, 14 Mar 2007 03:30:25 -0000 Chad Leigh -- Shire.Net LLC wrote: > > On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote: > >> On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote: >> >>> >>> I agree..... callbacks are not enough, you can reach a >>> false conclusion, thatīs why I use SPF along with callbacks... >>> >>> on the same message, my MX concludes: >>> >>> "you are sending email "from chad@shire.net", but shire.net >>> says YOUR IP address is not allowed to send email on behalf >>> of that domain, therefore YOU ARE FAKE/FORGED" ..---> reject >>> >>> regards, >>> >> >> I'm not sure what you mean by callbacks but if that involves talking to >> mx.example.com and trying to figure out if cmdr.sinclair@example.com is >> a valid address go ahead. I would consider a mailserver that answers >> that question a security risk as it is freely giving away information >> about your domain without notifying you. For a long time my mx servers >> would answer any such question in the affirmative regardless of whether >> or not the mail account existed. > > Address verification callbacks take various forms, but the way exim does > it by default is to attempt to start a DSN delivery to the address and > if the RCPT TO is accepted it is affirmative. It is not usually use > VRFY. Most address verification is done by attempting to start some > sort of delivery to the address. > I'm assuming that DSN is Delivery Service Notification or return receipt. If it is or if it somehow relies on the ability to deliver a message via smtp to *@example.com then I don't see how it prevents spam. >> >> As the above poster says SPF is the way to go. SPF gives the receiving >> MTA a mechanism to vet inbound mail. For any combination of > server> and there are three possible results >> from an SPF check: The server is allowed to send mail for the domain; >> The server is not allowed to send mail for the domain; And I cannot tell >> because the owner of the domain hasn't published an SPF record. The only >> problem with SPF is that it's not more widely implemented so the third >> response is sadly more common than the first two. > > I believe it also breaks when you have forwards. > I'm not sure that I would classify it as breakage. I always confuse these but there is a problem with SPF vis-a-vis remails or old style bounces of messages. The delivery from address specified as mail-from in the smtp dialog and the envelope from specified in the mail's headers will differ. And the one that SPF checks is the smtp dialog mail-from address. So a spammer can setup SPF for his domain and mail will false positive in the SPF check but the MTA can add a header which lists the original sender. E.g. jrandomspammer@spamsource.com lists himself as the sender of a mail and lists smtp.spamsource.com as a valid source of mail for his domain. He crafts an email with a from address of curry@example.com and fires is off to you. I'm fairly certain that my MTA, postfix, will add an Original-Sender: jrandomspammer@spamsource.com header to any message that comes in under these circumstances. I wouldn't be surprised if my Bayes filter is keying on this header. In the end internet email is built on a flawed protocol. It'd be great if you could verify that the letter that you got passed was really sent by the person who name was really sent in the mail-from part of the smtp handshake but you can't. For my part I neither want to burden people who want to send me email with the chore of having to vet themselves nor wade through excessive amounts of spam. I greylist with spamd and then filter with spamassassin and it's Bayes filter. I find that this combination works very well at negligible cost to people who want to send me mail. YMMV -- Chris __o "All I was doing was trying to get home from work." _`\<,_ -Rosa Parks ___(*)/_(*)___________________________________________________________ Christopher Sean Hilton chris | at | vindaloo.com pgp: f5:30:0a:54:e1:55:76:9b:1f:47:0b:07:e9:75:0e:14