the issue with abovenet is not what you are thinking
If I am understanding it correctly here is the issue (random IP addresses
used for demonstration)
above.net has 10.x.x.x addresses assigned for them and their customers.
above.net has their own servers running in the 10.1.1.x subnet
above.net blocks scanning of 10.1.1.x but NOT the rest of the 10.x.x.x net
VA linux gets the 10.200.100.x subnet from above.net for their
servers. (which are configured properly)
VA linux discovers that they are unable to send mail becouse ORBS flags
the ENTIRE 10.x.x.x range owned by above.net, even though most of it is
not blocked, and does not contain any open relays.
The last paragraph is what is the issue, if they just blocked (ok, they
don't block, they just reccoment that others block)` the 10.1.1.x subnet
that they could not scan that would be one thing, but they instead block
the entire 10.x.x.x range.
David Lang
On Tue, 18 Jan 2000, Stephen Satchell wrote:
> Date: Tue, 18 Jan 2000 11:35:25 -0800
> From: Stephen Satchell <[EMAIL PROTECTED]>
> To: Glynn Clements <[EMAIL PROTECTED]>, Blu3Viper <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [Semi-OT,important] ORBS globally blocks users of these lists
>
> [linux-kernel removed from list]
>
> At 09:13 AM 1/17/00 , Glynn Clements wrote:
> >If I were in ORBS' position, I wouldn't want to get involved in
> >un-listing hosts which cannot be verified, but whose admin says "Trust
> >me: it's not an open relay, honest". The issue of whose word you
> >accept is way too tricky, IMHO.
>
> After checking my inside-only sendmail against the checklist that ORBS
> publishes through its links, I found that I was running what could have
> been an open relay if I let the smtp port be visible through my firewall.
>
> The problem is identical to what @HOME is claiming: that people provide
> open relay as a consequence of another action. For example, sendmail's
> configuration options are obtuse in and of themselves without having some
> dark-side prankster discover a syntactic hole and exploiting it to send one
> million email messages (or several thousand UseNet messages) through the
> compromise.
>
> After reading all the traffic, asking a few pointed questions, and tracking
> down all the web pages quoted by people all over these lists and in other
> places as well, I am of the belief that ORBS is indeed on the right path.
>
> It is the job of each mail admin to check, by whatever means available,
> that access is granted to those who are authorized and denyed to those who
> are not authorized. Now, to the mail admin the ORBS probes should be
> welcomed as a powerful tool to block spammers, by having ORBS use the
> spammer's tricks to see if ORBS can get a mail message relayed when it
> isn't supposed to be able to.
>
> Frankly, the more I think about it, the more it sounds like above.net and
> others are saying "Hey, the rule against driving while drunk doesn't apply
> to me! I know how to handle it." Right.
>
> By that thinking, Microsoft can claim "We never have buffer overruns!" with
> equal authority.
>
> Censorship? No. More like stopping the village idiot from polluting my
> mail inbasket.
>
> And don't forget that I was affected by ORBS when it turned out my provider
> has mail relay agents listed in ORBS. I brought up sendmail to fix the
> problem.
>
> Satch
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to [EMAIL PROTECTED]
>
-====---====---====---====---====---====---====---====---====---====---====-
to unsubscribe email "unsubscribe linux-admin" to [EMAIL PROTECTED]
See the linux-admin FAQ: http://www.kalug.lug.net/linux-admin-FAQ/
