You're going to get bounce blowback anyhow, whether you use SAV or not. Using Recipient Address Validation (or any kind of reject at the gateway level without first scanning for spam) would also increase blowback if junk mail is being sent via relays.
No Address validation at the gateway - this seems to result in the fewest bounces: Spammer -> relay (accepted) Relay -> you (accepted) <spam filtering swallows most of the junk> Backend server -> bounce if invalid recipient (bad but most of the junk has been eliminated by this stage) Spammer -> you (accepted) <spam filtering swallows most of the junk> Backend server -> bounce if invalid recipient (bad but most of the junk has been eliminated by this stage) ---------- Recipient Address Validation at the gateway: Spammer -> relay (accepted) Relay -> you (denied because of invalid recipient) Relay to forged sender -> bounce (bad) Spammer -> you (denied because of invalid recipient) --------- Sender address validation at the gateway: Spammer -> relay (accepted) Relay -> you (denied because of invalid sender) Relay to forged sender -> bounce Spammer -> you (denied because of invalid sender) Looks like the best (most ethical?) strategy is to swallow all email and never bounce or reject anything. That could put a huge load on your internet pipe and spam filtering boxes. But rejecting / bouncing at the earliest possible stage is, from the viewpoint of the person doing it, a very sane and rational strategy. It saves them bandwidth and resources on their gateway boxes. Note also that my comments on relays also apply to the use of DNSBLs at the gateway. So, mail relays are bad, ISP's backup MX servers are bad, etc, etc. It's a no-win situation, alas. Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 11 March 2007 12:32 To: Kelly Jones Cc: freebsd-questions@freebsd.org; users@spamassassin.apache.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Tool for validating sender address as spam-fighting technique? 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! 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. --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 "[EMAIL PROTECTED]", 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: <[EMAIL PROTECTED]> > 250 Ok > RCPT TO: <[EMAIL PROTECTED]> > 550 <[EMAIL PROTECTED]>: Recipient address rejected: 5.1.1 > <[EMAIL PROTECTED]>... User unknown > QUIT > 221 Bye > Connection closed by foreign host. > > This tells me [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]" (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.
