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 antispam[0-9]+@west.verizon.net. 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:<blah@example.com>
>
> 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: "support@thuleracks.com" 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
> little-suzie@example.com, 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 <XXXXXXXXXXXXXXXXX@gsp.org>... 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=<antispam332078@west.verizon.net>, size=0,
class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc014pub.verizon.net
[206.46.170.58]
>
> That's them.
>
>
> ---Rsk
|