Re: Verizon hosting spammers :)

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


jdow writes:
> This probably explains the massive runs of emails with nothing in them
> that fetchmail is failing on when it attempts to drag them from NG_Popper.
> 
> I guess simply dropping Verizon on the floor is the simplest answer.
> Explain to users what you are doing and why. Verizon facilitating
> spam and DDoS attacks on smaller ISPs is worthy of blocking them at
> the IP level in your firewall, IMAO. Those of us using fetchmail are
> not so lucky in that regard.

btw, if you have procmail on your upstream, it should be possible
to match

    Return-Path: <spamblocker-challenge

which, if I recall correctly, is the Verizon callback.  I do (except with
an SpamAssassin rule), because nowadays I'm getting 1000 virus/spam
blowback bounces a day. :( (I don't know what I'd do without the
vbounce.cf ruleset!)

- --j.

> Of course abuse bounced as did postmaster. So the technical contact
> may have received the email including the gratuitous comment that
> their phone service sucks dead puppies through garden hoses, too.
> (They are about 10 to 20 years overdue replacing their main feeds
> from the CO to this area.)
> 
> z2c.net is another one that has appeared on my internal block list,
> too. They spammed me with a Forbes investment ad. I am getting mad
> enough to block major ISPs if I have to. DIGEX, Verizon, Z2C, AOL,
> HOTMAIL, and so forth. Scroom all. And I have decided that we're
> reaching the depths of an attack by the large ISPs on the small ones
> via spam. We need an anti-spam law with teeth enough to hang the
> spammers from the yard arm by their genitals.
> 
> {^_^}
> ----- Original Message ----- 
> From: "Kelson Vibber" <ke...@speed.net>
> Cc: <us...@spamassassin.apache.org>
> Sent: 2005 January, 19, Wednesday 09:14
> Subject: Re: Verizon hosting spammers :)
> 
> > 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:<bl...@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 <XX...@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=<an...@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFB7xcvMJF5cimLx9ARAlSUAJ9gUDYWI3vRYz8+73oLJqX1fWT+2gCeIZxQ
c8OZa+Z4ATb3WgCBvKGB0YE=
=ghYe
-----END PGP SIGNATURE-----

Re: Verizon hosting spammers :)

[jdow <jd...@earthlink.net>]

From: "Justin Mason" <jm...@jmason.org>


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> jdow writes:
> > This probably explains the massive runs of emails with nothing in them
> > that fetchmail is failing on when it attempts to drag them from
NG_Popper.
> >
> > I guess simply dropping Verizon on the floor is the simplest answer.
> > Explain to users what you are doing and why. Verizon facilitating
> > spam and DDoS attacks on smaller ISPs is worthy of blocking them at
> > the IP level in your firewall, IMAO. Those of us using fetchmail are
> > not so lucky in that regard.
>
> btw, if you have procmail on your upstream, it should be possible
> to match
>
>     Return-Path: <spamblocker-challenge
>
> which, if I recall correctly, is the Verizon callback.  I do (except with
> an SpamAssassin rule), because nowadays I'm getting 1000 virus/spam
> blowback bounces a day. :( (I don't know what I'd do without the
> vbounce.cf ruleset!)


Fetchmail gets so confused by these malformed messages that it actually
reports them as empty. So I've no traceback on them. They get dumped
on the floor now, anyway. From addresses have [>! type characters in
them.

{^_^}