Actually what mostly happens is that these consumer-oriented IP operations in large telcoish networks are balanced out by an equally garguantan hosting/colocation provider owned and operated by the same parent company. So basically they want to protect themselves from people competing against their hosting counterpart on the same network, for which you really can't blame them.
Also, generally network providers depend on a balance between inbound and outbound traffic. It's easier to get peering with other networks if you're not only connecting to them to suck them dry, but also have routes to offer them to get their customers to some content. If the outbound traffic from consumer services goes up too much, this balance gets disturbed.
A last point is that people who install an actual server on a network (be it ftp, http or, lord help us, irc) will be more demanding of that network and thiss be bigger pain-in-the-asses than the average lusers. Drives supportcosts up, while helldesk morale plummets. Lose lose.
Are many TOS/AUPs used by many providers ridiculously anal? Perhaps so. From an ISP perspective I assure you that this is not evil-mindednes, but coldblooded self-protection. I can tell you from situations where we discontinued service to spammers that the really bad assholes out there will do anything to shoot holes into your reason for terminating then. If you make things too specific when setting up the AUP, these people are bound to circumvent that which you explicitly forbid and still get their net.abuse fix. That's why AUPs usually read like "If we do not like you, we will show you the door, as you fly through it to the other side". Because sometimes it is necessary to do just that.
It is ultimately an ISP's reputation that defines how far they can actually go when enforcing anything in such an AUP. Now if a spammer is a paying member of your ISP but circumvents abusing the ISP's mailservers for the actual spamruns (using a throwaway account elsewhere or using third party remailers or lord knows what the spammer tricks du jour are) and they know for sure that this one customer is in fact the spammer (because he consistently spams for the website he hosts at said ISP), but their AUP doesn't cover the exact circumstance under which the spammer operated, you can be sure that your ISP will not be popular and manages to end up RBLed up the wazoo. If, however, they deal with the abuser adequately, they get applauded by everyone, most probably including you.
Now if the same ISP were to, say, break into your house to check your nude photo archive of Nathalie Portman, and the press got a word of this, would you suspect this would do much good to ISPX on NASDAQ? I don't think so.
Now with bigger ISPs like sprint, this is entirely academic anyway. Find me a large telco ISP that actually reads and responds to its abuse-mail and I'll find you a pregnant moose that can dance the polka while reciting Goethe in Chinese.
HTH.
Pi
-- This is a contract between two parties, namely: Broadband Operations & Fast Hyperlinks from here on known as THE GUYS WHO TRACK YOUR PROXYLOGS.
and {insert name here} from here on known as THE LUSER WITH NO LIFE.
CISH is getting along just fine. The ipchains wrapping is currently exactly the same as on a native IOS shell. If you want to learn how to operate the basic environment of IOS with regards to static routes, interface configuration and access lists, the program will be quite usable
The CVS release contains elements that will allow a system to boot with cish handling the system initialization. Expect an LRP floppy that does this in the near future to be available for download.
An area where cish is still lacking is in dynamic routing. I am currently looking at ways to interface with parts of GNU Zebra to add support for BGP, OSPV, RIPv2 et al.
In the case of whois, don't bet on it. I don't
know if the particular whois daemon that NSI use
is public, but writing one is even more trivial
than writing a CGI. You read one line from the input, which is the query. You output the results.
I'm using an internal whois server on my network that is nothing more than a simple shellscript.
I'm afraid you're wrong. The IRC does transmit the transfer-request. If you send someone a file over DCC, what happens is that your clients sends a CTCP DCC message to that client containing your IP-address and a port-number. The client on the other side connects to this port-number and receives the file.
(...) a wake-up call to legislators who believe the Internet is controllable by legislation. De-centralization puts it beyond arm's reach and even if they could target every server being used, it would be a futile excercise as copycat protocols spring up.
The same could be said for napster. Napster is not much unlike an irc-server. I'm still waiting for the MPAA or RIAA to start the lawsuits on IRC networks for "distributing intellectual property". Just as with napster, the exchange of files on IRC is a peer-to-peer issue: The IRC server only transmits the transfer-requests.
I don't know how big galaxynet is. But most networks that run "smooth and without splits" are those who don't have enough clients yet to run into the problems bigger networks run into. It's sort of common knowledge that at 40-60K users (depending on server software and network architecture) an irc network just tends to get saturated.
Disclaimer: I'm fairly new to the efnet experience. I've been running Undernet servers[1] for the past two years and only recently linked a server to efnet[2].
I haven't yet found someone who has been able to figure out where these rumours have been coming from. We got a couple enquiries about "is efnet going to shut down" in our efnet mailbox, but that's nothing out of the ordinary (Imminent Death of Efnet Predicted - Film at 11). Haven't seen any mail claiming that anything really special is going on. A couple of servers changed their policy. As far as I understand, from my limited experience, there's nothing strange or extraordinary about that. IRC networks are dynamic in nature.
The amount of DoS-flooding that goes on directed at a typical server for a major IRC network is completely out of bounds. Scriptkiddies see themselves as Freedom Fighters and Mighty Warriors, but are slowly pushing IRC networks to the point where they either become unusable or virtual Police States. On some networks, ideas have already been coined to start using a mandatory user registration system. No admin likes the privacy implications of such a move, but it may turn out to be the only way to keep the idiots out.
Once in a while, we get lucky and one of these kids touches a site that a federal agency cares enough about to start a case and the world has to deal with one scriptkiddie less. Most of them never get caught, though.
HTH.
Pi
[1] saltlake.ut.us.undernet.org and haarlem.nl.eu.undernet.org
[2] efnet.vuurwerk.nl
Re:ORBS helps spammers...
on
MAPS vs. ORBS
·
· Score: 1
$ nslookup > server topaz.nstc.com Default Server: topaz.nstc.com Address: 207.166.203.194
> ls -d relays.mail-abuse.org [topaz.nstc.com] <snip full list of abusable relays> My God! It's full of relays!
Cheers, Pi
Re:As far as I can tell ...
on
MAPS vs. ORBS
·
· Score: 1
Still seems pretty simple to me. They don't want to pass traffic for a certain AS, they shouldn't announce it. The low-metric jokes also were pretty lame.
Re:ORBS isn't about spam entirely.
on
MAPS vs. ORBS
·
· Score: 1
Just for the record, they don't block you. They mark you as untestable. Unfortunately the default implementations query relays.orbs.org for any response at all. I'm actually taking an active look at that and perhaps AB can be convinced to make the default zone not include those listings, making it then a deliberate choice to either bounce/tag messages in that static list or not.
Cheers, Pi
Documented example please? (Re:ORBS is a fraud)
on
MAPS vs. ORBS
·
· Score: 1
Please give me an example. I hear these stories all the time, but nobody bothers to give me a good example. AB is not immune to LARTs, even remote ones:-).
I don't think these are BGP 'hacks' as such. It's more a breaking of the standard. If they announce routability for a certain AS, they should route that AS, period. If they don't want to carry parts of that network, they bloody well shouldn't announce it.
The other part is about the way things were handled. They don't want the tester on their network, fine. However, what's that got to do with the ORBS Website and nameservers let alone 30000 unrelated domains caught in the action?
Hi there. I read abuse@vuurwerk.nl, the upstream of the machine sending you unwanted probes (relaytest.orbs.vuurwerk.nl). Please give me a couple of message-ids so I can trace back where you complained and see to it that you are never again probed. Also tell me how you managed to call me without knowing my phone-number:-).
AboveNet never complained to us. Nor to UUNet (our upstream) nor to Versatel (our other upstream). They just started blocking out of the blue. They can block for any reason at all, it's their right, but sensible, reasonable, people try to get things fixed without being so drastic first.
ORBS is not on RBL by the way. This is a solo-action inside AboveNet space. It was put in the RBL once, though, by Dave Rand (CTO of AboveNet if I'm not mistaken) but removed under public pressure.
Cheers, Pi.
Re:ORBS "gulty until proven innocent" stance
on
MAPS vs. ORBS
·
· Score: 1
The hall of shame netblocks are either netblocks that were full of open relays and then suddenly got blocked. Relays in these blocks have usually been tested manually by other people, with the results forwarded to ORBS.
Hope that clears things up for you.
Cheers, Pi
Re:The static list is NOT a static list.
on
MAPS vs. ORBS
·
· Score: 1
That warning text is not written by ORBS and doesn't come from the ORBS system. ORBS just returns an ip-address on an nslookup query. If your MTA tags with this anal text, you should take up the issue with whomever wrote it.
Your friend's mailserver is a security vulnerability. The vendor-provided update should be installed pronto.
I have witnessed one incident with a mailer crashing in the past and have been very helpful with the administrator of said server. I went as far as temporarily blocking access from the tester on our border router. It was in the planning to even add explicit banner-checks for mailers that choked on this particular test if more reports came in (none did).
They're not telling people you're a spammer if you don't allow their probes. They are telling people that they cannot verify that you are a spammer and leave the jumping to conclusions to implementing parties. Paranoid people will feed their rejects out of relays.orbs.org and dump you. The more optimistic admins will simply add a score-tag or take the inputs.orbs.org zone and let your mail go through.
ORBS didn't retaliate by farming out the relaytester. It was consistantly hosted by MIS, until telecomNZ got pressured to force them to drop it. Then it was consistantly hosted by Vuurwerk. It was moved out of necessity, not out of strategic considerations in an attempt to piss off administrators and thwart their security policies.
HTH. HAND. Pi
Re:that "seemingly clueful post"...
on
MAPS vs. ORBS
·
· Score: 1
Some footnotes to your comments, which were overall unbalanced yet a bit incomplete.
The ISP ORBS uses is more than one ISP. The website runs at MIS. The tester runs at Vuurwerk. And several companies host secondary nameservers for the orbs.org zones. All of those networks have suffered temporary unannounced blackholes and other routing-related incidents without prior notification.
AboveNet and Paul Vixie are not one. But the two top MAPS figureheads (Dave Rand and Paul Vixie) both have high (as in policy-making) positions there. It's ultimately been their call to not allow ORBS through AboveNet. And it's been their call to do this in a covert blackops style instead of being frank about it.
I don't think MAPS as a project is out to get ORBS either. I've been able to talk to MAPS supporters in quanitity the last couple of days and the majority of them are friendly and aware of the fact that basically they're on the same side. There are some things that can be said about ORBS that would need improvement. The way ABOV have engineered things, though, there is not the slightest chance of getting those improvements made. They want ORBS to die and then they're happy.
Oh, final note, the inputs.orbs.org zone is what you can use if you don't want 'untestable' ranges rejected by your MTA. It only lists verified relay inputs, not the manual entries. It's been around for a while, too, although advocacy of this option has been rather sparse.
Cheers, Pi
Re:Additional Background and Perspectives
on
MAPS vs. ORBS
·
· Score: 1
I have seen a lot of funny routing-games going on towards the MIS netblocks (where www.orbs.org is hosted), one of our netblocks (194.178.232.0/24 which currently hosts the relaytester) and even against specific DNS servers hosting secondary zones. If ABOV's purpose were to stop what they thought to be abuse, they wouldn't be doing things so covertly.
People argue that AboveNet are within their right to deny any traffic they see fit. Perhaps they are, but there are respectable members of the Internet community working there that at least I expected to be a bit less short-sighted, people that, for example, would have the decency to send a bit of mail to our abuse-address concerning the problem they have with the tester instead of silently blackholing a/24.
If this were just a provider concerned with their own security policies and nothing else, they would have done what they did in the open and they would have approached the people involved to get things fixed. The message is very clear, they want ORBS to just plainly die. I don't use ORBS myself (pretty hard to use ORBS if you're supposed to handle the abuse-queue where messages _about_ ORBS could end up at), but I don't react well to intimidation.
Cheers, Pi.
Re:ORBS is a net.terrorist!
on
MAPS vs. ORBS
·
· Score: 2
I think your use of the word "attack" is a bit of an overstatement. There is a total of 12 different SMTP transactions. I've had probes come over my heavily overused 28k8 line (it routes a/27 full of workstations) on a heavily underpowered mailserver (486dx4 with 16MB) and never noticed anything apart from the logfile entries.
I can't really judge your case without having an IP-address to look at the history. However, demanding that they mail you information over snailmail is not exactly showing an open mind from your side. Sounds much like "send me a signed letter so I can feed it to my lawyer who will crush you like a bug HAHAHA", which would indeed fall under the "cartooney threaths" department. However, I wasn't there, so without seeing your email I again can't judge what happened.
Finally, you were listed as "untestable", which gives a distinctive reply (as in, not 127.0.0.2) when looked up through the relays.orbs.org zone. It also does not appear in the much cleaner inputs.orbs.org zone.
The tcp/ip stack runs in kernel space. In the context of the kernel, there are no threads and there are no processes. Both of these are concepts that userland programs can rely upon because this same kernel imposes these virtual constructs upon them.
There is still a demand for the Amiga platform. At the recent St. Louis show three Disney animators created a series of concept designs for free. The Amiga has retained its image as a multimedia machine even after years of neglect. The new Amiga Corp. are hoping to tap into this to create something new.
There is however, the problem that developers of the innovative kind (people bound to try something new, create something staggering) really starve for low-threshold developer information for any product. Give them a free toy and they'll play with it, with the odd chance of something wonderful coming out of it.
The $99, however, is probably only payable by credit-card, which alone will rule out a fair amount of potential developers. In Europe, credit card payment is still not that commonplace as it is in the US. Even for people who may think the $99 is worth it, there is the matter of hassle. It's just not as convenient as downloading sdk.tar.gz and starting to hack.
Using this logic, Sony must be really be desperate. Look at the price of their DevKits! Why should they give it away for free?
Ah, but the Gaming Console is a totally different ballgame. The hardware there is usually sold at a loss. Money is made from the software, either through direct sales (Nintendo) or through royalties (Playstation). The Development Kits for such beasts usually include special-purpose hardware, which on its own makes giving it away to anyone but people who are serious about generating money out of their products a silly venture.
Sony made a semi-elegant knee-jerk to the not-so-serious coding geeks by releasing the Net Yaroze, by the way. For something around $400-$500, you could buy this special issue PSX1 complete with a linkcable, a convenient runtime library and the software to transfer code and data from the PC to the playstation. Software created for this platform couldn't run on an unmodded PSX, which meant that to release an 'official' playstation game you still needed the full devkit.
Nintentdo's position, if I understood it correctly, has been one of even more direct control over the developers. Again, as far as I have been told, you just couldn't release software unless if they really really liked you. And your software. Which meant that there had to be a Mario in there somewhere. That's S-NES lore, though, I have no idea if they got a better act together for N64. Most probably not, considering again the high density of Mario lameness surrounding the product.
You can't get the PIII serial number from Yahoo's webserver either, so what is the point you're trying to make? Yes, that you need local software to access the Mac address, just like you need for the cpuid.
You miss the point. The intel cpu id isn't in every ip packet that you send either. It's the software that accesses this number and does something with it. Like putting it in one of the umpteen redundant hidden fields in your Word documents;)
Slashdot Mirror
You obviously never tried out Microsoft "Promise but never deliver" Support. You'll love Linux "www.google.com" Support soon enough. HTH.
Pi.
Also, generally network providers depend on a balance between inbound and outbound traffic. It's easier to get peering with other networks if you're not only connecting to them to suck them dry, but also have routes to offer them to get their customers to some content. If the outbound traffic from consumer services goes up too much, this balance gets disturbed.
A last point is that people who install an actual server on a network (be it ftp, http or, lord help us, irc) will be more demanding of that network and thiss be bigger pain-in-the-asses than the average lusers. Drives supportcosts up, while helldesk morale plummets. Lose lose.
Are many TOS/AUPs used by many providers ridiculously anal? Perhaps so. From an ISP perspective I assure you that this is not evil-mindednes, but coldblooded self-protection. I can tell you from situations where we discontinued service to spammers that the really bad assholes out there will do anything to shoot holes into your reason for terminating then. If you make things too specific when setting up the AUP, these people are bound to circumvent that which you explicitly forbid and still get their net.abuse fix. That's why AUPs usually read like "If we do not like you, we will show you the door, as you fly through it to the other side". Because sometimes it is necessary to do just that.
It is ultimately an ISP's reputation that defines how far they can actually go when enforcing anything in such an AUP. Now if a spammer is a paying member of your ISP but circumvents abusing the ISP's mailservers for the actual spamruns (using a throwaway account elsewhere or using third party remailers or lord knows what the spammer tricks du jour are) and they know for sure that this one customer is in fact the spammer (because he consistently spams for the website he hosts at said ISP), but their AUP doesn't cover the exact circumstance under which the spammer operated, you can be sure that your ISP will not be popular and manages to end up RBLed up the wazoo. If, however, they deal with the abuser adequately, they get applauded by everyone, most probably including you.
Now if the same ISP were to, say, break into your house to check your nude photo archive of Nathalie Portman, and the press got a word of this, would you suspect this would do much good to ISPX on NASDAQ? I don't think so.
Now with bigger ISPs like sprint, this is entirely academic anyway. Find me a large telco ISP that actually reads and responds to its abuse-mail and I'll find you a pregnant moose that can dance the polka while reciting Goethe in Chinese.
HTH.Pi
--
This is a contract between two parties, namely:
Broadband Operations & Fast Hyperlinks from here on known as THE GUYS WHO TRACK YOUR PROXYLOGS.
and
{insert name here} from here on known as THE LUSER WITH NO LIFE.
CISH is getting along just fine. The ipchains wrapping is currently exactly the same as on a native IOS shell. If you want to learn how to operate the basic environment of IOS with regards to static routes, interface configuration and access lists, the program will be quite usable
The CVS release contains elements that will allow a system to boot with cish handling the system initialization. Expect an LRP floppy that does this in the near future to be available for download.
An area where cish is still lacking is in dynamic routing. I am currently looking at ways to interface with parts of GNU Zebra to add support for BGP, OSPV, RIPv2 et al.
Cheers,Pi
In the case of whois, don't bet on it. I don't know if the particular whois daemon that NSI use is public, but writing one is even more trivial than writing a CGI. You read one line from the input, which is the query. You output the results. I'm using an internal whois server on my network that is nothing more than a simple shellscript.
Cheers,Pi
I'm afraid you're wrong. The IRC does transmit the transfer-request. If you send someone a file over DCC, what happens is that your clients sends a CTCP DCC message to that client containing your IP-address and a port-number. The client on the other side connects to this port-number and receives the file.
Cheers,Pi
(...) a wake-up call to legislators who believe the Internet is controllable by legislation. De-centralization puts it beyond arm's reach and even if they could target every server being used, it would be a futile excercise as copycat protocols spring up.
The same could be said for napster. Napster is not much unlike an irc-server. I'm still waiting for the MPAA or RIAA to start the lawsuits on IRC networks for "distributing intellectual property". Just as with napster, the exchange of files on IRC is a peer-to-peer issue: The IRC server only transmits the transfer-requests.
Cheers,Pi
I don't know how big galaxynet is. But most networks that run "smooth and without splits" are those who don't have enough clients yet to run into the problems bigger networks run into. It's sort of common knowledge that at 40-60K users (depending on server software and network architecture) an irc network just tends to get saturated.
Disclaimer: I'm fairly new to the efnet experience. I've been running Undernet servers[1] for the past two years and only recently linked a server to efnet[2].
I haven't yet found someone who has been able to figure out where these rumours have been coming from. We got a couple enquiries about "is efnet going to shut down" in our efnet mailbox, but that's nothing out of the ordinary (Imminent Death of Efnet Predicted - Film at 11). Haven't seen any mail claiming that anything really special is going on. A couple of servers changed their policy. As far as I understand, from my limited experience, there's nothing strange or extraordinary about that. IRC networks are dynamic in nature.
The amount of DoS-flooding that goes on directed at a typical server for a major IRC network is completely out of bounds. Scriptkiddies see themselves as Freedom Fighters and Mighty Warriors, but are slowly pushing IRC networks to the point where they either become unusable or virtual Police States. On some networks, ideas have already been coined to start using a mandatory user registration system. No admin likes the privacy implications of such a move, but it may turn out to be the only way to keep the idiots out.
Once in a while, we get lucky and one of these kids touches a site that a federal agency cares enough about to start a case and the world has to deal with one scriptkiddie less. Most of them never get caught, though.
HTH.Pi
[1] saltlake.ut.us.undernet.org and haarlem.nl.eu.undernet.org
[2] efnet.vuurwerk.nl
$ nslookup
Cheers,> server topaz.nstc.com
Default Server: topaz.nstc.com
Address: 207.166.203.194
> ls -d relays.mail-abuse.org
[topaz.nstc.com]
<snip full list of abusable relays>
My God! It's full of relays!
Pi
Still seems pretty simple to me. They don't want to pass traffic for a certain AS, they shouldn't announce it. The low-metric jokes also were pretty lame.
Just for the record, they don't block you. They mark you as untestable. Unfortunately the default implementations query relays.orbs.org for any response at all. I'm actually taking an active look at that and perhaps AB can be convinced to make the default zone not include those listings, making it then a deliberate choice to either bounce/tag messages in that static list or not.
Cheers,Pi
Please give me an example. I hear these stories all the time, but nobody bothers to give me a good example. AB is not immune to LARTs, even remote ones :-).
Cheers,Pi
I don't think these are BGP 'hacks' as such. It's more a breaking of the standard. If they announce routability for a certain AS, they should route that AS, period. If they don't want to carry parts of that network, they bloody well shouldn't announce it.
The other part is about the way things were handled. They don't want the tester on their network, fine. However, what's that got to do with the ORBS Website and nameservers let alone 30000 unrelated domains caught in the action?
Cheers,Pi
Hi there. I read abuse@vuurwerk.nl, the upstream of the machine sending you unwanted probes (relaytest.orbs.vuurwerk.nl). Please give me a couple of message-ids so I can trace back where you complained and see to it that you are never again probed. Also tell me how you managed to call me without knowing my phone-number :-).
AboveNet never complained to us. Nor to UUNet (our upstream) nor to Versatel (our other upstream). They just started blocking out of the blue. They can block for any reason at all, it's their right, but sensible, reasonable, people try to get things fixed without being so drastic first.
ORBS is not on RBL by the way. This is a solo-action inside AboveNet space. It was put in the RBL once, though, by Dave Rand (CTO of AboveNet if I'm not mistaken) but removed under public pressure.
Cheers,Pi.
The hall of shame netblocks are either netblocks that were full of open relays and then suddenly got blocked. Relays in these blocks have usually been tested manually by other people, with the results forwarded to ORBS.
Hope that clears things up for you.
Cheers,Pi
That warning text is not written by ORBS and doesn't come from the ORBS system. ORBS just returns an ip-address on an nslookup query. If your MTA tags with this anal text, you should take up the issue with whomever wrote it.
HTH. HAND.Pi
- Your friend's mailserver is a security vulnerability. The vendor-provided update should be installed pronto.
- I have witnessed one incident with a mailer crashing in the past and have been very helpful with the administrator of said server. I went as far as temporarily blocking access from the tester on our border router. It was in the planning to even add explicit banner-checks for mailers that choked on this particular test if more reports came in (none did).
- They're not telling people you're a spammer if you don't allow their probes. They are telling people that they cannot verify that you are a spammer and leave the jumping to conclusions to implementing parties. Paranoid people will feed their rejects out of relays.orbs.org and dump you. The more optimistic admins will simply add a score-tag or take the inputs.orbs.org zone and let your mail go through.
- ORBS didn't retaliate by farming out the relaytester. It was consistantly hosted by MIS, until telecomNZ got pressured to force them to drop it. Then it was consistantly hosted by Vuurwerk. It was moved out of necessity, not out of strategic considerations in an attempt to piss off administrators and thwart their security policies.
HTH. HAND.Pi
Some footnotes to your comments, which were overall unbalanced yet a bit incomplete.
The ISP ORBS uses is more than one ISP. The website runs at MIS. The tester runs at Vuurwerk. And several companies host secondary nameservers for the orbs.org zones. All of those networks have suffered temporary unannounced blackholes and other routing-related incidents without prior notification.
AboveNet and Paul Vixie are not one. But the two top MAPS figureheads (Dave Rand and Paul Vixie) both have high (as in policy-making) positions there. It's ultimately been their call to not allow ORBS through AboveNet. And it's been their call to do this in a covert blackops style instead of being frank about it.
I don't think MAPS as a project is out to get ORBS either. I've been able to talk to MAPS supporters in quanitity the last couple of days and the majority of them are friendly and aware of the fact that basically they're on the same side. There are some things that can be said about ORBS that would need improvement. The way ABOV have engineered things, though, there is not the slightest chance of getting those improvements made. They want ORBS to die and then they're happy.
Oh, final note, the inputs.orbs.org zone is what you can use if you don't want 'untestable' ranges rejected by your MTA. It only lists verified relay inputs, not the manual entries. It's been around for a while, too, although advocacy of this option has been rather sparse.
Cheers,Pi
I have seen a lot of funny routing-games going on towards the MIS netblocks (where www.orbs.org is hosted), one of our netblocks (194.178.232.0/24 which currently hosts the relaytester) and even against specific DNS servers hosting secondary zones. If ABOV's purpose were to stop what they thought to be abuse, they wouldn't be doing things so covertly.
People argue that AboveNet are within their right to deny any traffic they see fit. Perhaps they are, but there are respectable members of the Internet community working there that at least I expected to be a bit less short-sighted, people that, for example, would have the decency to send a bit of mail to our abuse-address concerning the problem they have with the tester instead of silently blackholing a /24.
If this were just a provider concerned with their own security policies and nothing else, they would have done what they did in the open and they would have approached the people involved to get things fixed. The message is very clear, they want ORBS to just plainly die. I don't use ORBS myself (pretty hard to use ORBS if you're supposed to handle the abuse-queue where messages _about_ ORBS could end up at), but I don't react well to intimidation.
Cheers,Pi.
I think your use of the word "attack" is a bit of an overstatement. There is a total of 12 different SMTP transactions. I've had probes come over my heavily overused 28k8 line (it routes a /27 full of workstations) on a heavily underpowered mailserver (486dx4 with 16MB) and never noticed anything apart from the logfile entries.
I can't really judge your case without having an IP-address to look at the history. However, demanding that they mail you information over snailmail is not exactly showing an open mind from your side. Sounds much like "send me a signed letter so I can feed it to my lawyer who will crush you like a bug HAHAHA", which would indeed fall under the "cartooney threaths" department. However, I wasn't there, so without seeing your email I again can't judge what happened.
Finally, you were listed as "untestable", which gives a distinctive reply (as in, not 127.0.0.2) when looked up through the relays.orbs.org zone. It also does not appear in the much cleaner inputs.orbs.org zone.
HTH. HAND.Pi
The tcp/ip stack runs in kernel space. In the context of the kernel, there are no threads and there are no processes. Both of these are concepts that userland programs can rely upon because this same kernel imposes these virtual constructs upon them.
HTH. HAND.Pi
There is still a demand for the Amiga platform. At the recent St. Louis show three Disney animators created a series of concept designs for free. The Amiga has retained its image as a multimedia machine even after years of neglect. The new Amiga Corp. are hoping to tap into this to create something new.
There is however, the problem that developers of the innovative kind (people bound to try something new, create something staggering) really starve for low-threshold developer information for any product. Give them a free toy and they'll play with it, with the odd chance of something wonderful coming out of it.
The $99, however, is probably only payable by credit-card, which alone will rule out a fair amount of potential developers. In Europe, credit card payment is still not that commonplace as it is in the US. Even for people who may think the $99 is worth it, there is the matter of hassle. It's just not as convenient as downloading sdk.tar.gz and starting to hack.
Using this logic, Sony must be really be desperate. Look at the price of their DevKits! Why should they give it away for free?
Ah, but the Gaming Console is a totally different ballgame. The hardware there is usually sold at a loss. Money is made from the software, either through direct sales (Nintendo) or through royalties (Playstation). The Development Kits for such beasts usually include special-purpose hardware, which on its own makes giving it away to anyone but people who are serious about generating money out of their products a silly venture.
Sony made a semi-elegant knee-jerk to the not-so-serious coding geeks by releasing the Net Yaroze, by the way. For something around $400-$500, you could buy this special issue PSX1 complete with a linkcable, a convenient runtime library and the software to transfer code and data from the PC to the playstation. Software created for this platform couldn't run on an unmodded PSX, which meant that to release an 'official' playstation game you still needed the full devkit.
Nintentdo's position, if I understood it correctly, has been one of even more direct control over the developers. Again, as far as I have been told, you just couldn't release software unless if they really really liked you. And your software. Which meant that there had to be a Mario in there somewhere. That's S-NES lore, though, I have no idea if they got a better act together for N64. Most probably not, considering again the high density of Mario lameness surrounding the product.
Cheers,
Pi
You can't get the PIII serial number from Yahoo's webserver either, so what is the point you're trying to make? Yes, that you need local software to access the Mac address, just like you need for the cpuid.
Pi
You miss the point. The intel cpu id isn't in every ip packet that you send either. It's the software that accesses this number and does something with it. Like putting it in one of the umpteen redundant hidden fields in your Word documents ;)
Pi
That last remark, in the article's signature, seems like a nice place to pull gossip from:
Jacob MoormanFormer Assistant Head Developer, Stampede Linux (or Stampede GNU/Linux)
Now, those 22 people didn't resign because the others wanted them to call it GNU/Linux all the time, did they? Just wondering :).
Pi