In <Pine.LNX.4.21.0001170555450.24192-100000@james.kalifornia.com> Blu3Viper (david@killerlabs.com) wrote:
>> And which address is affected ? 210.201.200.216 is not there.
B> Yes it is. Look at the above URL. Also look at
B> http://www.orbs.org/bugtraq.html and http://www.orbs.org/above.net.txt.
B> Now look at mail.linux.com:
B> -- cut --
B> # host 210.201.200.216.relays.orbs.org.
B> 210.201.200.216.relays.orbs.org has address 127.0.0.4
B> # host -t TXT 210.201.200.216.relays.orbs.org.
B> 210.201.200.216.relays.orbs.org descriptive text "above.net has multiple
B> open relays and has blocked the ORBS tester."
B> -- cut --
>> Exactly. There are NO WAY to automatically find out which servers are bloking
>> ORBS and which are not. So they are all marked as "netblock entry":
>> -- cut --
>> [khim@dell khim]$ host 177.196.126.207.relays.orbs.org.
>> 177.196.126.207.relays.orbs.org has address 127.0.0.4
>> -- cut --
B> Yes, there certainly is. Think about it. How do you test the entire
B> internet address space for open relays? Do you start by blacklisting the
B> entire thing because "there is no way to tell" which ones are good and bad?
B> No. You list the servers that return 400/500 responses to relay injection,
B> you list servers that are unknown status (blocked) and you list servers that
B> grant 200 responses.
But what to do if you are found server who are relays but fall into "Unknown"
status due blocking on router ? You should mark them. By hand. Otherwise every
spammer will use blocked servers and ORBS become useless (and yes, I know quite
a few sysadmins who tried to fool ORBS instead of fixing relay problem till
I showed him what the end result will be). Problem is that you can not find
correct border for netblock (and even worse: you can not easily pull out
one address from netblock and do not mark it with netblock due DNS nature).
So ORBS created .ok.orbs.org. instead. Hmm. I should (and will) use .ok.orbs.org.
before .relays.orbs.org. but I doubt why it's not used in examples ???
>> It's up to admin to allow or refuse "netblock entries". Hmm. Perhaps I should
>> add check for .ok.orbs.org. before check for relays.orbs.org. ...
B> # host -t TXT 210.201.200.216.ok.orbs.org.
B> 210.201.200.216.ok.orbs.org is a nickname for 2.0.127.127.ok.orbs.org
B> 2.0.127.127.ok.orbs.org descriptive text "This server has been tested by
B> ORBS and appears to be secure against relaying"
B> Funny how it's a compliant server by ORBS but ORBS feels it's fine and dandy
B> to levy the blacklist, eh?
As Cox's said it's DNS nature :-/ Since there are EXIST "list of exceptions"
*.ok.orbs.org. the only question remains: "why it's not used in samples" ?
>> There are NO automatic procedure to find blocking. Thus all automatisation
>> works ONLY till bloking attempts are detected.
B> You have three types: Compliant, Unknown, and Non-compliant. Systems that
B> fit in Unknown could be broken, down, bad routing, and they could be
B> firewalling ORBS.
If you will not punish admins of "Unknown" systems noone will fix relays - they
will just block ORBS and go in "Unknown" state. Of course sometimes you'll
punish innocent systems :-( It's life as it is. What I can not understood is
other thing: if there are exist "exceptions list" already why it's not used ?
B> It doesn't matter. Compliant servers should NOT be blocked.
But it's only partially ORBS fault :-) Examples are there but it's mere
examples. I was one who used ORBS database in sendmail.cf. And used it
wrongly :-(
B> This entire discussion about blocking is not relevant to the rest of the
B> address space served by above.net, above.net is blocking a segment, we exist
B> in a different segment.
There are NO WAY to find out where segment border is. Since your host is not
blocked (and thus listed in .ok.orbs.org.) ORBS done what they can. It's not
easy to remove just one host from netblock by DNS nature so they created
"exceptions list" instead. Looks like bright move to me. What's not so bright
is silence in which such "exceptions list" is created :-((
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:15 EST