-----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" <[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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFB7xcvMJF5cimLx9ARAlSUAJ9gUDYWI3vRYz8+73oLJqX1fWT+2gCeIZxQ
c8OZa+Z4ATb3WgCBvKGB0YE=
=ghYe
-----END PGP SIGNATURE-----
