The problem is that the feature is fricking undocumented
Just so I understand the fricking problem...
If you have a PGP-encrypted drive, and you know the passphrase, you can unlock the drive until the next reboot. But PGP - and others as well, from TFA - have added a mode that unlocks it until the reboot AFTER that.
Most people wouldn't want to use such a feature, because it leaves your drive exposed for a longer period of time. Even PGP calls it "dangerous, but needed" (for enterprise environments that do remote reboots). Companies that need it know they need it; anyone else would merely be shooting themselves in the foot to use it.
And the fricking problem is that PGP hasn't publicized how to use that dangerous feature?
Hah.. I'd read the whole thread and hadn't even thought about that question. Not a bad point. I mean, my word processor can use different fonts and colors, so why can't the scheduler?
Forward Link Reverse Retrieve Mail Protocol - Is likely the answer, apparently can be implemented side-by-side with "standard" email protocols until adopted Internet wide. http://www.mollensoft.com/FLRRMaP_Protocol_V3.htm
I dunno about "likely the answer". He's basically reinvented what Nathaniel Borenstein (father of MIME) called "rock mail" - I put a message under a rock, tell you where the rock is, and you go get it from under the rock.
AOL's mail system works this way, as do Exchange and other corporate mail systems. When you send mail from one AOL address to another, you don't really "send" anything; it stores the message on the server, and puts a post-it note in the inbox of all the recipients. When they check their mail, they read it from that same server. This lets you do neat tricks like "Unsend" and "Check Status"; plus you can verify recipient addresses instantly at "send" time, and you can have different clients see different versions of the message.
But that's inside a closed system; it doesn't scale well to the whole Internet.
Problems off the top of my head:
* How do I, the sending server, know that the "callback" I'm getting is really from the recipient server, and not from someone who intercepted the message? * Who says the sender can't be a spambot? A spambot could easily stay online long enough to receive the callback. * How do you deal with multiple recipients, mailing lists, etc.? One copy on the sending server for each recipient? That makes mailing lists very, very heavy.
This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters
- It causes backscatter - It doesn't work with mail from mailing lists - It's not accessible
Additionally: - It doesn't work well with sites that have many MTAs (requires one bounce/CAPTCHA per MTA) - It doesn't work well with an SMTP server that sends for many domains (requires one bounce per MTA per outgoing domain) - It merely confirms that "this server can send mail for domain X". If you've got a spambot and can determine your user's domain name (e.g. comcast.com), this won't stop anything at all.
The author brushes off concerns with bold (well, italic now) statements like:
Resend software is a simple onetime update for webmail systems, email clients, and local mail servers...Universal Distribution of Auto-Resend Software is a Surprisingly Simple Thing to Achieve
Hah! A simple one-time update for all servers and clients everywhere! Granted, RIA doesn't depend on that update happening, but it's clear even the author thinks it'd be a pain without auto-resend.
There is little disincentive to implement Auto-Resend software as it is a one-time upgrade that remains dormant until needed.
There is a huge disincentive; looking up a user's mailbox to see if he did, indeed, send the message you claim he sent is a ridiculously expensive operation, if it's even possible at the server level. It could also lead to a privacy leak if done wrong; people could forge RIA bounces to probe outgoing mail flows.
At best, it potentially doubles the volume of outgoing mail, which deepens queues, requires more disk space, etc. etc.
I'm guessing the author is unfamiliar with high-volume mail sites - the very ones he wants to implement this scheme first.
Suspicious Domains Will Be Neutralized By CAPTCHA Encoded Sub-addresses
Great. So now e-mail that's "suspicious" requires intervention from a sighted human, and all his "auto-resend" silver bullets are used up. He does imagine yet another client change that will "nicely reformat" a CAPTCHA. Yeah, right. Oh, and now he's e-mailing me graphics on my Blackberry.
In general, he seems to imagine that he personally runs the One True RIA list, and we all trust his determinations of what is and isn't "suspicious", with reputation scores, rate limiting, etc. That is, of course, ridiculous; the original MAPS RBL has splintered and grown to the point where there are over 200 DNSBLs available.
He talks about automatically e-mailing users that he has "detected" are running zombies. Right, because that's a good idea and isn't spam.
Domains commonly associated with phishing (e.g. Paypal.com, Citibank.com)
As if there's a way to create a comprehensive, or even useful, list of "domains commonly associated with phishing".
with the passage of time it will become difficult for spammers to purport that all of their spam is sent via increasingly obsolete or esoteric brands of software. Of course it won't. I still get spam from "The Bat!". Before, he forgot about the big guys; now he's forgetting about the long tail. Spammers can make up any number of X-Mailer names.
I don't follow your claim; if a spammer sends spam in my name, and it hits the RIA filter, what makes you say the backscatter is not also sent to my name? According to TFA, it is (assuming my name is "Stranger aat mysterious dotcom").
And no, I'm not automatically filtering out MAILER-DAEMON, because (to the increasingly limited extent that bounces are sent these days) it's useful if I make a typo on an outgoing e-mail.
This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters; I'll post more later in the thread.
Actually the misunderstanding is yours...So in fact it is a criminal act for someone to impede your freedom of speech
Hey, look! Someone from outside the U.S., who doesn't know anything about U.S. law, is telling other people they're wrong while, himself, being wrong! When has that ever happened on Slashdot before?
AArrgh... Too many old-fart nerd jokes here! I'm gonna&#*(% NO CARRIER
Which ironically brings me back to the first time I saw an emoticon - not on a BBS, but on Q-Link, in chat rooms. I'd been through hell with NYNEX to get clean phone lines (this was back when data was "unsupported" by the phone company), and they worked fine on BBS's, but the minute I connected to Q-Link I started seeing all this "line noise" at the end of each line.
A friendly QGUIDE explained what the line noise meant.
I wish I could remember what we used to call them before emoticons - there was another word, and "emoticon" was something I first saw in the press, not online. Anyone remember?
Apple's secrecy doesn't jive very well with a lot of corporate environments either. IT departments like to plan well ahead, and Apple (almost) unpredictably changing hardware etc. doesn't give them a very good feeling.
That can't be emphasized enough. Microsoft may be the Devil, but Apple reserves the right to be. Sadly, I see a lot more information and openness from Microsoft these days than Apple. We knew details about Vista for years (and years, and years) before release and could prepare. We still don't know much about Leopard internals - and I mean the technical details, not what shadow gradient the icons use.
Developer blogs? Microsoft yes, Apple no. Notice of upcoming incompatibilities? Microsoft yes, Apple not so much. Works on any Intel-based hardware? Microsoft yes, Apple no. Acknowledgements of known bugs? Microsoft yes, Apple rarely.
I'm hardly a Microsoft fanboi; I just bought a MacBook Pro to replace my OLD MacBook Pro, and my next desktop will be a Mac Pro. That way, I can run my choice of software pretty seamlessly in any of my four major environments: Windows, OS X, UNIX/POSIX (/KDE/GNOME), and Java. But not everyone wants to go buy an 8GB machine to have multiple VMs running.
Apple's really hip right now, but I don't think their closed-off approach will benefit them in the long term.
I've been programming for 19 years. You or an immediate family member HAS used code I've written. And you know what? I have no freaking idea what the difference between a "systems analyst", a "programmer" and a "software engineer" are.
OK, that's not strictly true. I know how I could divide up the responsibilities if I had to, and assign different working styles to each title. But I've never had to. I also know that ten techies will have eleven opinions on what the distinctions are and whether they matter.
I started as a "Programmer/Analyst", because that was the fashionable title in those days. Later, we spent two years and a great sum of money revamping the entire company's title scheme, and I became a software "engineer". Later, they wanted to keep me, so they made me a software "architect" to give me a raise. And still later, it was time for a promotion, so I became a chief architect.
You know what? I did the same thing in every one of those positions. Sure, I got better over time, but my approach never changed. I look at programming, or development, or software architecture, or what have you, as a young engineering discipline. There's no certification for it, like there is for P.E.s, and maybe there never will be. And some people suck at it, and some people do "programming by coincidence", and some can do in an hour what others do in a day.
But if you can pass the engineering test, you can be a software engineer. And the engineering test is this:
1. If you see a picture on the wall that is crooked, do you:
(a) do nothing.
(b) Straighten it.
(c) Spend the next six months learning a high-end CAD/CAM system and buying a 3D printer so that you can design and fabricate a self-powered, self-levelling, automatic picture hook.
Man, am I glad I live in Massachusetts, where it's illegal for the manufacturer OR the vendor to waive (or get the buyer to waive) the warrantees of merchantability (is this thing worth selling to you?) and fitness for a particular purpose (is it designed like something that was designed to do what it is designed to do?).
If you sell me a laptop, it's designed to open, close, move around, and run an operating system. If it doesn't do all those for a reasonable period of time, you damn well better believe it's defective, and if you can't return it to the manufacturer, then that's a problem between you and the manufacturer.
The focus in court was not on the end user - AOL and CompuServe were filing the lawsuit, not their users. The focus was on whether the data in the headers - including the SMTP HELO header, which is buried in down in the headers - were fooling AOL's servers.
In fact, there was another angle besides forgery - the Computer Fraud and Abuse act. I can't remember if that's a Virginia law or a federal law, but the argument (which IIRC was successful) was that if a spammer sent "HELO aol.com" to work around filters that were blocking his real domain, "iamaspammer.com", he was gaining access to the mail server by providing fraudulent information.
Similarly, if I'm a Comcast subscriber, Comcast is sending data that claims to originate from me in order to gain access to the torrent provider's computer that they would not otherwise have - in this case, the access to say "I'm hanging up".
I don't think that's much different than header-forging. But check http://legal.web.aol.com/ if you want to delve into the arguments - my memory's fuzzy.
I don't think it necessarily follows that this can be construed as impersonation of an individual::shrug:: At AOL, we successfully sued for trademark infringement and forgery based on From: foo@aol.com in the headers.
We've got code here that refers to 'insurrances', 'insurances', 'insurrences' and 'insurences', I'm not kidding.
I believe it. A very early Q-Link programmer (or perhaps even a PlayNet programmer) couldn't spell "certificate" properly. As a result, all login and registration code for the next ten years had to access "cirtificate.db", because it was too embedded to change easily...
I've used Antares AutoTune and Celemony Melodyne, two of the popular pitch-correctors, and both default to equal-tempered. I never looked to see if they'd support alternate tunings, since it wasn't relevant to the music I was working on.
It always pisses me off that some web services say in their very long agreement that they have the right to change the terms at any time IIUC, this ruling doesn't apply to those contracts. This says a consumer has no general obligation to keep checking the contract. It doesn't say a consumer can't agree to assume such an obligation by, say, signing a contract.
Ah! A1 clarifies. It sounded like you were saying it was impossible/unlikely/etc for Hotmail addresses to be brute-force guessed. I agree, if these were at your own domain (or some other domain but the Top Four), it's unlikely, because spammers don't spend the time.
However, that doesn't necessarily imply an internal security breach. Are you familiar with cross-site request forgery? That's one possible way that a spammer could get at the Hotmail address book. There may be others.
Because e-mails can have multiple recipients, it does not take 100 bytes per recipient to send spam; it takes address_length + 11 (RCPT TO: . Thus, your calculation of 16 years for a brute-force search is wrong.
Also, you calculated using an assumption of 100MB of bandwidth. Because spammers have bots, they have far more than that at their disposal - couple of million computers, assume they're mostly broadband, figure maybe 256Kb per computer on average to be conservative? So that's what, 8GB of bandwidth? Thus, your calculation of 16 years is also wrong.
Hotmail is one of the biggest mail systems in the world. Spammers are constantly, CONSTANTLY targeting Hotmail's inbound servers to scour for valid addresses, whether you find it a "foolish and practically impossible task" or not. It's not just "one domain", as if spammers were busy trying dictionary attacks on every domain in the universe. It's Hotmail. Spammers focus on AOL, GMail, Hotmail, Yahoo, because that's where their bang for the buck is. They've been doing it for years. They get far more than "just a few" spammable addresses with brute-force attacks.
Is there evidence that spammers in your example used such a technique? Not that either of us can know without reading the Hotmail server logs. There's no evidence they didn't, though, other than your disbelief that such a thing even exists - and I can counter that disbelief with actual experience. Are your spammers special? Maybe. But you seem awfully focused on the math and the RFCs (all of which I can read, thank you, much of which I have memorized, and some of which I have contributed to) and not the real world. If something mathematically impossible happens every day in the real world, you probably have the math wrong.
So far, the only evidence you've provided of your example being a security breach is that you can't conceive of any other way it could have happened. That's called an "argument from incredulity". It's a fallacy to begin with, and it holds even less water if you find real, every day events incredulous.
Slashdot Mirror
The problem is that the feature is fricking undocumented
Just so I understand the fricking problem...
If you have a PGP-encrypted drive, and you know the passphrase, you can unlock the drive until the next reboot. But PGP - and others as well, from TFA - have added a mode that unlocks it until the reboot AFTER that.
Most people wouldn't want to use such a feature, because it leaves your drive exposed for a longer period of time. Even PGP calls it "dangerous, but needed" (for enterprise environments that do remote reboots). Companies that need it know they need it; anyone else would merely be shooting themselves in the foot to use it.
And the fricking problem is that PGP hasn't publicized how to use that dangerous feature?
Hah.. I'd read the whole thread and hadn't even thought about that question. Not a bad point. I mean, my word processor can use different fonts and colors, so why can't the scheduler?
Forward Link Reverse Retrieve Mail Protocol - Is likely the answer, apparently can be implemented side-by-side with "standard" email protocols until adopted Internet wide. http://www.mollensoft.com/FLRRMaP_Protocol_V3.htm
I dunno about "likely the answer". He's basically reinvented what Nathaniel Borenstein (father of MIME) called "rock mail" - I put a message under a rock, tell you where the rock is, and you go get it from under the rock.
AOL's mail system works this way, as do Exchange and other corporate mail systems. When you send mail from one AOL address to another, you don't really "send" anything; it stores the message on the server, and puts a post-it note in the inbox of all the recipients. When they check their mail, they read it from that same server. This lets you do neat tricks like "Unsend" and "Check Status"; plus you can verify recipient addresses instantly at "send" time, and you can have different clients see different versions of the message.
But that's inside a closed system; it doesn't scale well to the whole Internet.
Problems off the top of my head:
* How do I, the sending server, know that the "callback" I'm getting is really from the recipient server, and not from someone who intercepted the message?
* Who says the sender can't be a spambot? A spambot could easily stay online long enough to receive the callback.
* How do you deal with multiple recipients, mailing lists, etc.? One copy on the sending server for each recipient? That makes mailing lists very, very heavy.
This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters
- It causes backscatter
- It doesn't work with mail from mailing lists
- It's not accessible
Additionally:
- It doesn't work well with sites that have many MTAs (requires one bounce/CAPTCHA per MTA)
- It doesn't work well with an SMTP server that sends for many domains (requires one bounce per MTA per outgoing domain)
- It merely confirms that "this server can send mail for domain X". If you've got a spambot and can determine your user's domain name (e.g. comcast.com), this won't stop anything at all.
The author brushes off concerns with bold (well, italic now) statements like:
Resend software is a simple onetime update for webmail systems, email clients, and local mail servers...Universal Distribution of Auto-Resend Software is a Surprisingly Simple Thing to Achieve
Hah! A simple one-time update for all servers and clients everywhere! Granted, RIA doesn't depend on that update happening, but it's clear even the author thinks it'd be a pain without auto-resend.
There is little disincentive to implement Auto-Resend software as it is a one-time upgrade that remains dormant until needed.
There is a huge disincentive; looking up a user's mailbox to see if he did, indeed, send the message you claim he sent is a ridiculously expensive operation, if it's even possible at the server level. It could also lead to a privacy leak if done wrong; people could forge RIA bounces to probe outgoing mail flows.
At best, it potentially doubles the volume of outgoing mail, which deepens queues, requires more disk space, etc. etc.
I'm guessing the author is unfamiliar with high-volume mail sites - the very ones he wants to implement this scheme first.
Suspicious Domains Will Be Neutralized By CAPTCHA Encoded Sub-addresses
Great. So now e-mail that's "suspicious" requires intervention from a sighted human, and all his "auto-resend" silver bullets are used up. He does imagine yet another client change that will "nicely reformat" a CAPTCHA. Yeah, right. Oh, and now he's e-mailing me graphics on my Blackberry.
In general, he seems to imagine that he personally runs the One True RIA list, and we all trust his determinations of what is and isn't "suspicious", with reputation scores, rate limiting, etc. That is, of course, ridiculous; the original MAPS RBL has splintered and grown to the point where there are over 200 DNSBLs available.
He talks about automatically e-mailing users that he has "detected" are running zombies. Right, because that's a good idea and isn't spam.
Domains commonly associated with phishing (e.g. Paypal.com, Citibank.com)
As if there's a way to create a comprehensive, or even useful, list of "domains commonly associated with phishing".
with the passage of time it will become difficult for spammers to purport that all of their spam is sent via increasingly obsolete or esoteric brands of software.
Of course it won't. I still get spam from "The Bat!". Before, he forgot about the big guys; now he's forgetting about the long tail. Spammers can make up any number of X-Mailer names.
I don't follow your claim; if a spammer sends spam in my name, and it hits the RIA filter, what makes you say the backscatter is not also sent to my name? According to TFA, it is (assuming my name is "Stranger aat mysterious dotcom").
And no, I'm not automatically filtering out MAILER-DAEMON, because (to the increasingly limited extent that bounces are sent these days) it's useful if I make a typo on an outgoing e-mail.
This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters; I'll post more later in the thread.
Actually the misunderstanding is yours...So in fact it is a criminal act for someone to impede your freedom of speech
Hey, look! Someone from outside the U.S., who doesn't know anything about U.S. law, is telling other people they're wrong while, himself, being wrong! When has that ever happened on Slashdot before?
AArrgh... Too many old-fart nerd jokes here! I'm gonna&#*(% NO CARRIER
Which ironically brings me back to the first time I saw an emoticon - not on a BBS, but on Q-Link, in chat rooms. I'd been through hell with NYNEX to get clean phone lines (this was back when data was "unsupported" by the phone company), and they worked fine on BBS's, but the minute I connected to Q-Link I started seeing all this "line noise" at the end of each line.
A friendly QGUIDE explained what the line noise meant.
I wish I could remember what we used to call them before emoticons - there was another word, and "emoticon" was something I first saw in the press, not online. Anyone remember?
Nice ATtitude. Triple-plus.
I was thinking more of Kernel-level stuff like what Mark Russinovich tends to write about.
Apple's secrecy doesn't jive very well with a lot of corporate environments either. IT departments like to plan well ahead, and Apple (almost) unpredictably changing hardware etc. doesn't give them a very good feeling.
That can't be emphasized enough. Microsoft may be the Devil, but Apple reserves the right to be. Sadly, I see a lot more information and openness from Microsoft these days than Apple. We knew details about Vista for years (and years, and years) before release and could prepare. We still don't know much about Leopard internals - and I mean the technical details, not what shadow gradient the icons use.
Developer blogs? Microsoft yes, Apple no. Notice of upcoming incompatibilities? Microsoft yes, Apple not so much. Works on any Intel-based hardware? Microsoft yes, Apple no. Acknowledgements of known bugs? Microsoft yes, Apple rarely.
I'm hardly a Microsoft fanboi; I just bought a MacBook Pro to replace my OLD MacBook Pro, and my next desktop will be a Mac Pro. That way, I can run my choice of software pretty seamlessly in any of my four major environments: Windows, OS X, UNIX/POSIX (/KDE/GNOME), and Java. But not everyone wants to go buy an 8GB machine to have multiple VMs running.
Apple's really hip right now, but I don't think their closed-off approach will benefit them in the long term.
I call pessimism.
I've been programming for 19 years. You or an immediate family member HAS used code I've written. And you know what? I have no freaking idea what the difference between a "systems analyst", a "programmer" and a "software engineer" are.
OK, that's not strictly true. I know how I could divide up the responsibilities if I had to, and assign different working styles to each title. But I've never had to. I also know that ten techies will have eleven opinions on what the distinctions are and whether they matter.
I started as a "Programmer/Analyst", because that was the fashionable title in those days. Later, we spent two years and a great sum of money revamping the entire company's title scheme, and I became a software "engineer". Later, they wanted to keep me, so they made me a software "architect" to give me a raise. And still later, it was time for a promotion, so I became a chief architect.
You know what? I did the same thing in every one of those positions. Sure, I got better over time, but my approach never changed. I look at programming, or development, or software architecture, or what have you, as a young engineering discipline. There's no certification for it, like there is for P.E.s, and maybe there never will be. And some people suck at it, and some people do "programming by coincidence", and some can do in an hour what others do in a day.
But if you can pass the engineering test, you can be a software engineer. And the engineering test is this:
1. If you see a picture on the wall that is crooked, do you:
(a) do nothing.
(b) Straighten it.
(c) Spend the next six months learning a high-end CAD/CAM system and
buying a 3D printer so that you can design and fabricate a self-powered,
self-levelling, automatic picture hook.
If you answered (c), you passed.
Man, am I glad I live in Massachusetts, where it's illegal for the manufacturer OR the vendor to waive (or get the buyer to waive) the warrantees of merchantability (is this thing worth selling to you?) and fitness for a particular purpose (is it designed like something that was designed to do what it is designed to do?).
If you sell me a laptop, it's designed to open, close, move around, and run an operating system. If it doesn't do all those for a reasonable period of time, you damn well better believe it's defective, and if you can't return it to the manufacturer, then that's a problem between you and the manufacturer.
Well, it wasn't a bold new invention until you went and typed it in bold.
You have doomed us all. Thanks, kenh.
Trouble is you have to press all four paws at once to get her into valet mode.
The focus in court was not on the end user - AOL and CompuServe were filing the lawsuit, not their users. The focus was on whether the data in the headers - including the SMTP HELO header, which is buried in down in the headers - were fooling AOL's servers.
In fact, there was another angle besides forgery - the Computer Fraud and Abuse act. I can't remember if that's a Virginia law or a federal law, but the argument (which IIRC was successful) was that if a spammer sent "HELO aol.com" to work around filters that were blocking his real domain, "iamaspammer.com", he was gaining access to the mail server by providing fraudulent information.
Similarly, if I'm a Comcast subscriber, Comcast is sending data that claims to originate from me in order to gain access to the torrent provider's computer that they would not otherwise have - in this case, the access to say "I'm hanging up".
I don't think that's much different than header-forging. But check http://legal.web.aol.com/ if you want to delve into the arguments - my memory's fuzzy.
Jay
I don't think it necessarily follows that this can be construed as impersonation of an individual ::shrug:: At AOL, we successfully sued for trademark infringement and forgery based on From: foo@aol.com in the headers.
I don't think this is materially different.
We've got code here that refers to 'insurrances', 'insurances', 'insurrences' and 'insurences', I'm not kidding.
I believe it. A very early Q-Link programmer (or perhaps even a PlayNet programmer) couldn't spell "certificate" properly. As a result, all login and registration code for the next ten years had to access "cirtificate.db", because it was too embedded to change easily...
I've used Antares AutoTune and Celemony Melodyne, two of the popular pitch-correctors, and both default to equal-tempered. I never looked to see if they'd support alternate tunings, since it wasn't relevant to the music I was working on.
When researchers fitted monitors to their computers, workers were found to be viewing e-mails up to 40 times an hour.
Workers using computers without monitors checked their e-mail far less often.
It always pisses me off that some web services say in their very long agreement that they have the right to change the terms at any time
s ays-aol.html
IIUC, this ruling doesn't apply to those contracts. This says a consumer has no general obligation to keep checking the contract. It doesn't say a consumer can't agree to assume such an obligation by, say, signing a contract.
See analysis at http://pubcit.typepad.com/clpblog/2007/07/courts-
And you don't think those access points are all made by Apple? That's not much of a test.
Now I won't have to switch from one system to the other on long drives.
Ah! A1 clarifies. It sounded like you were saying it was impossible/unlikely/etc for Hotmail addresses to be brute-force guessed. I agree, if these were at your own domain (or some other domain but the Top Four), it's unlikely, because spammers don't spend the time.
However, that doesn't necessarily imply an internal security breach. Are you familiar with cross-site request forgery? That's one possible way that a spammer could get at the Hotmail address book. There may be others.
I guess I wasn't clear enough.
Because e-mails can have multiple recipients, it does not take 100 bytes per recipient to send spam; it takes address_length + 11 (RCPT TO: . Thus, your calculation of 16 years for a brute-force search is wrong.
Also, you calculated using an assumption of 100MB of bandwidth. Because spammers have bots, they have far more than that at their disposal - couple of million computers, assume they're mostly broadband, figure maybe 256Kb per computer on average to be conservative? So that's what, 8GB of bandwidth? Thus, your calculation of 16 years is also wrong.
Hotmail is one of the biggest mail systems in the world. Spammers are constantly, CONSTANTLY targeting Hotmail's inbound servers to scour for valid addresses, whether you find it a "foolish and practically impossible task" or not. It's not just "one domain", as if spammers were busy trying dictionary attacks on every domain in the universe. It's Hotmail. Spammers focus on AOL, GMail, Hotmail, Yahoo, because that's where their bang for the buck is. They've been doing it for years. They get far more than "just a few" spammable addresses with brute-force attacks.
Is there evidence that spammers in your example used such a technique? Not that either of us can know without reading the Hotmail server logs. There's no evidence they didn't, though, other than your disbelief that such a thing even exists - and I can counter that disbelief with actual experience. Are your spammers special? Maybe. But you seem awfully focused on the math and the RFCs (all of which I can read, thank you, much of which I have memorized, and some of which I have contributed to) and not the real world. If something mathematically impossible happens every day in the real world, you probably have the math wrong.
So far, the only evidence you've provided of your example being a security breach is that you can't conceive of any other way it could have happened. That's called an "argument from incredulity". It's a fallacy to begin with, and it holds even less water if you find real, every day events incredulous.
Yes, they do. You forgot two things: Mail can have multiple recipients, and spammers have bots.
Find it theoretically impossible, if you like - I've watched the spammers hit the servers.