North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Possibly OT, definately humor. rDNS is to policy set by federal law.

  • From: Rich Kulawiec
  • Date: Sat Mar 17 10:07:40 2007

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  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  All of them obligingly try
to open up simultaneous SMTP connections to's MX's.
How many do you think will be required before 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.