Date: Sun, 11 Mar 2007 18:11:54 -0500 From: Jeffrey Goldberg <jeffrey@goldmark.org> To: Kelly Jones <kelly.terry.jones@gmail.com> Cc: nmosug-l@mailman.swcp.com, linuxusersgroup@googlegroups.com, freebsd-questions@freebsd.org, nmlug@nmlug.org, users@spamassassin.apache.org Subject: Re: Tool for validating sender address as spam-fighting technique? Message-ID: <F2BD9F36-2B4D-4EA0-9EF1-1C3A627EDA3D@goldmark.org> In-Reply-To: <26face530703101127l558d2db7y54ddb6674d663383@mail.gmail.com> References: <26face530703101127l558d2db7y54ddb6674d663383@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[mailed and posted] On Mar 10, 2007, at 1:27 PM, Kelly Jones wrote: > 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: > [...] > RCPT TO: <kmnyqi@wnonline.net> > 550 <kmnyqi@wnonline.net>: Recipient address rejected: 5.1.1 > <kmnyqi@wnonline.net>... User unknown > > > 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 [...] In some anti-spam discussions what you are proposing is referred to as "call-backs". > I realize this technique is far from perfect: > > Spammers spoof legit addresses Indeed they do. As someone who has at times received more than 100 bounces per minute over the span of a week because some spammer decided that my address would be a good one to forge, I am well aware of that. In general, we have a question of how well any spamming counter measure scales. If most SMTP servers did the kind of verification you wish to do, than most spam would be sent with forged genuine addresses. So when considering using such a system, consider the overall cost to legitimate users vs the counter counter measures spammers will take. In this case the counter counter measures available to spammers is so much easier and cheaper than the verification system itself, that it's not really a good idea to try such verification. > Bounces/Mailing lists/etc legitimately use "do not reply" addresses > > It could be considered unfriendly to the target MX servers As you've already seen, some managers of MXes complain, others find the added load negligible. > Some mail servers incorrectly say "user unknown" when they see spam, > figuring it's more of a deterrent than saying "you're a spammer" Yes. An unknown user response is more likely to get the address removed from a list than a policy bounce. > 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 Yes. While I'm a believer in "reject early, reject often" lots of sites don't or can't say that an address is bad at SMTP RCPT TO: time. Often these are situations where an MS-Exchange server is the "real" mailhub for an organization, but it is being protected from direct access from the Internet by having a Unix box stand between it and the network. Other MTAs just accept and then bounce (instead of rejected at SMTP time) as a matter of (mis)design. Some very deliberately don't provide verification at STMP time as a means to make it harder for spammers to collect email addresses. Indeed, this is why the VRFY command is almost never implemented by STMP servers these days. Anyway, others have pointed you to tools for doing what you want. The newsgroups or mailing lists (and FAQs) for the particular MTA you use will point you to how to plug in such tools into their MTA. As I've suggested, I'm not a particular fan of this particular counter measure, but you will have seen that opinions differ. Cheers, -j -- Jeffrey Goldberg http://www.goldmark.org/jeff/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2BD9F36-2B4D-4EA0-9EF1-1C3A627EDA3D>