North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Fw: Administrivia: ORBS

  • From: Greg A. Woods
  • Date: Sat Jan 15 01:40:31 2000

[ On Friday, January 14, 2000 at 21:20:19 (-0800), Paul A Vixie wrote: ]
> Subject: Re: Fw: Administrivia: ORBS 
>
> Abovenet, like many ISP's, has a far-reaching antispam AUP, and aggressively
> disconnects customers of theirs who spam or who allow their own downstream
> customers to spam.  On their main web page (www.above.net) I saw a link with
> the title "Anti-Spam Policy" pointing to http://www.above.net/anti-spam.html
> which begins:
> 
> 	AboveNet's tolerance for spam originating from our customers, or
> 	from our customers' customers, or for spam advertising web sites of
> 	our customers of our customers' customers, is zero.

IANAL, but that doesn't say anything directly about AboveNet's policy
regarding open relays, at least not if you interpret "originate" as
meaning that it was actually generated on the source site.  They do say
in another part of their policy that the "reserve the right ... to
blackhole ... open relays", but they don't say that their tolernance for
open relays "is zero" as above for direct spam.  Of course I have no
personal, or even second hand, experience to know if/how they implement
their policies and until now I've had no reason to doutbt that they do
enforce their policies quite strictly.

I thought when this discussion first errupted that the issue might
actually be one of multi-level relays (which would be very effectively
stopped if AboveNet themselves used ORBS! :-), but after looking at the
list of AboveNet IPs published by ORBS it would appear that the open
relays are not generally of the multi-level nature.

Everything else I've heard about this event suggests that there are
indeed quite a few open relays within AboveNet's customer network space
(and/or in their customer's customer's).  What I don't know yet is how
those open relays were first discovered, or whether or not any
significant number of them have been exploited by spammers to any degree
at all.

Perhaps AboveNet would openly submit to testing by someone independent
of ORBS who would agree not to release the detailed results (except to
AboveNet) but who would check the validity of ORBS claims and provide a
summary report.  ORBS would of course have to be allowed to review the
validity of the tests done.

> Abovenet seems to be exercising their property rights over their own network.
> According to reports, they asked ORBS to stop running their SMTP port scanner
> on Abovenet's address space, and ORBS refused.  Abovenet's only recourse was
> to block access to ORBS' probe host.  And so, "I can't say as I blame them."

Ummm....  Something's wrong with that logic I think.

As I understand it the open-relay problems are not with AboveNet's own
mail servers, but rather with those of its customers, as I say above.
In this case AboveNet is a transport provider and in my opinion they're
risking their status as a network carrier to be filtering in they way
they are.  (Not that I know anything about carrier rights! :-).  In my
opinion they should be helping their customers secure the customer
networks, at the customer's border router, and not trying to do this
anywhere within AboveNet's network.  If anything they should be
filtering all external SMTP connections to or from the open relays on
their networks, not just those from the relay tester.

Of course if they can get by with using the MAPS RBL then they should be
able to get by with using ORBS too!

Your own filtering of your own network when your own hosts are involved
is a much different scenario.  If you don't want your mailers tested by
ORBS then that's fine.  Just arrange it such that they get back a TCP
RST packet and then be darn sure nobody else can relay through you
either.  Don't even bother logging their probes and it won't affect your
blood pressure.

Finally can we please stop using the incorrect term "port scanner" here?
ORBS does not "scan" and it most certainly doesn't scan arbitrary ports.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email protected]>      <robohack!woods>
Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>