Date: Tue, 13 Mar 2007 20:11:42 -0600 From: "Chad Leigh -- Shire.Net LLC" <chad@shire.net> To: Christopher Sean Hilton <chris@vindaloo.com> Cc: Marcelo Maraboli <marcelo.maraboli@usm.cl>, User Questions <freebsd-questions@freebsd.org> Subject: Re: Tool for validating sender address as spam-fighting technique? Message-ID: <30DC016D-CA46-44D1-A12D-00BDD723A71D@shire.net> In-Reply-To: <1173830431.1588.34.camel@dagobah.vindaloo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=B4s 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 =20 > talking to > mx.example.com and trying to figure out if =20 > 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 =20 > whether > or not the mail account existed. Address verification callbacks take various forms, but the way exim =20 does it by default is to attempt to start a DSN delivery to the =20 address and if the RCPT TO is accepted it is affirmative. It is not =20 usually use VRFY. Most address verification is done by attempting to =20= start some sort of delivery to the address. > > 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 <mail > server> and <from address/from domain> there are three possible =20 > 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 =20= > tell > because the owner of the domain hasn't published an SPF record. The =20= > 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. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30DC016D-CA46-44D1-A12D-00BDD723A71D>