In the meantime I'd love any pointers at all to where you can buy the systems they used for development and testing - apparently you can actually buy systems with infinite memory so you can do extensive testing and never notice firefox has a memory management problem.
Number of firefox crashes while typing this comment: four.
I think you're touching on a very large part of the problem when you write
> The big problem I am having is with companies and websites. These emails are often no-reply, which means I can't send back a quick note.
I've always thought that sending messages with invalid return addresses or with a return address that's routed to the functional equivalent of/dev/null is intolerably rude. In fact, I think sending a message with the intention of discarding any reply is pretty close to the maxiumum amount of disrespect you can show your message's recipient.
I have one message to the executives of companies that send email with 'no-reply' return addresses deserve to be faced with a boycott: If you're not interested in reading our replies, we're not interested in sending you any money either.
I don't think Microsoft Exchange addiction (as I've blogged on in the past, see my.signature) should count as an excuse either. Sending mail with a deliverable return address is a matter of a minimum of common courtesy and civilty.
The concept isn't very new or radical, but it will be interesting to see how their implementation behaves in real life.
Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.
Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.
The right-hand column on the BBC site has a link to a story called "Europe is 'losing' superbugs battle". The current story is a case in point: Europe is losing big time against the sinister "Stupidity" superbug.
I'd be more than a little surprised if any part of the US government would in fact agree to let non-disclosure agreements expire automatically. That alone makes me suspicious that the truth content of these allegations is a little thin.
For those of you who are interested in finding out the facts, start by reading the whole thread on openbsd-tech (eg http://marc.info/?t=129236639300001&r=1&w=2 ), it's only a handful of messages so far and I find Damien Miller's response at http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 particularly enlightening. (You're using Damien's code right now, in some other window -- he's been a major OpenSSH developer for quite a while).
Then again, I have to agree with Bob Beck (see http://marc.info/?l=openbsd-tech&m=129236730027908&w=2 ) that this is fairly likely to part of a personal vendetta of some sort, possibly against either the OpenBSD project or even something totally unrelated, using the OpenBSD project only as the attention-grabber in contexts such as/.
At this point we have only allegations with some finger pointing, I for one look forward to any real information to surface. The best way to draw out the real information behind this is to do what Theo did - publish the allegations and let the involved parties explain themselves in public.
I find it's always worth mentioning that there are publishers out there who respect their customers enough to not do the DRM dance, and from the author's view (yes, I am one) the danger of people not reading your stuff is more scary than the danger of not getting paid for every last copy.
It's probably worth mentioning that there's at least one tech books publisher that publishes e-book versions in several formats (IIRC you get them all in a zip archive), with no DRM. That publisher is No Starch Press (http://nostarch.com).
I think for most of the writers who publish on No Starch, the thinking is that readers should have access to the material the form that's convenient to them, with as few restrictions as possible. For my own part, I see the bittorent trackers that turned up about four hours after the PDF version of the first edition of my book mainly as a sign that people appreciate my work.
Full disclosure: I have a title out on No Starch that's been available as ebook before the printed version is available (expected about Nov 10th), see http://nostarch.com/pf2.htm
Make sure you make a backup of your/etc/ directory beforehand and you are good to go. The upgrade process should keep your configuration intact, but it never hurts to be a bit cautious.
For/etc upgrades, there's sysmerge.
In fact, you can run sysmerge -x xetcNN.tgz -s etcNN.tgz and answer the friendly prompts before booting into the installer for the upgrade. Then after you've done the base system upgrade, set your PKG_PATH to something sensible and run pkg_add -u to upgrade your packages. Time needed is mainly a function of how good your connectivity to the packages mirror is.
There's a series of pictures at http://bsdly.blogspot.com/2010/01/goodness-of-men-and-machinery.html that tell you what the installer looked like in January. IIRC no huge changes have happened to it since then. But do try 4.8 or a recent snapshot (they come with installNN.iso files these days)
Repetition by hand, even by a skilled operator, is error prone. I think that's the main message in this article, and I couldn't agree more. The task at hand doesn't even have to be that complex.
That's why, in a system administration context, tools like puppet (http://www.puppetlabs.com/) and cfengine (http://cfengine.com) make so much sense.
Tools like those help you make sure that items that need to be the same stay the same, and make sure changes happen in sync across systems when need be (courtesy of your version control system). And of course, local variations can be catered to in a number of ways and maintained across global reconfigurations. If you're lucky enogh to be working on a Unix or BSD, that is. Not sure what's available in Cisco or Windows space.
In Europe, checks are rare if not extinct, for something like the last 10 years at least. Direct transfers (IBAN) or similar just work and most people here do their banking mainly online anyhow.
Most likely you could talk your bank here into issuing a check for you if you ask them nicely, but it would almost certainly be more expensive than a straight electronic transfer.
On the other hand, somebody likely had fun and made a modest amount of money developing that check scannin app, so the effort I guess is not totally wasted.
They've also added a nice feature called expiretables that keeps the "bruteforce" table small & efficient by expiring entries that haven't seen any hits after a definable period of time.
Thanks for mentioning the tuturial, but actually expiretable is no longer necessary. On anything with PF equal to OpenBSD 4.1 or newer a simple
pfctl -t bruteforce -T expire 86400
will expire table entries that have not had their statistics updated for the last 24 hours (86400 seconds)
I really should reverse the sequence at that page. expiretable likely still works, but it is no longer necessary to install a separate package to get table expiry.
Or to put it another way, what you're seeing is the Internet's background noise. There is at least one, possibly several, smallish botnets that do brute force ssh password guessing all across the Internet.
I see others have already mentioned my articles such as http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html, and if you take a peek in the list of addresses I put there, I would not be at all surprised if there's a great deal of overlap with the hosts that keep sniffing your servers (my data for that round has a little over 4000 hosts). In fact, it would be interesting to know how large or small the overlap is. They will keep trying (in fact I'm just seeing the start of another alphabetic phase over the last few days here) but there are a few things you can do to make it less likely they will succeed.
The general advice is, as you have heard many times before, to enforce a policy of no passwords, usin only key authentication, of course disable root logins and if practical limit where you can log in from to 'known good' IP addresses or ranges. The first two won't rid you of the logged attempts, but sensible in any case and makes the probability of ssh-based compromise quite a bit less likely.
Rate limiting helps get rid of the classical rapid-fire variety password guesser, but will not help at all when you're faced with the coordinated 'hail mary cloud' where each individual host could be attempting to access your system or network only every few hours.
As for portknocking, I seriously think the port knockers would be equally well served by switching all passwords to unicode. That provides a practical alphabet of the same number of unique characters (16 bits, remember), and for anyone with a large enough fleet of password guessers, the mechanics of guessing the right one is not all that different. Oh well, I just spilled the beans for the main point of an upcoming column, that won't spoil the fun later, I hope.
It struck me that Microsoft over the last few years has made a series of deals with other corporations over patents, but in each case
whatever is published is too unspecific to interpret
Microsoft's announcement mentions Linux in vague language, with the intention of making it sound less than legit
What then, if that secret, submarine patent is about something else entirely, or for that matter, does not even exist? For that matter, there could be several threats in play, patent based or otherwise, but anyway the main point of any such deal is to make sure the non-Microsoft party stays quiet, leaving Microsoft free to create the impression that Linux is somehow not quite legit, with no factual basis whatsoever.
We have no way of actually knowing, but it does appear that the US legal system somehow allows the kind of of behavior I suspect here as long as the actual underlying facts are not available to the public.
It doesn't even have to be a patent or a real issue at all, given the likely size of Microsoft's legal budget the threat of prolonged litigation backed up by the famous PR machine would be quite sufficient to intimidate smaller players to silence. Most of us are, after all, smaller players than Microsoft.
All idle speculation of course, but as long as they keep us in the dark about the facts of these deals, speculation will flourish.
We've been hearing this for quite a while, and for some odd reason IPv6 isn't really entering the mainstream regardless of these warnings.
We should not forget that within IPv4 space, reallocations do happen. Some organizations are AFAIK still sitting on routeable/8s for no good reason whatsoever, and possibly, maybe, some of that space will be redistributed one way or the other. Then of course those parts of the world that have actually switched to IPv6 are not likely to switch back (but you'd have to pry their 4to6 and 6to4 gateways from their dead, cold fingers), and actuall large segments of the Western world lives quite comfortably (fsvo) behind one or more layers of NAT.
So are we actually that close to running out?
Could be. It could also be that reallocations happen in IPv4 space that make the matter a little less urgent for just long enough that IPv6 wins the hearts and minds of the resisters or their objections are in fact addressed.
I set up SPF as kind of a desperation play more than anything else and the backscatter disappeared almost overnight. I'm sure someone out there is still receiving spam which appears to be sent from my domain, but the volume of backscatter I'm getting isn't even a tenth of what it once was. SPF is good for something.
The end of backscatter is more likely both a temporary thing and an indicator that they moved on to the next domains in their lists. They will be back sooner or later. In the meantime, you could use those backscatter addresses productively for such things as greytrapping (see eg http://www.bsdly.net/~peter/traplist.shtml, featured here at/. at various times). It is worth noting that the domains involved there had valid spf records before those backscatter storms started happening.
Oh, there's certainly a convenience factor, of course. The problem starts when your account with the default password is exposed to the world at large. In the case of the jailbroken iphones there is no sane reason to have a default password - for root of all things - in the first place.
And http://www.defaultpassword.com/?action=dpl&char=d confirms my hazy memory of the DEC field circus' User: field pass: service - which is good for a few stories in itself, of on-sites changing the password to 'circus' and a few mostly forgotten tales about putting modems into the mix and getting unusual activity from the field account.
Publishing your password on the net (which is roughly equivalent to what these lusers have done) borders on criminal negligence.
I've ranted about this before (and yes, it was/.ed), and the conclusion remains the same:
if you run with a default password, for root or otherwise, you have effectively published that account's password.
What is bound to happen after you have published your password is left as an exercise to the eader.
The problem here seems to be badly maintained blacklists. After seeing way too many false positives on various blacklists out there, the only lists I would use are ones that expire their entries in a matter of days or hours. The good ones that I use are uatraps (greytrapping generated, 24 hour expiry) and nixspam (IIRC max 4 days after last seen spam activity). Then of course I maintain my own greytrap list (see the traplist homepage and the traplist ethics pagefor details).
The point is, you need to expire entries aggressively. Keeping entries around because somebody received a spam from somewhere in that general direction four years ago is just silly. And don't get me started on blacklisting domains. If there is one thing we know with almost total certainty, it is that spammers never use From: or Reply-to: addresses that have anything vaguely to do with the real senders.
Even without any sort of criminal record it's not a pleasant experience to enter the US, even as a Norwegian citizen entering via Canada. This May the robots routed me back form BSDCan (in Ottawa) through Washington, DC. It's possible that the fact that I did not apply for a visa (this was transit only, planning to stay on the ground roughly one hour between flights) complicated things a bit.
As it turned out, in addition to the ordinary three forms (with more or less the same info in all of them) I needed to fill in a separate 'visa waiver form' (identical to at least two of the other forms in all other things than paper thickness, sheet size, color of paper and print and font) before getting to the fingerprinting, retina scanning and oral examination to check the validity of the information that I'd filled in, performed by a border guard who seemed to have been trained to appear hostile but was obviously monumentally bored by the whole process.
This was after clearing the ordinary pre-boarding security theatre, mind you. And of course I would need to pick up the boarding passes for my connecting flights at the Washington, DC airport. That meant getting from one end of the airport to the other to pick up boarding passes and clearing another full act of security theatre in order to get back to where I could board the transatlantic flight. I did make my connecting fligh, running pretty much all the way except for the time spent lining up for the various security checks on the way.
So yes, I can believe in a theory that US border control was a factor in deciding to place the next Olympics elsewhere.
The Spamhaus article really describes one of the most frequently encountered behaviors we see by looking at our spamd logs.
Each machine does not necessarily send a large number of messages (although some do, hanging on for weeks on end in extreme cases), but once a machine has tried to deliver mail to one of our published trap addresses (see the list at http://www.bsdly.net/~peter/traplist.shtml ), we keep them occupied and publicly shamed (see http://www.bsdly.net/~peter/nameandshame.html as well as the exported blacklist) for 24 hours, or longer if they keep coming.
I wrote about these things in some blog posts earlier that were/.ed, and of course the generated lists are free to use, see the URLs and the blog posts.
I read your article, from what I can tell you were not even blacklisted? If you are blacklisted on MEHS (Microsoft Exchange hosted Services) your email is bounced back right away, I don't see any such messages in your writeup. When I tried sending that writeup to Microsoft, the message was indeed bounced immediately. I have no idea how the admin interface works or what it looks like, but I got the impression from the customer's admin guy that it was (is?) a very complicated and confusing GUI application.
The main thing is, however, that the process was totally opaque, and how the system is supposed to work is a trade secret. Getting any kind of information out of Frontbridge at all was just not possible.
It's possible that the system was designed by very smart people, but I strongly suspect that those orignal brains took the money they got from Microsoft and ran, leaving the code and operation in less capable hands.
Slashdot Mirror
In the meantime I'd love any pointers at all to where you can buy the systems they used for development and testing - apparently you can actually buy systems with infinite memory so you can do extensive testing and never notice firefox has a memory management problem.
Number of firefox crashes while typing this comment: four.
> The big problem I am having is with companies and websites. These emails are often no-reply, which means I can't send back a quick note.
I've always thought that sending messages with invalid return addresses or with a return address that's routed to the functional equivalent of /dev/null is intolerably rude. In fact, I think sending a message with the intention of discarding any reply is pretty close to the maxiumum amount of disrespect you can show your message's recipient.
I have one message to the executives of companies that send email with 'no-reply' return addresses deserve to be faced with a boycott: If you're not interested in reading our replies, we're not interested in sending you any money either.
I don't think Microsoft Exchange addiction (as I've blogged on in the past, see my .signature) should count as an excuse either. Sending mail with a deliverable return address is a matter of a minimum of common courtesy and civilty.
Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.
Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.
My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.
The right-hand column on the BBC site has a link to a story called "Europe is 'losing' superbugs battle". The current story is a case in point: Europe is losing big time against the sinister "Stupidity" superbug.
For those of you who are interested in finding out the facts, start by reading the whole thread on openbsd-tech (eg http://marc.info/?t=129236639300001&r=1&w=2 ), it's only a handful of messages so far and I find Damien Miller's response at http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 particularly enlightening. (You're using Damien's code right now, in some other window -- he's been a major OpenSSH developer for quite a while).
Then again, I have to agree with Bob Beck (see http://marc.info/?l=openbsd-tech&m=129236730027908&w=2 ) that this is fairly likely to part of a personal vendetta of some sort, possibly against either the OpenBSD project or even something totally unrelated, using the OpenBSD project only as the attention-grabber in contexts such as /.
At this point we have only allegations with some finger pointing, I for one look forward to any real information to surface. The best way to draw out the real information behind this is to do what Theo did - publish the allegations and let the involved parties explain themselves in public.
I find it's always worth mentioning that there are publishers out there who respect their customers enough to not do the DRM dance, and from the author's view (yes, I am one) the danger of people not reading your stuff is more scary than the danger of not getting paid for every last copy.
Full disclosure: I have a book out on No Starch, The Book of PF, 2nd ed.
It's probably worth mentioning that there's at least one tech books publisher that publishes e-book versions in several formats (IIRC you get them all in a zip archive), with no DRM. That publisher is No Starch Press (http://nostarch.com).
I think for most of the writers who publish on No Starch, the thinking is that readers should have access to the material the form that's convenient to them, with as few restrictions as possible. For my own part, I see the bittorent trackers that turned up about four hours after the PDF version of the first edition of my book mainly as a sign that people appreciate my work.
Full disclosure: I have a title out on No Starch that's been available as ebook before the printed version is available (expected about Nov 10th), see http://nostarch.com/pf2.htm
Make sure you make a backup of your /etc/ directory beforehand and you are good to go. The upgrade process should keep your configuration intact, but it never hurts to be a bit cautious.
For /etc upgrades, there's sysmerge.
In fact, you can run sysmerge -x xetcNN.tgz -s etcNN.tgz and answer the friendly prompts before booting into the installer for the upgrade. Then after you've done the base system upgrade, set your PKG_PATH to something sensible and run pkg_add -u to upgrade your packages. Time needed is mainly a function of how good your connectivity to the packages mirror is.
There's a series of pictures at http://bsdly.blogspot.com/2010/01/goodness-of-men-and-machinery.html that tell you what the installer looked like in January. IIRC no huge changes have happened to it since then. But do try 4.8 or a recent snapshot (they come with installNN.iso files these days)
Repetition by hand, even by a skilled operator, is error prone. I think that's the main message in this article, and I couldn't agree more. The task at hand doesn't even have to be that complex. That's why, in a system administration context, tools like puppet (http://www.puppetlabs.com/) and cfengine (http://cfengine.com) make so much sense. Tools like those help you make sure that items that need to be the same stay the same, and make sure changes happen in sync across systems when need be (courtesy of your version control system). And of course, local variations can be catered to in a number of ways and maintained across global reconfigurations. If you're lucky enogh to be working on a Unix or BSD, that is. Not sure what's available in Cisco or Windows space.
This makes it fairly obvious that it was actually toads, not mice, that rigged up the earth in the first place.
Nice bit of coverup, Douglas!
Next up, what species if not the dolphins? And what's the real qoute behind "So long and thanks for all the fish?"?
Most likely you could talk your bank here into issuing a check for you if you ask them nicely, but it would almost certainly be more expensive than a straight electronic transfer.
On the other hand, somebody likely had fun and made a modest amount of money developing that check scannin app, so the effort I guess is not totally wasted.
They've also added a nice feature called expiretables that keeps the "bruteforce" table small & efficient by expiring entries that haven't seen any hits after a definable period of time.
FWIW, there's also an entry in the official PF FAQ on this...
Thanks for mentioning the tuturial, but actually expiretable is no longer necessary. On anything with PF equal to OpenBSD 4.1 or newer a simple
pfctl -t bruteforce -T expire 86400
will expire table entries that have not had their statistics updated for the last 24 hours (86400 seconds)
I really should reverse the sequence at that page. expiretable likely still works, but it is no longer necessary to install a separate package to get table expiry.
I see others have already mentioned my articles such as http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html, and if you take a peek in the list of addresses I put there, I would not be at all surprised if there's a great deal of overlap with the hosts that keep sniffing your servers (my data for that round has a little over 4000 hosts). In fact, it would be interesting to know how large or small the overlap is. They will keep trying (in fact I'm just seeing the start of another alphabetic phase over the last few days here) but there are a few things you can do to make it less likely they will succeed.
The general advice is, as you have heard many times before, to enforce a policy of no passwords, usin only key authentication, of course disable root logins and if practical limit where you can log in from to 'known good' IP addresses or ranges. The first two won't rid you of the logged attempts, but sensible in any case and makes the probability of ssh-based compromise quite a bit less likely.
Rate limiting helps get rid of the classical rapid-fire variety password guesser, but will not help at all when you're faced with the coordinated 'hail mary cloud' where each individual host could be attempting to access your system or network only every few hours.
As for portknocking, I seriously think the port knockers would be equally well served by switching all passwords to unicode. That provides a practical alphabet of the same number of unique characters (16 bits, remember), and for anyone with a large enough fleet of password guessers, the mechanics of guessing the right one is not all that different. Oh well, I just spilled the beans for the main point of an upcoming column, that won't spoil the fun later, I hope.
What then, if that secret, submarine patent is about something else entirely, or for that matter, does not even exist? For that matter, there could be several threats in play, patent based or otherwise, but anyway the main point of any such deal is to make sure the non-Microsoft party stays quiet, leaving Microsoft free to create the impression that Linux is somehow not quite legit, with no factual basis whatsoever.
We have no way of actually knowing, but it does appear that the US legal system somehow allows the kind of of behavior I suspect here as long as the actual underlying facts are not available to the public.
It doesn't even have to be a patent or a real issue at all, given the likely size of Microsoft's legal budget the threat of prolonged litigation backed up by the famous PR machine would be quite sufficient to intimidate smaller players to silence. Most of us are, after all, smaller players than Microsoft.
All idle speculation of course, but as long as they keep us in the dark about the facts of these deals, speculation will flourish.
We should not forget that within IPv4 space, reallocations do happen. Some organizations are AFAIK still sitting on routeable /8s for no good reason whatsoever, and possibly, maybe, some of that space will be redistributed one way or the other. Then of course those parts of the world that have actually switched to IPv6 are not likely to switch back (but you'd have to pry their 4to6 and 6to4 gateways from their dead, cold fingers), and actuall large segments of the Western world lives quite comfortably (fsvo) behind one or more layers of NAT.
So are we actually that close to running out?
Could be. It could also be that reallocations happen in IPv4 space that make the matter a little less urgent for just long enough that IPv6 wins the hearts and minds of the resisters or their objections are in fact addressed.
I set up SPF as kind of a desperation play more than anything else and the backscatter disappeared almost overnight. I'm sure someone out there is still receiving spam which appears to be sent from my domain, but the volume of backscatter I'm getting isn't even a tenth of what it once was. SPF is good for something.
The end of backscatter is more likely both a temporary thing and an indicator that they moved on to the next domains in their lists. They will be back sooner or later. In the meantime, you could use those backscatter addresses productively for such things as greytrapping (see eg http://www.bsdly.net/~peter/traplist.shtml, featured here at /. at various times). It is worth noting that the domains involved there had valid spf records before those backscatter storms started happening.
Oh, there's certainly a convenience factor, of course. The problem starts when your account with the default password is exposed to the world at large. In the case of the jailbroken iphones there is no sane reason to have a default password - for root of all things - in the first place.
And http://www.defaultpassword.com/?action=dpl&char=d confirms my hazy memory of the DEC field circus' User: field pass: service - which is good for a few stories in itself, of on-sites changing the password to 'circus' and a few mostly forgotten tales about putting modems into the mix and getting unusual activity from the field account.
Publishing your password on the net (which is roughly equivalent to what these lusers have done) borders on criminal negligence. I've ranted about this before (and yes, it was /.ed), and the conclusion remains the same:
if you run with a default password, for root or otherwise, you have effectively published that account's password.
What is bound to happen after you have published your password is left as an exercise to the eader.
the rickrolled iphones were vulnerable because the password had been published. published password == bad
The problem here seems to be badly maintained blacklists. After seeing way too many false positives on various blacklists out there, the only lists I would use are ones that expire their entries in a matter of days or hours. The good ones that I use are uatraps (greytrapping generated, 24 hour expiry) and nixspam (IIRC max 4 days after last seen spam activity). Then of course I maintain my own greytrap list (see the traplist homepage and the traplist ethics pagefor details).
The point is, you need to expire entries aggressively. Keeping entries around because somebody received a spam from somewhere in that general direction four years ago is just silly. And don't get me started on blacklisting domains. If there is one thing we know with almost total certainty, it is that spammers never use From: or Reply-to: addresses that have anything vaguely to do with the real senders.
Even without any sort of criminal record it's not a pleasant experience to enter the US, even as a Norwegian citizen entering via Canada. This May the robots routed me back form BSDCan (in Ottawa) through Washington, DC. It's possible that the fact that I did not apply for a visa (this was transit only, planning to stay on the ground roughly one hour between flights) complicated things a bit. As it turned out, in addition to the ordinary three forms (with more or less the same info in all of them) I needed to fill in a separate 'visa waiver form' (identical to at least two of the other forms in all other things than paper thickness, sheet size, color of paper and print and font) before getting to the fingerprinting, retina scanning and oral examination to check the validity of the information that I'd filled in, performed by a border guard who seemed to have been trained to appear hostile but was obviously monumentally bored by the whole process. This was after clearing the ordinary pre-boarding security theatre, mind you. And of course I would need to pick up the boarding passes for my connecting flights at the Washington, DC airport. That meant getting from one end of the airport to the other to pick up boarding passes and clearing another full act of security theatre in order to get back to where I could board the transatlantic flight. I did make my connecting fligh, running pretty much all the way except for the time spent lining up for the various security checks on the way. So yes, I can believe in a theory that US border control was a factor in deciding to place the next Olympics elsewhere.
The Spamhaus article really describes one of the most frequently encountered behaviors we see by looking at our spamd logs. Each machine does not necessarily send a large number of messages (although some do, hanging on for weeks on end in extreme cases), but once a machine has tried to deliver mail to one of our published trap addresses (see the list at http://www.bsdly.net/~peter/traplist.shtml ), we keep them occupied and publicly shamed (see http://www.bsdly.net/~peter/nameandshame.html as well as the exported blacklist) for 24 hours, or longer if they keep coming. I wrote about these things in some blog posts earlier that were /.ed, and of course the generated lists are free to use, see the URLs and the blog posts.
I generally do not get a lot of spam, but one episode recently made me collect some samples and blog about them (/.ed as Giving Your Greytrapping a Helping Hand).
That page also contains references such as the complete listing of subject lines from spammers caught in our blacklists over a few years' time.
Enjoy!
The main thing is, however, that the process was totally opaque, and how the system is supposed to work is a trade secret. Getting any kind of information out of Frontbridge at all was just not possible.
It's possible that the system was designed by very smart people, but I strongly suspect that those orignal brains took the money they got from Microsoft and ran, leaving the code and operation in less capable hands.