Re: Verizon hosting spammers :)

[Kelson Vibber]

This was sent to me off-list.  It's an interesting look at the 
implications of doing callbacks:

Rich Kulawiec wrote:
> If you wouldn't mind forwarding this back to the list (your message
> was forwarded to me off-list)...
>
> On Tue, Jan 18, 2005 at 09:25:18AM -0800, Kelson wrote:
>
>>Actually, I suspect those are (misguided?) attempts at sender
>>verification*.  We get hammered by those too, and they're always** from
>><> or [EMAIL PROTECTED]  We know spammers are forging our
>>domain name in the return address, using randomly-generated addresses
>>which look just like the unknown users Verizon is trying to reach.
>
>
> You're exactly right -- and it's worse, as we've dissected on spam-l
> a couple of times.
>
>
> What Verizon is doing is known as a "callback".  This technique comes
> from people who have confused "spam" and "forgery" and are operating
> under the very mistaken notion that doing something about the latter
> will have any impact on the former.
>
> It works like this:
>
> When an incoming SMTP connection is made to one of Verizon's MX's,
> they allow it to proceed until the putative sender is specified,
> i.e., they wait for this part of the SMTP transaction:
>
> 	MAIL From:<[EMAIL PROTECTED]>
>
> Then they pause the incoming connection.  And then they start up an
> *outbound* SMTP connection from somewhere else on Verizon's network, back
> to one of the MX's for example.com.  They then attempt to verify that
> "blah" is a valid, deliverable address there.  But since most people have
> long since (sensibly) disabled SMTP VRFY, they actually construct a 
message
> and attempt delivery with RCPT.  If delivery looks like it's going to
> succeed, they hang up this connection (which is rude), and un-pause
> the incoming one, and allow it to proceed.  If delivery looks like
> it's going to fail, then they also hang up the connection (still rude),
> un-pause the incoming one, and reject the traffic.
>
> In words, Verizon is faking mail -- thus generating yet more junk SMTP
> traffic at a time when we're drowning in junk SMTP traffic -- to do this.
>
> This also means that if the MX they try to connect to is (a) busy
> (b) down (c) unaware of all the deliverable addresses (d) something
> else, that they'll refuse the incoming message.
>
> Whoops!
>
> Real-world example: "[EMAIL PROTECTED]" is where mail from the 
support
> staff at Thule Racks comes from.   However, it doesn't accept mail -- 
which
> is arguably a bad practice on Thule's part, but is not a good reason for
> Verizon to aggravate the problem by rejecting it.
>
> This (callbacks) is bad for a whole bunch of reasons: two of the more 
obvious
> ones are (a) it's a pathetic "anti-spam" measure because ANY forged 
address
> ANYWHERE will do, and (b) it doesn't scale.  Add to that (c) it abuses
> RCPT because apparently Verizon is unwilling to use VRFY and to accept
> the decision of many/most mail server operators to disable it.  Oh, and
> (d) the behavior of their probe systems is nearly indistinguishable from
> that of spam-spewing zombies, which don't obey the SMTP protocol either,
> and also rudely hang up connections in mid-transaction.
>
> But there's a not-so-obvious reason that this goes beyond mere silliness
> and into the realm of active support for spammers.
>
> A lot of people, including me, are blocking particularly problematic
> spammer-controlled networks at (a) our border routers (b) our firewalls
> or (c) our mail servers.  In other words, we not only won't accept mail
> from them, we won't even allow them to connect: we're blocking *all* IP
> traffic from them.  This prevents them from spamming; it also prevents
> them from building lists of deliverable addresses to sell to other 
spammers
> by poking at our mail servers.
>
> Now go back and look at what Verizon's doing.  Since Verizon is doing
> this testing *from their network*, spammers can easily get around all
> of our blocking by getting Verizon to do the probing for them.  For free.
> Anonymously.  They can thus use Verizon to build/check their lists...and
> there's no way for us to find out who's on the other side of these 
probes.
>
> Which means that Verizon is running a free, anonymizing, spam support
> service.
>
> And even this isn't the end of it.  I'll spare you the entire analysis
> (which may be found in the Spam-L archives) but another unpleasant side
> effect of this tactic is that it's possible to exploit it to conduct
> DoS attacks against third parties.
>
> 	If they don't cache the results: then they have no way of knowing
> 	that they've already queried for any given address (and what the
> 	result was) and thus no way of avoiding repeat queries for the
> 	same thing.  I trust it's obvious why that poses serious problems.
>
> 	If they do cache: then what happens when someone behind
> 	an ordinary 500-million message spam run decides to forge
> 	500 million unique addresses in example.com, including
> 	[EMAIL PROTECTED], and a few hours, later, someone who
> 	operates the _real_ example.com creates the perfectly valid
> 	address little-suzie?  (That is, if they've managed to survive
> 	the DDoS attack launched at them by all the sites doing callbacks.)
> 	And if they rate-limit the queries, what happens to the 1 piece
> 	of legitimate mail from example.com that happened to be sent at
> 	the same time as this spam run?
>
> It's unclear (to those of us outside Verizon) what can be done about 
this:
> refusing their probes will cause them to reject incoming mail.  We've 
debated
> whether we should just answer them all in the affirmative so that the 
technique
> is rendered useless, but that has its drawbacks too.
>
> So for now all we can do is explain that it's causing problems and try to
> deal with it.
>
> Check your logs for stuff like this (example from sendmail 8.13):
>
> Jul 15 07:24:51 <[EMAIL PROTECTED]>... User unknown
> Jul 15 07:24:51 lost input channel from sc014pub.verizon.net 
[206.46.170.58] to MTA after rcpt
> Jul 15 07:24:51 from=<[EMAIL PROTECTED]>, size=0, 
class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc014pub.verizon.net 
[206.46.170.58]
>
> That's them.
>
>
> ---Rsk