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.
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" <[EMAIL PROTECTED]>
Cc: <users@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 [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
