Date: Sun, 11 Mar 2007 12:41:48 -0600 From: "Chad Leigh -- Shire.Net LLC" <chad@shire.net> To: Justin Mason <jm@jmason.org> Cc: User Questions <freebsd-questions@freebsd.org> Subject: Re: Tool for validating sender address as spam-fighting technique? Message-ID: <2B018128-F951-41DF-8EFD-123119E9987C@shire.net> In-Reply-To: <20070311123142.A326032CD9@radish.jmason.org> References: <20070311123142.A326032CD9@radish.jmason.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: > > for what it's worth, I would suggest *not* adopting this > as an anti-spam technique. > > Sender-address verification is _bad_ as an anti-spam technique, in my > opinion. Basically, there's one obvious response for spammers > looking to > evade it -- use "real" sender addresses. Where's an easy place to find > real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. > > Hence, the spam recipients now get twice as much mail from each > spam run > -- spam aimed at them, *and* bounce blowback from hundreds of spams > aimed > at others, forged to appear to be from them. It's the obvious > response to > SAV, which is one reason why we never implemented something like > that in > SpamAssassin. Sorry, but you conclusion does not follow. Sender verification has been around for a while and this has not happened in my experience. Ie, there is no greater use of real FROM addresses than there was before. Most MTAs have in-built routines to do this, with exim having a particularly good facility for this. Technically, with exim's, you are actually validating the sending server's adherence to the RFCs about accept DSN replies back. Chad > > --j. > > Kelly Jones writes: >> To fight spam, I want to validate the address (not necessarily in >> real-time) of the a given email sender. Is there a Unix tool that >> does >> this? >> >> The basics are simple: to validate "kmnyqi@wnonline.net", I >> connect to >> the MX record of wnonline.net and go as far as "RCPT TO" as follows: >> >>> host -t mx wnonline.net >> wnonline.net mail is handled by 5 wnspf.bayou.com. >> >>> telnet wnspf.bayou.com. 25 >> Trying 209.209.192.75... >> Connected to wnspf.bayou.com.. >> Escape character is '^]'. >> 220 Welcome to Bayou mxfilter >> HELO domaintester.com >> 250 mxfilter.bayou.com >> MAIL FROM: <test@ignoreme.com> >> 250 Ok >> RCPT TO: <kmnyqi@wnonline.net> >> 550 <kmnyqi@wnonline.net>: Recipient address rejected: 5.1.1 >> <kmnyqi@wnonline.net>... User unknown >> QUIT >> 221 Bye >> Connection closed by foreign host. >> >> This tells me kmnyqi@wnonline.net is an invalid address and that mail >> from that address is probably bogus. >> >> A more sophisticated tool would cache results, handle temporary >> failures (eg, inability to connect to the MX server), handle multiple >> MX records, perhaps even publish results [carefully, to avoid giving >> spammers a source of legit email addresses!], etc. Plus, I'd >> prefer to >> use a tested tool vs hacking something up myself. >> >> I realize this technique is far from perfect: >> >> Spammers spoof legit addresses >> >> Bounces/Mailing lists/etc legitimately use "do not reply" addresses >> >> It could be considered unfriendly to the target MX servers >> >> Some mail servers incorrectly say "user unknown" when they see spam, >> figuring it's more of a deterrent than saying "you're a spammer" >> >> Some mail servers inefficiently accept mail for "foo@xxx.com" (where >> xxx.com is one of their domains), figure out if foo exists later, and >> send a bounce back to the envelope sender, instead of rejecting email >> at the SMTP level (a really good tool would create throwaway >> addresses >> to catch these cases too) >> >> ... but I still think it might help. >> >> -- >> We're just a Bunch Of Regular Guys, a collective group that's trying >> to understand and assimilate technology. We feel that resistance to >> new ideas and technology is unwise and ultimately futile. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions- > unsubscribe@freebsd.org" --- 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?2B018128-F951-41DF-8EFD-123119E9987C>