No, you simply have to resolve the dispute properly. Some of the Commonwealth and former British colonies have updated little-used parts of common law, but some things occasionally fall through the cracks. A friend of mine relates a story, probably somewhat embellished in its trip around the SCA, about a friend in Maryland who was in a civil court case he wasn't likely to win. His attorney (licensed in Maryland) was also an accomplished heavy-armor swordfighter. When it was time for his opening statement, the attorney approached the other side's attorneys, threw down his chainmail gauntlet, and demanded his right of Trial By Combat, which had been part of English Common Law when Maryland revolted against the crown in 1776, and therefore was still active (even though the English Parliament abolished it sometime later), since it hadn't occurred to the Maryland legislature that it was something they should also abolish. The attorney making the demand, who was acting as Champion for his client, was a Large Dude, while the other side's attorney was an Old, Non-Large Dude. Some legal discussion ensued following this action, and at least some renditions indicate that the judge was a spoilsport and wouldn't let them follow through properly. Others indicate that the legislature may have since fixed this bit of old code.
On the surface, that looks like fun - Overture's customers bid for how much they'll pay per click-through, all of them get listed on Overture's own search engine, and the top three bidders get listed on the commercial search engines. Overture's site says they do carefully tuned techniques to prevent multiple clickthroughs by the same person (they've figured out that attack already), but that doesn't prevent single clickthroughs from a quarter million slashdot users, and that'd be a fun and community-minded thing to do.
My question, though, is how much information their customers get from my click-through. I assume that the long ugly URLs they generate encode the search terms, and maybe my IP address, and that their customers' web pages will use their favorite combinations of cookies, web bugs, and other images to find out more. But can they get my email address? If I'm checking out most sites that advertise there, I'm not too worried, but obviously clicking through to a spammer's web page has some inherent dangers. Should I be checking them out using the anonymizer, or is it ok to use my work network connection, which goes through a load-balancer-selected proxy server which probably looks a bit less like me?
From: clueless-open-relay@btamail.net.cn
Subject: Make Money Fast
Send your $31337 to Not-networkguru@Not-sloop.net
and I'll pay you 50% interest by Tuesday if you follow my 31337 PlanZ.
followed by the payment address for Not-networkguru@Not-sloop.net. Your proposed legislative solution, while well-meaning, makes it easy to cause lots of problems for someone by forging spam from them - a few hundred thousand emails from that cybercafe near their house through an open mail relay in Korea leading to a few thousand people each going to their nearest small claims court to collect their $200 nearly-automatic bounty, and most of them costing money to contest in court, especially in courts not near the framed-non-spammer's home. Big companies have an easier time defending themselves against this than individuals, but many anti-spam activists are good targets. And defending yourself means subpoenaing that open relay in Korea, and the ISPs supporting that relay - it just isn't practical.
Meanwhile, arranging payment is simply not hard. The most convenient payment mechanisms are credit cards and paypal, and sometimes you can get those providers to block payments to the spammer, but it's usually difficult to block *everything* - at best you can block the payments that *you* made to them. So they probably collect at least some money through their storefront check cashing / money laundering store in Taiwan, and *you* can't trace them easily.
The legislative problems that are easier to solve are the anti-hacking laws, which make it somewhat harder to track down spammers and much harder to stop them. While obviously you don't want some cracker to break into your machine, send themselves backdated spam claiming to be from you, and use that as their get-out-of-jail-free card, there may still be some middle ground that makes self-defense actions legal.
There are lots of mean nasty ugly things you could do to incoming spammers you catch with address bait, but shouldn't, for a variety of reasons that are ethical as well as self-protective. The most critical one is that somebody who knows you run a honeypot on your machine can fake email from you to a victim, causing them or their machine to send email to one of your boobytrapped addresses, tricking you into attacking them, which is bad for both of you. You really don't want to do that.... especially once spammers find out you're running an attack machine, because some of them will try to get revenge - especially if lots of people are running them.
But there are still entertaining things you can do that are within the bounds of propriety, legality, and sometimes even good taste.
You can trace the IP addresses of the spammers, and traceroute to find their ISPs. You can autogenerate complaints, though it's probably worth waiting until you have a couple of messages to be sure it's not just a misdirected email message (or you can hand-inspect them to be sure they're really spam.)
You can block all email from their IP addresses to your real users - especially convenient if you're running your spam-trapping on the same machine as your real email, or at least on a cooperating machine. (Be careful, and you may want to whitelist some machines, such as big email providers, and return good error messages so that any mail from real people can be resent using some other method or simply at a different time.)
You can run Teergrube which doesn't do anything destructive to the spammer, but responds v.... e..... r.... y.... s.... l.... o..... w..... l.... y.... , tying up resources that could otherwise be used to annoy other people.
You can run open relay checks on their machines - even though the RBLs of the world have cut down on real providers allowing open relays, there are lots of misconfigured open relay machines that spammers abuse. You can send them to the RBL people so they get cut off, but you can also quickly cut them off from your real email servers.
If the machine does have an open relay, and you've got a few thousand close friends running teergrube, you could use the relay to drop each of them a note. Do be careful not to cause infinite loops when you do this, though... Exponential growth is easier to cause than to recover from, and you don't want to shut down all the teergrubes you know.
(Also, be careful not to engage in defensive action for every message from a given source - you only need to traceroute and relay-check a given address once....)
Spam from China gets the additional letter to the spammer and also the ISP about "Dear Postmaster@btamail.net.cn, I'm having trouble reaching your subscriber AmyWilson@btamail.net.cn. Please let her know that the arms shipment will arrive next Thursday. Long live Falun Gong!":-)
Teergrube is a category of systems designed to "accept" mail from spammers, v e r y s l o w l y , and some of the implementations are designed to hold 10 connections from spammers open simultaneously (you could do a lot more.) Some of them can be run on machines with working SMTP servers, others are a substitute for a SMTP server that you run on some spare machine. If you know who's sending you mail, you can do a variety of things, ranging from notifying your real machine not to accept email from the spammer's IP address, simply holding the connection open (if enough people do that, the spammer's stuck waiting for timeouts instead of sending spam), submitting their address to block lists, or robo-generating complaints to the spammer's ISP, to doing mean nasty ugly things that probably violate your ISP's AUP. Some of the programs (see Raphael's posting encode the IP address of the harvester in the bogus addresses, which is nice for tracking down the real culprits as opposed to just blocking some open relay in Korea.
Spider traps are good at handing out bogus email addresses. If some of those addresses belong to teergrube machines, anybody who harvests them and then uses them to send spam to the "users" gets stuck in the tar pit for a while. If you're only doing that for your own machines, that's nice, and slows down the amount of spam you get from a given spammer, and maybe lets you track them down, but it's a pretty unfocused attack. The way to make these things really effective is to coordinate a bunch of honeypots with a bunch of spider traps, so a spammer gets totally mired down in a few hundred honeypots at once instead of just one or two. Is anybody running a project like this?
Running a network of honeypots properly isn't trivial - it helps to keep the list of cooperating honeypots semi-private, because otherwise spamware vendors will start avoiding them, and you need to make sure that every machine on your honeypot list *is* really a honeypot, and not some poor sucker's machine that's suddenly DDOS's by tons of spam because 500 Sugarplums are handing out his address to spammers. If you're going to automate this sort of thing, you should probably require at least confirmation-mail from postmaster@targetdomain.org or possibly a digital signature. One convenient method for coordinating it could be an IRC channel or similar IM server, though you could just use email. An entertaining technique to use would be to have the bogus addresses all belong to domains that you control the MX records for, so you can use DNS to load-balance the spam among machines that have spare cycles for teergrubing (e.g. spammer asks for bogus1.bogusdomain.com, bogus2.widgets.org, bogus3.slashdot.org, etc.) Too bad Napster's dead - most machines running Napster were clients that didn't run their own Port 25 SMTP services, so adding teergrube features to Napster clients wouldn't have interfered with real email, wouldn't have added much bandwidth because it doesn't actually accept messages very fast, and would have made the Napster folks anti-spamming heros. Any other Peer-to-Peer services such as ICQ/Jabber/etc or for that matter IRC clients want to jump in?
The web page doesn't have enough information to tell if the technology is usable. It's got some examples of compressed files, and a demo program, which does say that it's not vaporware and that at least for some kinds of sound samples it provides good compression and probably-pretty-good sound quality for the bitrates it uses. But that doesn't tell me enough to know if it's usable for any real applications. It needs several things:
Documentation on what kinds of sound compression it can support at what bit rates, and what frequencies it supports. Is this the same algorithm for music as for 3kHz voice? Can you do really good voice with 11kHz stereo inputs, or do its voice compression modes only do a better or worse job of reproducing the same raw 64kbps / 3kHz voice stream?
CPU horsepower requirements for compression. Is this a job for a DSP, or a fast PC, or a slow PC, or a Palm Pilot, or a wristwatch?
CPU horsepower requirements for decompression. It's often lower than compression, but not always.
Latency requirements for Compression and Decompression - is this usable for real-time conversations, or only for canned speech? This is separate from the horsepower requirements, which can be fixed by faster processors - many of the common algorithms require N voice samples to run the compression algorithm over, which is ok if you need 10ms of sound, marginally usable if you need 100ms, and unusable for conversations if you need 1 second of sound samples to get the compression rates (even though it's fine for music playback and other one-way sound applications.)
If possible, standard voice compression quality scores compared to the popular compression algorithms.
Information on what kind of licensing is negotiable and what isn't - can I give away free players and only pay/charge for compression tools, or do I have to charge every listener money for the decompression client? This makes a huge difference for web applications - it's much easier to get a web page publisher to pay for a tool with better compression than to get their readers to pay - that's Kiss Of Death mode.
Telcos have been doing various kinds of voice compression for decades, especially on international circuits; an important feature has been detecting modem and fax tones and turning off compression. We used to use analog techniques, then digital, then fancier digital. There's not much compression used within the United States, but lots of international calling on traditional telcos runs at 32kbps. Many of the new low-price international carriers use Voice-Over-IP technology - you may be getting 8kbps. And in addition to the telephones-on-both-ends carriers, there are the international Internet-to-telephone gateway companies like Net2Phone which go for the consumer market.
But the place you really see voice compression on T1s is between corporate PBXs - if you've got enough traffic between your offices to keep 12 or 24 channels full, it might make sense to run a private line, and until the mid-80s lots of companies did this, but by the time everybody's PBX was smart enough to be good at it, the price of Voice-by-the-minute from long distance telcos was cheap enough that almost everybody ripped that stuff out except for multiple offices in the same city. But compression equipment has become cheap enough and good enough that lots of people are rebuilding those networks that we ripped out in the 80s, especially since IP data networks mean that even if VOIP isn't cost-effective by itself, you can piggyback some voice on a data network for not much extra operating cost, and the equipment cost may pay off pretty quickly.
Companies are more likely to use voice compression on international circuits, because the price of pipes across the ocean is usually atrociously high, but the price per minute for phone calls to much of Asia is also atrociously high, so a dedicated line using compressed voice is still often a good deal. It doesn't usually sound as good as a Real Telephone Call, but lots of Asian telcos don't have the best sound quality either. The other big trend that's appearing in international calls is VOIP over internet connections - the quality is more variable, but the price of a T1 or E1 internet connection in Asia is often similar to the price of a 64kbps or 128kbps frame relay PVC.
This sounds like a really nice high-end compute server machine to support a herd of developers, as long as you give it enough RAM and Disk Drive and the 300 Watt Turbo-Charged Fan. I don't want it anywhere near my desk - put it in some server room somewhere. (In my current office environment, that means "back in the mailroom next to the Really Loud Xerox Machine".)
Give me a desktop with no fan, lots of pixels and video RAM, and a reasonable-sized disk and a CD-burner. In a small case. And put the disk in one of those removable-drive drawers so it's easy to replace. If it needs more than 500 MHz, it belongs on the server in the back room. Desktops are for running X (or VNC if you don't have a real OS), and doing light development, and running MP3s. If I need to have a dedicated machine to do development on instead of a shared environment, (which I don't), it almost certainly needs to be a slower machine to emulate a random customer.
Actually, my current desktop is a laptop running Win98. There's never enough RAM, and often not enough disk, but the 450MHz CPU is almost always fast enough.
I'm just speculating here, but one reason there's so much spam from Korea is that it's a high-tech country, but another reason is that there are a few million people with cable modems. If they're running software that's got open relay capability, there's a lot of potential spam that can be forwarded. Another reason, of course, is that Korean is a tough, bizarre language that doesn't use a Roman alphabet and isn't close enough to anything else for most non-Koreans to be good at writing useful complaints to administrators....
One way to run a teergrube system is to use a machine that doesn't have any real email users, and to seed your web sites with a bunch of email addresses on that machine. It's a nice thing to do with a cable modem or DSL server if you're not actually receiving email there. Many of the popular spamwares work by spidering the web to harvest fresh addresses of victims (though that's partly because they're competing against the people selling lists of 19 billion valid email addresses, but those losers get many of their lists by harvesting as well.)
An entertaining way to use Teergruben would be to set your DNS server to respond to requests from RBL locations with random teergrube servers. Handout them an MX record for some machine they really don't want to talk to...
If you've got a number of people running teergruben, you can share bogus addresses on each others' domains, you can spread around the damage so that the spammers end up stuck on lots of teergruben at once.
Everybody's a sysadmin these days, esp. Linuxusers
on
Spam Slows AT&T Email
·
· Score: 2
Sysadmins used to be a small community of people who were either running an organization's expensive computer system, and therefore could afford training and learning time, or people who'd built up systems (like the BBS scene) that achieved enough popularity that they often had to learn things the hard way. But that's a long, long time ago in a galaxy far far away. Everybody who's got a Linux system is a sysadmin. Everybody who runs a shared gaming systems is a sysadmin. Anybody who runs an application program that can provide services is a sysadmin. You can't expect millions of people to get sysadmin clues the way you could expect a few thousand of us to.
So what's the alternative? It's to make sure, as often as possible, to build applications programs that have security tools, and to make them as secure as possible by default. We need to try to anticipate problems that will affect lots of people beyond the intended users.
Economics will be hard to fix, because the whole Moore's Law effect driving our industry is that computation and communications keep becoming radically cheaper, and email has been really cheap for a long time. What we have to do is find ways to use those economics for spam prevention - as pattern recognition becomes easier, it's more usable for tracking down spammers, and you can make it *much* easier by techniques like seeding your websites with bogus email addresses you can use to trigger defensive responses, track down spammers, and get ISPs to block abusers. It's also important to use our communications abilities to coordinate spam detection and blocking - the RBL and its relatives are a beginning for this kind of process. Teergruben are another approach, especially if they can be coordinated. But it's also important to make sure that anti-spam tools aren't easily abused as Distributed Denial Of Service attacks (e.g. forging spam leading to mailbombing or long-term blockading of the forgee), which is amazingly easy (e.g. suppose you reply to a spammer's "remove me" address with a thousand emails of "From: bogusaddress1@bogus.net\nSubject: Unsubscribe\n\nbegin 666 vmunix\n...."
Yes, ICANN failed. Esther may have been one of the main founders of ICANN, but she hasn't been in charge for a long time, if she ever was. She may be a net.goddess, but never claimed to be omnipotent or omniscient. It was an important job, somebody had to do it, and she tried really hard.
Meanwhile, I'd say to ICANN's current leaders, that you're not Al Haig, and you're not in charge here.
I've never been that impressed with the alternate roots - while there are inherent problems with having a single root, especially if you define its existence before defining ownership or policies, most of the alternate roots I've seen were either run by net.kooks or people who wanted to make money by selling.sex and.xxx before the official root got around to it.
But ICANN's decided that not only has it scammed its way into control (as opposed to the IETF committee that was working on the same problems), but that it should increasingly get rid of any grassroots control, ignoring as much as possible the processes for elections by the actual public for members of its board. Now that it's declared itself no longer bound by the processes that it always refused to follow anyway, it's time to dump it. Part of that process is replacing control of the root - Lynn's proposal itself says that the root servers aren't really under ICANN's control or funding now.
California has a law saying that senders of bulk advertising email must include a subject line of "ADV:", or "ADV: ADLT" for porn spam. I've probably received half a dozen messages since they passed that law which were marked that way - it's much more effective to block emails with "Viagra" in the subject. The proposed Senate Bill 1618 was much more effective, even though it didn't pass, because spammers started using trailers about "According to Senate Bill S.1618, this isn't spam", and it was easy to filter out any messages containing that pattern.
Spam laws won't work until they can be applied effectively everywhere in the world; not a chance. Meanwhile, some of the proposed laws have had significant anti-privacy terms - banning anonymous email, banning mail services that don't insist on getting your personal identification. Here in the US, we've got a First Amendment, and most of the anti-spam laws are much better at trying to weaken it than at actually blocking spam.
Mailing lists are the obvious place where hashcash fails, because as you say, a large real mailing list has the same scaling problems that a large spammer list has. The way to fix that is for hashcash mail systems to use whitelists - if you know the sender isn't a spammer, accept mail from them without hashcash. Of course, that just encourages spammers to join mailing lists and then spam them.
You've got it backwards - there are mail packages such as Spam Bouncer that let you filter based on character set - if you never want to receive email in Korean, Chinese, or Russian, you can discard it all based on character-set headers. If you never want to receive email from Korea, you can even block that too. (That's a bit less reliable, because it's possible that there's someone in Korea you'd want to talk to, but you could probably set an autoresponder rule that tells Koreans that you're blocking email from there due to heavy spam levels, so they should use a non-Korean email system such as Hotmail/Yahoo/etc. to send you mail.)
There's a story from the '89 quake that somebody placed a service call to Tandem after the quake. (Tandem, later bought by Compaq, made highly reliable fault-tolerant machines with N processors, disks, backplane busses, etc. backing each other up.) The machine had fallen over on its face. It was still running just fine, but they wanted Tandem to come put it rightside up just in case anything went wrong in the process... (Also, they were big heavy machines....)
It sounds like your friend, and people in similar circumstances, really needs to get a Unix mail system. If he's got a Unix account at his ISP, then he can use Procmail or similar preprocessing scripts to trash the mail message before putting it in his mailbox, so he doesn't have to download it over a slow link. Alternatively, since he's using a POP mail client, he should retrieve his mail in a headers-only mode, trash the messages that are obviously spambounce, and limit his full downloading to the real messages. A number of mail clients can do that, or again, if he's running Unix at home, he can hack something if there's nothing that does quite the right job.
A number of years ago, a friend of mine was at University of Colorado. They had two computer centers which were connected by an infrared laser which was pointed out the window of one building to the other building. It had minor data loss during snowstorms, but was pretty reliable. One day the window broke, and a repair person came by and put a piece of plywood over the window until they could get a piece of glass big enough to repair it properly. He didn't understand why all the computer people started yelling at him.... after all, *he* couldn't see the invisible light beam going through the broken window:-)
Can't design 64-bit chips with 32-bit tools?
on
Inside the Itanium
·
· Score: 1
So *that's* why it's taken so long for this stuff to get to market!:-) You're not able to design bigger chips because your current design tools need the bigger chips to run on....
Like so many/. stories, this one's abstract assumes you know what FooBarBazz is,which all the FooBarBazz insiders know and some but often nowhere near all of the non-insiders have no clue because the name doesn't tell you. Is a "Myth Internet Server" a gamer thing, or a new operating system kernel, or a graphics widget, or a new coding project on Freshmeat?
Myth Game Server Open Source
February 7, 2002
By Mordia
Nothing in this world is permanent, and this must also be said of gaming servers. Over the past five years many of you have enjoyed the thrill of playing the Myth games online, as well as experienced the pains of a downed server or a rank reset. Ah! Memories! The time has come, however, to bid farewell to the old and tired Myth II game server.
We are finally and officially closing the doors on the Myth gaming servers for all time. Myth II online's last day will be Friday, February 15.
However, we realize that by doing so we leave a lot of people without a place to call home. So, what we intend to do is give it to you. Any of you who want it. The server that is. On this site you will find downloadable the Myth II metaserver source code. Do with it what you will!
Want to be an admin? Go for it! Want to make your own ranking system? Everything you need to do so is here. Have a yen for a custom WW2 server? You can make it!
This is the raw Myth II metaserver source code, stripped of a few proprietary bits of code, but still run-able. You can modify it in any way you want and use it for most anything you want. The only real conditions are that you don't then try to sell it and that you leave all the copyright and other legal notices with the code. Be sure to read the short, but very legal license agreement that comes with it before going nuts, but afterwards, go nuts.
The Myth Vault site will serve as a central location for the Myth game server development community, with a forum for people interested in discussing the code and the possibilities. In the future this site may also offer links to fan run servers, leader boards, order databases, whatever--that's all up to you.
We had two different accounting systems for mainframe access at Cornell in the mid-70s - the "instant turnaround" system that was accountless and gave you one second of CPU time and some number of pages of printout, and the regular account-based system that let you access more resources, such as files stored on the disk system and unlimited printout, and more computer languages. I think it was HASP, but it might have been JES2. Computer classes used IT for the first couple of semesters, and then used real accounts for the more complicated classes or for real research. Most classes handed out a couple of accounts, or had group projects that gave you access to multiple accounts, or you'd have some classes that didn't really need most of the funny-money in their accounts so you'd have some money left over, and each class normally had a few extras (people dropped the course or whatever) that you could guess the default 4-character passwords for.
The trick was to manage the accounts so that by the end of the semester, when crunch time came, you had a few accounts left that had at least a few cents credit in them, so you could exploit the Big Debugging Run Hack. Because the accounting system checked your balance when you started your batch job, to see if you had money and permissions that you needed, and debited the account at the end of the run, if you had any money left in it, your job could run as long as it wanted and print out as much output as you wanted as long as it could avoid crashing, leaving a negative balance if you overran it. So the desperation mov e you'd save for the big project was to get it mostly running but still containing the last few nasty bugs you hadn't been able to find, so you'd turn on all the gory debugging print statements around the sections you were having trouble with and burn a low-balance account. Then you'd take the reams of paper, spread it all over a table with different colored highlighters, and you and your project team would go hunt through and find the bugs, clean up anything else you needed for the hopefully final production run, and go run it from the real account. Hopefully that would work, or if it failed, then hopefully you had a few cents left in the account to do another run.
Later, at Bell Labs, I became a TSO wizard and could do interactive compilation and debugging - much nicer than batch. And we had Unix on PDPs and Vaxen, and then they got Unix running on the mainframe - while it was still in beta, I could do my development on a Vax with 40 other users, or on a mainframe that had a couple clunky things but gave me 10 WHOLE MIPS of horsepower to compile with:-)
The 9-track magnetic tape technology let you write-protect or write-enable tapes by inserting or removing a plastic ring that the tape-readers checked for before writing. There were usually lots of spare write-rings around any computer shop, because you'd remove them from backup tapes you were archiving so nobody'd overwrite them. They were great toys for little kids (good to grab or chew on), and also made good cat-toys.
My aperture card system was *much* faste rthan yours:-)
Aperture cards may seem an appallingly hokey kluge today, and they also did back when they were still current technology, but they really *were* amazingly practical. A 747 can't even *hold* the blueprints it takes to describe and manufacture itself if they're printed on dead trees, much less take off carrying them. But if you put the stuff on microfilm, you've got millions of little pieces of film that there's no way to manage effectively. Aperture cards gave you a way to manage and automate handling the film so that you could tell what was on an image without sticking the thing on a microfilm reader. That made it possible to open-source an airplane, because you could actually deliver all the information about the plane along with the plane itself. That's not strictly true - a fighter plane might not have cargo space even for the aperture cards. But the important problem was that every airplane was different, so you needed the prints to be able to do repairs or make replacement parts. Not just every model of plane, but every individual large airplane, because the mechanical systems, electrical systems, instrumentation, and even body parts were constantly being revised, and the building time for a 747 or a complex military plane was longer than the design cycles. Lots of parts also stayed the same across multiple planes, and you'd want to be able to produce multiple spares, but since every plane was different, it needed its data with it. And computers weren't big enough.
Back in the mid-late 80s I worked on a project that scanned aperture cards to translate them into computer media, because computers were starting to be able to manage that volume of data. The system had to read the Hollerith codes on the card, which were an index that said what the picture was, and then do a high-resolution scan of the image on the film onto a bitmap file, hand it to an raster-to-vector converter that attempted to extract line-drawings and text from the thing into a CAD/CAM data format, and store all the data in an optical jukebox - gigabytes were still pretty big back then:-) I forget if it was doing 900 cards/hour before I worked on it or after. I'd been brought in as a systems consultant because it was going dog-slow compared to what somebody had promised the Air Farce that they were going to be able to build, and it was way over budget and behind schedule, though of course the requirements hadn't been well-defined at the beginning of the project (except the number of cards/hour), there'd been lots of scope creep, the customer had changed the number of index fields in the database (seems like a minor thing for you relational database folks, but on a traditional mainframe database that was major surgery, especially when 10% of the cards had bogus data or had non-unique values in fields that were supposed to be unique sorting keys:-) Getting the people to redesign the mainframe stuff that was handling the database fixed the performance; the bottleneck should have been either the optical scanning process or storing the huge quantities of image data on the optical disk, not waiting for some silly CICS-emulator to look up the Hollerith data in a database so it would know how to label the image when it read it:-) The scanner system really rocked, and after the mainframe side was cleaned up, it was able to provide some of the performance we'd bought it for.
Slashdot Mirror
No, you simply have to resolve the dispute properly. Some of the Commonwealth and former British colonies have updated little-used parts of common law, but some things occasionally fall through the cracks. A friend of mine relates a story, probably somewhat embellished in its trip around the SCA, about a friend in Maryland who was in a civil court case he wasn't likely to win. His attorney (licensed in Maryland) was also an accomplished heavy-armor swordfighter. When it was time for his opening statement, the attorney approached the other side's attorneys, threw down his chainmail gauntlet, and demanded his right of Trial By Combat, which had been part of English Common Law when Maryland revolted against the crown in 1776, and therefore was still active (even though the English Parliament abolished it sometime later), since it hadn't occurred to the Maryland legislature that it was something they should also abolish. The attorney making the demand, who was acting as Champion for his client, was a Large Dude, while the other side's attorney was an Old, Non-Large Dude. Some legal discussion ensued following this action, and at least some renditions indicate that the judge was a spoilsport and wouldn't let them follow through properly. Others indicate that the legislature may have since fixed this bit of old code.
My question, though, is how much information their customers get from my click-through. I assume that the long ugly URLs they generate encode the search terms, and maybe my IP address, and that their customers' web pages will use their favorite combinations of cookies, web bugs, and other images to find out more. But can they get my email address? If I'm checking out most sites that advertise there, I'm not too worried, but obviously clicking through to a spammer's web page has some inherent dangers. Should I be checking them out using the anonymizer, or is it ok to use my work network connection, which goes through a load-balancer-selected proxy server which probably looks a bit less like me?
Meanwhile, arranging payment is simply not hard. The most convenient payment mechanisms are credit cards and paypal, and sometimes you can get those providers to block payments to the spammer, but it's usually difficult to block *everything* - at best you can block the payments that *you* made to them. So they probably collect at least some money through their storefront check cashing / money laundering store in Taiwan, and *you* can't trace them easily.
The legislative problems that are easier to solve are the anti-hacking laws, which make it somewhat harder to track down spammers and much harder to stop them. While obviously you don't want some cracker to break into your machine, send themselves backdated spam claiming to be from you, and use that as their get-out-of-jail-free card, there may still be some middle ground that makes self-defense actions legal.
But there are still entertaining things you can do that are within the bounds of propriety, legality, and sometimes even good taste.
Spider traps are good at handing out bogus email addresses. If some of those addresses belong to teergrube machines, anybody who harvests them and then uses them to send spam to the "users" gets stuck in the tar pit for a while. If you're only doing that for your own machines, that's nice, and slows down the amount of spam you get from a given spammer, and maybe lets you track them down, but it's a pretty unfocused attack. The way to make these things really effective is to coordinate a bunch of honeypots with a bunch of spider traps, so a spammer gets totally mired down in a few hundred honeypots at once instead of just one or two. Is anybody running a project like this?
Running a network of honeypots properly isn't trivial - it helps to keep the list of cooperating honeypots semi-private, because otherwise spamware vendors will start avoiding them, and you need to make sure that every machine on your honeypot list *is* really a honeypot, and not some poor sucker's machine that's suddenly DDOS's by tons of spam because 500 Sugarplums are handing out his address to spammers. If you're going to automate this sort of thing, you should probably require at least confirmation-mail from postmaster@targetdomain.org or possibly a digital signature. One convenient method for coordinating it could be an IRC channel or similar IM server, though you could just use email. An entertaining technique to use would be to have the bogus addresses all belong to domains that you control the MX records for, so you can use DNS to load-balance the spam among machines that have spare cycles for teergrubing (e.g. spammer asks for bogus1.bogusdomain.com, bogus2.widgets.org, bogus3.slashdot.org, etc.) Too bad Napster's dead - most machines running Napster were clients that didn't run their own Port 25 SMTP services, so adding teergrube features to Napster clients wouldn't have interfered with real email, wouldn't have added much bandwidth because it doesn't actually accept messages very fast, and would have made the Napster folks anti-spamming heros. Any other Peer-to-Peer services such as ICQ/Jabber/etc or for that matter IRC clients want to jump in?
But the place you really see voice compression on T1s is between corporate PBXs - if you've got enough traffic between your offices to keep 12 or 24 channels full, it might make sense to run a private line, and until the mid-80s lots of companies did this, but by the time everybody's PBX was smart enough to be good at it, the price of Voice-by-the-minute from long distance telcos was cheap enough that almost everybody ripped that stuff out except for multiple offices in the same city. But compression equipment has become cheap enough and good enough that lots of people are rebuilding those networks that we ripped out in the 80s, especially since IP data networks mean that even if VOIP isn't cost-effective by itself, you can piggyback some voice on a data network for not much extra operating cost, and the equipment cost may pay off pretty quickly.
Companies are more likely to use voice compression on international circuits, because the price of pipes across the ocean is usually atrociously high, but the price per minute for phone calls to much of Asia is also atrociously high, so a dedicated line using compressed voice is still often a good deal. It doesn't usually sound as good as a Real Telephone Call, but lots of Asian telcos don't have the best sound quality either. The other big trend that's appearing in international calls is VOIP over internet connections - the quality is more variable, but the price of a T1 or E1 internet connection in Asia is often similar to the price of a 64kbps or 128kbps frame relay PVC.
Give me a desktop with no fan, lots of pixels and video RAM, and a reasonable-sized disk and a CD-burner. In a small case. And put the disk in one of those removable-drive drawers so it's easy to replace. If it needs more than 500 MHz, it belongs on the server in the back room. Desktops are for running X (or VNC if you don't have a real OS), and doing light development, and running MP3s. If I need to have a dedicated machine to do development on instead of a shared environment, (which I don't), it almost certainly needs to be a slower machine to emulate a random customer.
Actually, my current desktop is a laptop running Win98. There's never enough RAM, and often not enough disk, but the 450MHz CPU is almost always fast enough.
I'm just speculating here, but one reason there's so much spam from Korea is that it's a high-tech country, but another reason is that there are a few million people with cable modems. If they're running software that's got open relay capability, there's a lot of potential spam that can be forwarded. Another reason, of course, is that Korean is a tough, bizarre language that doesn't use a Roman alphabet and isn't close enough to anything else for most non-Koreans to be good at writing useful complaints to administrators....
An entertaining way to use Teergruben would be to set your DNS server to respond to requests from RBL locations with random teergrube servers. Handout them an MX record for some machine they really don't want to talk to...
If you've got a number of people running teergruben, you can share bogus addresses on each others' domains, you can spread around the damage so that the spammers end up stuck on lots of teergruben at once.
So what's the alternative? It's to make sure, as often as possible, to build applications programs that have security tools, and to make them as secure as possible by default. We need to try to anticipate problems that will affect lots of people beyond the intended users.
Economics will be hard to fix, because the whole Moore's Law effect driving our industry is that computation and communications keep becoming radically cheaper, and email has been really cheap for a long time. What we have to do is find ways to use those economics for spam prevention - as pattern recognition becomes easier, it's more usable for tracking down spammers, and you can make it *much* easier by techniques like seeding your websites with bogus email addresses you can use to trigger defensive responses, track down spammers, and get ISPs to block abusers. It's also important to use our communications abilities to coordinate spam detection and blocking - the RBL and its relatives are a beginning for this kind of process. Teergruben are another approach, especially if they can be coordinated. But it's also important to make sure that anti-spam tools aren't easily abused as Distributed Denial Of Service attacks (e.g. forging spam leading to mailbombing or long-term blockading of the forgee), which is amazingly easy (e.g. suppose you reply to a spammer's "remove me" address with a thousand emails of "From: bogusaddress1@bogus.net\nSubject: Unsubscribe\n\nbegin 666 vmunix\n...."
Meanwhile, I'd say to ICANN's current leaders, that you're not Al Haig, and you're not in charge here.
But ICANN's decided that not only has it scammed its way into control (as opposed to the IETF committee that was working on the same problems), but that it should increasingly get rid of any grassroots control, ignoring as much as possible the processes for elections by the actual public for members of its board. Now that it's declared itself no longer bound by the processes that it always refused to follow anyway, it's time to dump it. Part of that process is replacing control of the root - Lynn's proposal itself says that the root servers aren't really under ICANN's control or funding now.
Dump ICANN, I say!
Spam laws won't work until they can be applied effectively everywhere in the world; not a chance. Meanwhile, some of the proposed laws have had significant anti-privacy terms - banning anonymous email, banning mail services that don't insist on getting your personal identification. Here in the US, we've got a First Amendment, and most of the anti-spam laws are much better at trying to weaken it than at actually blocking spam.
Mailing lists are the obvious place where hashcash fails, because as you say, a large real mailing list has the same scaling problems that a large spammer list has. The way to fix that is for hashcash mail systems to use whitelists - if you know the sender isn't a spammer, accept mail from them without hashcash. Of course, that just encourages spammers to join mailing lists and then spam them.
You've got it backwards - there are mail packages such as Spam Bouncer that let you filter based on character set - if you never want to receive email in Korean, Chinese, or Russian, you can discard it all based on character-set headers. If you never want to receive email from Korea, you can even block that too. (That's a bit less reliable, because it's possible that there's someone in Korea you'd want to talk to, but you could probably set an autoresponder rule that tells Koreans that you're blocking email from there due to heavy spam levels, so they should use a non-Korean email system such as Hotmail/Yahoo/etc. to send you mail.)
There's a story from the '89 quake that somebody placed a service call to Tandem after the quake. (Tandem, later bought by Compaq, made highly reliable fault-tolerant machines with N processors, disks, backplane busses, etc. backing each other up.) The machine had fallen over on its face. It was still running just fine, but they wanted Tandem to come put it rightside up just in case anything went wrong in the process... (Also, they were big heavy machines....)
It sounds like your friend, and people in similar circumstances, really needs to get a Unix mail system. If he's got a Unix account at his ISP, then he can use Procmail or similar preprocessing scripts to trash the mail message before putting it in his mailbox, so he doesn't have to download it over a slow link. Alternatively, since he's using a POP mail client, he should retrieve his mail in a headers-only mode, trash the messages that are obviously spambounce, and limit his full downloading to the real messages. A number of mail clients can do that, or again, if he's running Unix at home, he can hack something if there's nothing that does quite the right job.
A number of years ago, a friend of mine was at University of Colorado. They had two computer centers which were connected by an infrared laser which was pointed out the window of one building to the other building. It had minor data loss during snowstorms, but was pretty reliable. One day the window broke, and a repair person came by and put a piece of plywood over the window until they could get a piece of glass big enough to repair it properly. He didn't understand why all the computer people started yelling at him.... after all, *he* couldn't see the invisible light beam going through the broken window :-)
So *that's* why it's taken so long for this stuff to get to market! :-) You're not able to design bigger chips because your current design tools need the bigger chips to run on....
Anyway, Myth II is a gaming environment. Here's the story from the Myth Vault on bungie.net web site, in case it gets
Myth Game Server Open Source
February 7, 2002
By Mordia
Nothing in this world is permanent, and this must also be said of gaming servers. Over the past five years many of you have enjoyed the thrill of playing the Myth games online, as well as experienced the pains of a downed server or a rank reset. Ah! Memories! The time has come, however, to bid farewell to the old and tired Myth II game server.
We are finally and officially closing the doors on the Myth gaming servers for all time. Myth II online's last day will be Friday, February 15.
However, we realize that by doing so we leave a lot of people without a place to call home. So, what we intend to do is give it to you. Any of you who want it. The server that is. On this site you will find downloadable the Myth II metaserver source code. Do with it what you will!
Want to be an admin? Go for it! Want to make your own ranking system? Everything you need to do so is here. Have a yen for a custom WW2 server? You can make it!
This is the raw Myth II metaserver source code, stripped of a few proprietary bits of code, but still run-able. You can modify it in any way you want and use it for most anything you want. The only real conditions are that you don't then try to sell it and that you leave all the copyright and other legal notices with the code. Be sure to read the short, but very legal license agreement that comes with it before going nuts, but afterwards, go nuts.
The Myth Vault site will serve as a central location for the Myth game server development community, with a forum for people interested in discussing the code and the possibilities. In the future this site may also offer links to fan run servers, leader boards, order databases, whatever--that's all up to you.
The trick was to manage the accounts so that by the end of the semester, when crunch time came, you had a few accounts left that had at least a few cents credit in them, so you could exploit the Big Debugging Run Hack. Because the accounting system checked your balance when you started your batch job, to see if you had money and permissions that you needed, and debited the account at the end of the run, if you had any money left in it, your job could run as long as it wanted and print out as much output as you wanted as long as it could avoid crashing, leaving a negative balance if you overran it. So the desperation mov e you'd save for the big project was to get it mostly running but still containing the last few nasty bugs you hadn't been able to find, so you'd turn on all the gory debugging print statements around the sections you were having trouble with and burn a low-balance account. Then you'd take the reams of paper, spread it all over a table with different colored highlighters, and you and your project team would go hunt through and find the bugs, clean up anything else you needed for the hopefully final production run, and go run it from the real account. Hopefully that would work, or if it failed, then hopefully you had a few cents left in the account to do another run.
Later, at Bell Labs, I became a TSO wizard and could do interactive compilation and debugging - much nicer than batch. And we had Unix on PDPs and Vaxen, and then they got Unix running on the mainframe - while it was still in beta, I could do my development on a Vax with 40 other users, or on a mainframe that had a couple clunky things but gave me 10 WHOLE MIPS of horsepower to compile with
The 9-track magnetic tape technology let you write-protect or write-enable tapes by inserting or removing a plastic ring that the tape-readers checked for before writing. There were usually lots of spare write-rings around any computer shop, because you'd remove them from backup tapes you were archiving so nobody'd overwrite them. They were great toys for little kids (good to grab or chew on), and also made good cat-toys.
Aperture cards may seem an appallingly hokey kluge today, and they also did back when they were still current technology, but they really *were* amazingly practical. A 747 can't even *hold* the blueprints it takes to describe and manufacture itself if they're printed on dead trees, much less take off carrying them. But if you put the stuff on microfilm, you've got millions of little pieces of film that there's no way to manage effectively. Aperture cards gave you a way to manage and automate handling the film so that you could tell what was on an image without sticking the thing on a microfilm reader. That made it possible to open-source an airplane, because you could actually deliver all the information about the plane along with the plane itself. That's not strictly true - a fighter plane might not have cargo space even for the aperture cards. But the important problem was that every airplane was different, so you needed the prints to be able to do repairs or make replacement parts. Not just every model of plane, but every individual large airplane, because the mechanical systems, electrical systems, instrumentation, and even body parts were constantly being revised, and the building time for a 747 or a complex military plane was longer than the design cycles. Lots of parts also stayed the same across multiple planes, and you'd want to be able to produce multiple spares, but since every plane was different, it needed its data with it. And computers weren't big enough.
Back in the mid-late 80s I worked on a project that scanned aperture cards to translate them into computer media, because computers were starting to be able to manage that volume of data. The system had to read the Hollerith codes on the card, which were an index that said what the picture was, and then do a high-resolution scan of the image on the film onto a bitmap file, hand it to an raster-to-vector converter that attempted to extract line-drawings and text from the thing into a CAD/CAM data format, and store all the data in an optical jukebox - gigabytes were still pretty big back then
Actually, the cool new punchcard systems were the ones with the 96-character mini-cards, about 1/3 the size of the Hollerith 80-columns.