OT: Is verizon blocking european netblocks?
Marcel Weber
I discovered a bizarre problem. Since last week (about 16th. December
2004) we cannot send any email to verizon. All I get is:
Dec 18 05:12:18 intra postfix/smtp[23663]: 42B1898008:
to=<[removed_for_privacy]@verizon.net>, relay=none, delay=150841, status
=deferred (connect to relay.verizon.net[206.46.170.12]: Connection timed
out)
Our server is on a static netblock (80.242.195.72) and our provider is
glattnet.ch. I also tried to "telnet relay.verizon.net 25" with no
success. As this persists since several days I tried it from different
netblocks, using different ISPs within Switzerland.
Telnet times out from:
glattnet.ch ( 80.242.195.71 )
tiscali.ch ( 212.254.99.112 )
cablecom.ch ( 80.219.15.36 )
Sending emails via cablecom.ch's relay server produces the same failure
message as sending it directly from glattnet.ch. Via tiscali I just
tried it but did not get any response yet.
Furthermore I found following thread in a forum:
http://www.broadbandreports.com/forum/remark,12116645~mode=flat~days=9999
In short the thread says, that verizon started to block open relays,
especially outside the us, from the 14th December. As my mail servers
are NOT open relays (I tested them with ordb.org) and cablecom.ch mail
server is no open relay either, I am quite surprised.
Now my question: Did anyone of this list's members experience the same
problems? What measures can I take? Is it just a temporarly problem of
verizon (for what their famous for)?
Regards
Marcel Weber
Duncan Hill
> Hi
>
> I discovered a bizarre problem. Since last week (about 16th. December
> 2004) we cannot send any email to verizon. All I get is:
> In short the thread says, that verizon started to block open relays,
> especially outside the us, from the 14th December. As my mail servers
> are NOT open relays (I tested them with ordb.org) and cablecom.ch mail
> server is no open relay either, I am quite surprised.
>
> Now my question: Did anyone of this list's members experience the same
> problems? What measures can I take? Is it just a temporarly problem of
> verizon (for what their famous for)?
Via my Force9 account (UK ISP), I have the same trouble. I'm now routing all
mail for Verizon.net via a server I control in the USA, which works fine.
I'd say they just firewalled off all space in RIPE.
Matt
>
> Furthermore I found following thread in a forum:
>
> http://www.broadbandreports.com/forum/remark,12116645~mode=flat~days=9999
>
> In short the thread says, that verizon started to block open relays,
> especially outside the us, from the 14th December. As my mail servers
> are NOT open relays (I tested them with ordb.org) and cablecom.ch mail
> server is no open relay either, I am quite surprised.
Seems like you missed the explanation of what they think an open relay
is.
To quote:
Essentially, this means that all email coming from servers that don't
have an authentication process are being blocked.
End quote.
Matt
Chris Stratford
> I discovered a bizarre problem. Since last week (about 16th. December
> 2004) we cannot send any email to verizon.
> Now my question: Did anyone of this list's members experience the same
> problems? What measures can I take? Is it just a temporarly problem of
> verizon (for what their famous for)?
You are definitely not alone. We are seeing exactly the same thing in
the UK. I can't get through from any of our servers and I've seen
postings that suggest quite a few other UK ISPs are also affected.
There was a mention in one post that none of the Messagelabs machine in
Europe could get through, but the US ones were ok, which suggests some
sort of wide-scale block at Verizon (and makes the "open relay" comment
in the forum link you supplied rather unlikely, as you would expect
their EU and US machines to be configured in the same way.)
Chris.
John Peach
Marcel Weber <mmw...@ncpro.com> wrote:
> Hi
>
> I discovered a bizarre problem. Since last week (about 16th. December
> 2004) we cannot send any email to verizon. All I get is:
>
From the NANOG mailing list (10 days ago):
I think I can shine a little bit of light on what might be your
Verizon problem.
Summary:
Verizon has put in place an exceedingly stupid "anti-spam" system which
does not work, which facilitates DoS attacks, and which provides active
assistance to spammers. Verizon has been told all of this, and it's
been discussed on Spam-L. If there's been a response from Verizon,
I haven't seen it: and AFAIK the practice continues. Anyone trying to
deliver mail there might want to at least skim this to get an idea of
the issues they may bump into. Please note that in places this is
sketchy because it seems impossible to get Verizon to provide the
information necessary to make it otherwise (or correct any errors).
Details:
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. Since most people have
long since disabled SMTP VRFY, they actually construct a fake 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 their outbound connection
(still rude), un-pause the incoming one, and reject the traffic.
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.
It also means that if the address that's trying to send mail to Verizon
is something like "sup...@thuleracks.com", which is the address that
the people at Thule Racks emit support traffic from, but which doesn't
accept traffic, that Verizon will deny the message. (Yeah, this isn't
very bright on Thule's part, either.)
Whoops.
This 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 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.
[ (b) is also how it lends itself to DoS attacks. Sure, Verizon
could rate-limit the rate at which they make outbound connections,
but then attacker X could impose significant delay on mail
from domain Y just by forging a boatload of messages purporting
to be from addresses in Y to Verizon. If Verizon rate-limits
their outbound connections, then any real messages from Y will be
stuck in the verification queue along with a kazillion forgeries.
And beyond that: other people are foolishly adopting this
"callback" nonsense as well. Slashdot carried a note the other
day about a program _designed_ to do this. This allows attacker
X to forge messages from domain Y to idiots I1, I2... In, for
a very large "n", and then stand back as all of them simultaneously
try to connect to the MX's for domain Y.
General principle: any "anti-spam" measure that generates more
junk SMTP traffic at a time when we're drowning in it is probably
a bad idea. ]
One thing that's not clear is whether or not Verizon caches any of
this information. Doing so might help cut down on DoS attack methods
that involve them, but of course it doesn't do anything about those
which leverage everyone else who's doing "callbacks".
And this is unfortunately, not the end of it.
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 (at least directly
from their own network space); it also prevents them from using their
resources to build lists of deliverable addresses to sell to other
spammers by poking at our mail servers.
Since Verizon is doing this probing *from their network*, spammers can
easily get around all of our blocking by getting Verizon to do it for
them. 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.
Note that refusing Verizon's probes, either accidentally or
deliberately, will of course cause Verizon to deny incoming mail. Which
I suppose might be okay for some folks, it isn't workable here.
So for now all we can do is explain to our users that it's causing
problems and deal with it. But if you look in your MTA logs and find
things like:
Jul 15 07:24:51 <XXXXXXXX...@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=<antispa...@west.verizon.net>, size=0, class=0, nrcpts=0,
proto=SMTP, daemon=MTA, relay=sc014pub.verizon.net [206.46.170.58]
then you can see what they're doing.
Duncan Hill
> 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:
>
>
> Then they pause the incoming connection. =A0And then they start up an
> outbound SMTP connection from somewhere else on Verizon's network, back
Unfortunately, this is just their callback system which has been in place f=
or=20
a while now. I can't even get an ack from their mail servers, let alone a=
=20
connection.
John Peach
Duncan Hill <pos...@nacnud.force9.co.uk> wrote:
> On Tuesday 21 December 2004 13:24, John Peach might have typed:
> > 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:
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0MAIL From:<bl...@example.com>
> >
> > Then they pause the incoming connection. =A0And then they start up an
> > outbound SMTP connection from somewhere else on Verizon's network,
> > back
>=20
> Unfortunately, this is just their callback system which has been in
> place for a while now. I can't even get an ack from their mail
> servers, let alone a connection.
I realise that - just a pointer to how fscked they are. FWIW I can reach
relay.verizon.net on port 25 from both RIPE and ARIN space.
Laurent Frigault
> On Tuesday 21 December 2004 13:24, John Peach might have typed:
> > 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:
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0MAIL From:<bl...@example.com>
> >
> > Then they pause the incoming connection. =A0And then they start up an
ck
>=20
> Unfortunately, this is just their callback system which has been in
> place for a while now. I can't even get an ack from their mail
> servers, let alone a connection.
I have the same problem in France from several ISP.
From my network (AS29169), some IP can connect to their MX server and som=
e
can't. I have no idea about the criteria that make the difference.
--=20
Laurent Frigault - NOC GANDI
Marcel Weber
>>Unfortunately, this is just their callback system which has been in
>>place for a while now. I can't even get an ack from their mail
>>servers, let alone a connection.
Okay, so the callback system shouldn't be a problem, as VRFY is still
allowed on my system.
> I realise that - just a pointer to how fscked they are. FWIW I can reach
> relay.verizon.net on port 25 from both RIPE and ARIN space.
So, it isn't the whole RIPE IP range, but just some particular networks.
If this is the case, the best thing would be to inform my ISPs about
the problem or should I try to contact verizon directly (apparently they
don't tend to behave very helpful?)?
Regards
Marcel
pos...@nacnud.force9.co.uk
> > I realise that - just a pointer to how fscked they are. FWIW I can reach
> > relay.verizon.net on port 25 from both RIPE and ARIN space.
>
> So, it isn't the whole RIPE IP range, but just some particular networks.
> If this is the case, the best thing would be to inform my ISPs about
> the problem or should I try to contact verizon directly (apparently they
I still can't reach Verizon from my Force9 account (212.159.x.x), or from
work's servers (195.10.x.x) - I had a friend in the Netherlands try, failed.
Had a friend on BT try, failed.
Contacted my correspondent in the US, and she called her tech support, and
they haven't got a clue about it, didn't even know it had happened (which
bears up what was said in that linked web bb thread).
You could try talking to your ISP, maybe Verizon asked them?
I should note, that if I relay through a US IP that I have access to (that
doesn't do sasl-authed relay), the mail delivers fine. Yet another brilliant
anti-spam move.