On Sat, Mar 17, 2007 at 01:09:47PM +0000, Peter Corlett wrote:
Would you care to expand on why you think sender callback verification is apparently abusive and supports spam?
(a) this is wandering off-topic and (b) this has been covered in great depth on Spam-L multiple times, so I'll refer you there for more substantive discussion; consider this merely a brief overview whose points are not particularly well-ordered, although I'm going to try to list them from abstract-to-applied. 1. Is it really a good idea to allow unknown parties to cause *your* servers to generate outbound SMTP traffic to destinations of *their* choosing? I sure don't think so. 2. We're drowning in junk SMTP traffic. Any "solution" which creates *more* SMTP traffic is wrong. Not just bad, not just suboptimal, but flat-out wrong. The system desperately needs dampening, not positive feedback. And this is (another reason) why callbacks, C/R and bounces are all bad news. 3. What if everyone did this? Callbacks *do not scale*. As Alan Brown has pointed out: Because it doesn't scale against tens or hundreds of thousands of servers doing callouts against a single host which has had From: addresess forged - especially when you add in the factor that many spammers are mutating the left hand portion of the address with each mail sent - specifically to defeat caching mechanisms. 4. It's abusive because it's a deliberate attempt to circumvent an access control, somewhat like ignoring a robots.txt. The correct way to verify an address with SMTP is to use the VRFY command, not a dummy mail sequence. If I have VRFY off, then I have clearly announced to the world that I don't wish to provide a sender verification service. Yet those using callbacks are insisting on bypassing site security policy by forging a dummy mail message (since they have no intent to actually try to deliver one). IANAL but this seems to me to raise serious questions of legality. 5. Those using this "feature" are providing a free, anonymizing, scalable, spam support service. How? Because they're also enabling spammers to bypass my security mechanisms. Suppose I have firewalled out 1.2.3.0/24. Suppose X hasn't. Spammers can now use X's mail servers to attack mine. Well, and everyone else using callbacks: X and everyone else are now deliberately helping spammers go after third parties. And yes, they're doing it. 6 (7, 8, etc.) Callbacks enable multiple D/DoS attack mechanisms. Here's a simple one: attacker identifies N hosts using callbacks, where N is large enough to matter. Attackers forges mail to all of them claiming to be from victim-domain.com. All of them obligingly try to open up simultaneous SMTP connections to victim-domain.com's MX's. How many do you think will be required before victim-domain.com feels some serious pain? At the hands of those using callbacks. This is NOT a theoretical problem. And this alone is reason enough to stop doing callbacks immediately. (For more variations, including much nastier ones, see the Spam-L archives, but keep in mind that not all of them have been discussed publicly.) 7. Use of rate-limiting (sometimes advanced as a lame excuse for this abuse) enables other DoS attack vectors. So does result caching. (Example: if you only do X queries per Y time of any given domain's MX or any given MX, then an attacker can block traffic by making sure that forged traffic exceeds the rate limit. And so on.) 8. Consider that attackers can control where your outbound connections terminate. How? Register a throwaway domain, point the MX's at the victim, and then send *unforged* mail from the throwaway domain to you. Or set up an SMTP proxy which terminates on someone else's real mail server. Or which loops back to you. Or... There are also some decidedly nasty variations to this approach. There's more, but I said I'd be brief. The bottom line is that callbacks are an appallingly bad idea, right up there with C/R for boneheadedness. And as Bob O'Bob has pointed out, some receivers are starting to recognize callback abuse, and firewall off the offending hosts. It seems likely that public blacklists will be compiled and used if the originators of this abuse don't stop on their own. ---Rsk