On Thu, 15 Mar 2007, S. Ryan wrote:

Typical SORBS behavior. While this guy can demand all he wants, doesn't mean he will get what he wants or that he's right or wrong.

What's wrong with what Mat posted? The guy claiming DNS is regulated by federal law is an idiot. Not that I always agree with what Mat says, but the guy's claims are obviously and patently false. The claims, in fact, are so ridiculous that I tend to think he's making them to weasel out of solving the problem that got him listed in the first place. People doing that *deserve* to be publically ridiculed. When I talk to Mat I generally have no problems having a civil and productive discussion with him. But I don't start out with an attitude, and I don't cook up absurd stories to try to get out of fixing my spam problem. (Not that I have one, but if I did, I'd not try to weasel out of fixing it.)

Personally, we gave up using SORBS because of it's very high false-positive ratio

YMMV; at $DAYJOB we don't seem to have the same problem. Disclaimer: My opinions, not my boss's, etc. -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Victorville, California PGP:0xE3AE35ED It's all fun and games until someone starts a bonfire in the living room.

On Thu, 15 Mar 2007, S. Ryan wrote:

Oh and, of course publicly humiliating the guy is certainly not that cool. However, while it's not really above me to do the same, he could have removed the email address so spammers aren't adding to that guys list of problems.

Fair enough. -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Victorville, California PGP:0xE3AE35ED It's all fun and games until someone starts a bonfire in the living room.

On Thu, Mar 15, 2007 at 07:41:58PM -0700, S. Ryan wrote:

However, while it's not really above me to do the same, he could have removed the email address so spammers aren't adding to that guys list of problems.

Anti-spam strategies based on concealment and/or obfuscation of addresses are no longer viable. (For a variety of reasons, including harvesting from public sources, harvesting from private sources such as compromised systems, and the deployment of abusive, spam-supporting tactics such as callbacks/sender address verification.) Yes, I know there are counter-examples, I have my own collection of them. But they're exceptions, not the rule. ---Rsk

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

Peter Corlett wrote:

On 16 Mar 2007, at 18:21, Rich Kulawiec wrote:

...

[...] abusive, spam-supporting tactics such as callbacks/sender address verification.)

Would you care to expand on why you think sender callback verification is apparently abusive and supports spam?

I sure don't mind my MXers being probed if it stops somebody forging mail from my domains.

What next, will forward lookups of rDNS to verify that they're not forged also be considered abusive because the forged third-party's servers get consulted out of paranoia?

Also others didn't mention it doesn't actually work properly when other things are going on. Anywhere that is RBL'd when it tries to callback receives a message saying that delivery fails - this results in the outgoing mail not getting delivered (and I've had to deal with that problem several times where people are accusing SORBS of blocking their outgoing mail). DDoS attack is very understated, consider any SOHO... I have an 8M link here, 2m call backs will wipe out both my bandwidth for a few hours, as well as probably use up my monthly quota. Spammers who are blocked from my servers can use callback on your servers to determine what the real/working addresses are on my network. Rate-limiting on my servers is useless under callback attack (because it's not a DoS, but a DDoS). Many other things are bad about it... Read Spam-L and other lists for information. Regards, Mat

Steve Sobol wrote (on Thu, Mar 15, 2007 at 10:31:44PM -0400):

On Thu, 15 Mar 2007, S. Ryan wrote:

...

Personally, we gave up using SORBS because of it's very high false-positive ratio

YMMV; at $DAYJOB we don't seem to have the same problem.

I gave up using SORBS (and I'm not Mat's enemy, mind you - I used to work for SORBS and still like the idea) because it was so random. Mat would block 2, say, out of AOL's 26 or whatever mailservers. Why? b/c those two were used to send spam. Right. So, not only do I have to explain to users why their AOL friends cannot write them, I *also* have to explain that the blocking is at random, and if their friend just retrys sending, they'll have a 92% chance of getting through. Completely unworkable. If you want to block AOL (and I totally sympathize with Mat here) just ... block ... them and be done with it. Don't make me play email roulette. -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants