Modern operating systems juggle data between network stack layers using a buffering systems that usually leaves data in the same memory location once it is copied from virtual memory. If said buffer is allocated in a small space, and if the final push of that data into the ethernet hardware does not respect that small space, then this is the equivalent of a buffer overflow, except that it is reading beyond the buffer instead of writing. These being buffers in the network stack, and thus in the kernel in most systems, what you will most likely get is whatever follows that buffer in memory. Most likely that will be whatever data is in the same memory pool. That means it will be data the kernel itself is manipulating that requires similar allocation strategy as the network stack buffers. Most likely it will be data from other network stack buffers. Some of that data will be buffer pointers (not much use) or other packet data (in or out). In a modern switched LAN, sniffing is hard. To the machine getting these ethernet frames, which has to be in the same LAN, that's like being able to do a small bit of sniffing, but that the sniffing may include bits of kernel memory that were never part of packets, depending on the way the memory allocation in that kernel is handled.
I would agree the vulnerability is really really low. One reason for this is that most likely this memory will not include any virtual process space memory, since the allocation strategies are different. Only when a whole page is reclassified from being used for virtual memory to being used as allocation for small buffers, will there be any exposure of virtual memory from a process. And many programs that deal with sensitive information are already doing things like locking pages that contain clear passwords (to prevent them from ever reaching swap space) and actually clearing those fields when done.
In many cases the buffer location involved is in the ethernet device hardware itself. The driver would copy less than 46 bytes, but set the length to the minimum 46 and update the write queue registers to include it. Now the data sent is whatever was in the hardware memory. This won't expose kernel memory, but it can expose network transmitted data that would otherwise not been sniffable, to the one next hop machine it's destined to (assuming a switched LAN... a hubbed LAN already has greater risk than this on its own). This risk exists if the attacker is on the same LAN, so a remote exploit from over the internet won't be able to make use of this. Routers are not likely to be copying the padding along with the packet, although I can't say that this is a zero exposure.
This non-zero risk is not much of a performance hit to fix. Unless the ethernet device is doing direct memory access right out of the stack buffer, then some copying has to be involved. And how often are you needing extreme CPU performance while also sending lots of packets less than 46 bytes? Two major scenarios exist for why such small packets are going through. One is keystrokes. The other is an attack against this small vulnerability (pardon the pun). In either of these cases, I don't see where adding the extra CPU time to pad out the buffer target with zeros is going to push things over the edge. The one case where there might be a difficulty is when the network stack buffer is used directly, and in such a case it would have to be holding the whole ethernet frame in that buffer. The fix there would be to always make sure the buffer is allocated with the minimum required size (never smaller) and pad it there.
Your Fortune 500 company is very unlikely to be colocating sensitive machines where outsiders would have access to the same ethernet segment. Either you're running things in-house, or have outsourced to a major outsourcer, or have colocated things with router isolation involved. Just due to these factors, your risk drops just about as close to zero as you can get.
The cost in time needed to pad the frame out to 46 bytes is about the same as the time needed to copy the data over from some buffer when the frame actually is 46 bytes. Now if the driver is so high performance that it never copies anything, and is transmitting into hardware straight from the originally queued packet buffer, then yeah, padding to 46 bytes at this point does cost a wee bit. But how often are you sending so many packets less than this size and needing the performance in the CPU? It's not an issue at all with larger packets.
The open relay obscures the ability to block spam. It's either all permitted or all denied based on IP address.
This is just your broken filtering, which you insist on keeping broken. Your broken filtering isn't my problem. It is trivial to filter on the IP address in the Received Header. Even if the spammer inserts some additional forged headers, their real IP address is still there, and will be found on an IP address RBL.
This is where you are wrong. But I'm glad you are finally making it clear you expect people to accept the full body of every piece of junk mail and have to spend all that CPU time parsing each and every one of those headers.
You complain about standards, or lack thereof, for things like SMTP AUTH (even though a non-mandatory standard does exist for it, so we all can know how to do it in an interoperative way, which is what standards are really about). Yet there exists no standard on the syntax of the Received headers. The format might well be consistent for each piece of mail from your open relay, but that is just not so across the spectrum of all received header formats out there. The cost for me to parse these non-standardly formatted headers is greater than the cost to you to test the IP address, or user authentication, of incoming mail on your servers to be sure it's really your customer.
The open relay obscures the ability to block spam. It's either all permitted or all denied based on IP address.
It doesn't obscure anything. There is no difference (Header-wise) between spam sent through the spammer ISP's closed relay or an open relay. The same headers are in the messages as there are when the spammer uses their ISP's closed relay. If you filtered on IP addresses in the Received Headers, it wouldn't matter what relay (open or closed) the spammer used. They could use any relay, anywhere in the world, and it wouldn't make any difference. The spam would still be blocked. Which is my goal.
There is still the issue of having to accept message content and parse headers. See above.
Your concern is getting your legitimate mail through. To do that you need to find a way to make your legitimate mail distinguishable from any spam, or else make sure there is no spam. The choice is yours.
But of course, as you have said in the past, it isn't your goal to block spam. This explains why you insist on simplistic filtering and your insistence on the "necessity" of blocking open relays.
You've claimed this before. But I've never said such. You are apparently unable to distinguish between goals and methods.
Not all ISPs are willing to remove the spammer's connection. Of course we block those ISPs that do that. But because the spammer can get around it through open relays and open proxies, those get blocked, too
That doesn't mean you can't block spam. And this isn't my problem. I'm not responsible for some other ISP's policies. Their spammers still have IP addresses, just like everyone else. Those IP addresses go into Received headers, no matter what relay they use. Anonomizing relays and open proxies are a different problem, but can still be blocked by IP address, whether they use their ISP's closed relays, or some open relay.
If you run an open relay, your are responsible for making it difficult for me to distinguish legitimate mail sent through your server, from spam that irresponsible ISP is allowing their customers to send. You are responsible for your open relay. Why not mark which messages coming through are from your customers, and which are not?
And don't make threats against those who choose to not accept it. Then those who prefer to block only the open relays and not the whole network of the operator, can do so. It's the threats that I believe have resulted in most of the blocking of your entire net.
This is false. We are blocked in revenge because we block the relay testers. Also, we haven't made and 'threats' against anyone. We have successfully engaged the legal department of one ISP, after we learned of a credible threat to block our relays. The lawyers went head to head, and we won. Its not case law, but its clearly expert opinion. However, most ISP's don't block open relays. Very little of our email has ever been blocked. When it has, we've contacted the ISP, and the usual response is that they stop using the open relay list altogether. They could just whitelist us and keep using the open relay list. Instead, most people consider such blocking of legitimate mail, and entire ISP's inappropriate. They think the blacklist's goal is to block spam, and are usually quite unhappy to find out that isn't the case. And they're usually appreciative of the suggestion to use the IP address in the Received header, which improves their ability to block spam. Which is their goal, too.
I don't know if it's most or not, but a substantial number of ISPs do block open relays. It probably is most because the number of small ones run by the people in the trenches who really do know what is going on outnumber the few big ones run by pencil heads and golfing buddies who really don't have a clue about spam (or are looking to actually do some spamming for themselves some day). It sounds to me like you lied to a few ISPs because you very well know what blocking is all about. Or more likely you told them about the costs they would have litigating in court to a pinhead run ISP.
As far as legal action goes, the end users of an ISP have an expectation of privacy. There are laws that protect that privacy. That precludes ISP's from joining boycotts of legitimate email. The users' email isn't a pawn to be played with at the whim of some admin. It belongs to the user, not the ISP.
Joing boycotts, if you want to call it that, has nothing to do with privacy. It has everything to do with business relationships. Of course an ISP that blocks some mail a customer wanted in a manner outside of their business relationship is wrong. If the ISP advertised a service where all mail gets through, but secretly are blocking some mail for any reason, then that customer has cause to bring action against the ISP. Or they can take the easy route and switch to another ISP.
However, if the ISP offers as part of their service to help clean up the email by removing spam, and does not pretend that the system is perfect (no method is), then the business relationship is sound, and this is not a case of "playing with mail". That's what I offer to my customers now, and doing anything less would be against that business relationship.
Customers who have separate mail servers for their own domains (most of them) do get to have these things customized. A few have all anti-spam measures turned entirely off. Their choice, and it's easy to manage because it's a separate server. But I am planning on the next phase of mail services where customers can control their own email control policies even down to a single recipient address in the same domains as other users have different controls. Then it will be they who decide whether or not to trust your mail servers to carefully limit what they relay to just legitimate mail, or not.
I have no pre-existing business relation with Rackspace. I don't use their service. There is nothing to dump. They were cold-calling, probably from leads extracted from domain registrations (my guess). They did violate the No Call List.
Based on ads I do see, it still looks like most advertisers (decisions quite possibly being made at ad agencies) are expecting click-throughs. Those advertisers for which click-throughs are unexpected or unserving (e.g. McDonalds, and many of the other traditional consumer product categories I mentioned) tend not to be represented in web ads. The question is, is this because there is a perception that web advertising only works when click-through has significance (e.g. that there is no impressioning on people), or is it because even impression ads don't work?
Comparing web banner ads to say TV commercials is hard to do because TV commercials work different. They grab some time (of those not heading to the frig or the toilet, or fondling their remote) and get to tell a story, play a jingle, or just describe. Web ads have do have to make a more concise message. So the per impression price will be lower than the per impression price of a 30 second TV commercial. The question is how that affects advertising buying decisions. Just why is it that they are failing to buy impression based web advertising in the banner format?
Yes, I'll take a 5% commission on a new Mustang someone buys. But how likely is that to happen through my web page? Of course things like that are decisions I have to make. And I end up having to make that based on the demographics I bring in. Since my web page isn't about cars, or Mustangs, I suspect the probablity to be way too low to be worth it. I'll go with impression ads.
At the time of posting this comment, I have not changed my reply to the paper. That's still the first iteration on my reply. maybe you're reading into it more than is there.
I think the difference between what you perceive is going on, and what actually is going on, is more in the area of intention and goal, than in actual methods employed. I most certainly do add network ranges of ISPs, rather than just the spamming/relaying/proxying addressess, to the list, and use DNSBLs that also do such. So you are correct in understanding that my actions involve these full address ranges.
What you fail to understand are three critical things:
The reason this is done is because the actions of the ISP at the other end are causing my costs in dealing with spam to be greater. An open relay does this by preventing me from being able to test the originating IP address without having to go to the added cost of accepting DATA to get headers, and parsing it.
The goal isn't to suppress communication, since the ISP has the opportunity to correct these problems which are recognized by the vast majority as problems they are causing.
It's not the end of the world, since the addresses are not being blocked at the IP layer (with one exception right now). That does not mean I am refusing legitimate mail. What is means is I am applying finer tests to determine if the mail is legitimate; specifically I am in these cases testing the sender's email address.
Certainly the annoyance is a big cost. Costs are reduced by employing automated methods to prevent the spam from causing the annoyance. The issues I am dealing with regard the matter of keeping those automated costs low. If it was the case that I wanted to cut off all spam at all costs, I'd block your entire network at the IP layer and never have a process forked for any mail from there. But not getting legitimate mail is itself a cost, so I don't usually go to that extreme. Mail servers in your network can still establish an SMTP connection, and can still offer legitimate mail, and I still check the sender address to see if it is legitimate to the extent I know about. Your email address is in fact recognized; despite our disagreements, I have no reason to believe email from you is spam.
As for your cost figures, there are lots of things you are leaving out, and lots of things I'd most likely be leaving out if I spent the time to begin detailing them here. I won't, because it's not necessary. The reason is because my goal is to achieve the lowest cost, whatever I can determine that to be, not some specific fixed threshhold of cost. The lowest cost is going to depend on a lot of things, including my time (posting on slashdot, newsgroups, and mailing lists is not figured in), and goals of comfort, such as making sure my mail servers are typically running at less than 25% capacity (if one is regularly running at 30%, it's going to get upgraded somehow soon).
Banner ads are still done wrong on a lot of sites. The problem is they are too often arranged to be paid based on the number of times clicked, and ignore payment based on impression. Impression is how ads work in newspapers, magazines, television, and radio. But on the web, many advertisers saw the possibility of interactive clicking and just assumed a consumer would click on the ad whenever they wanted to find out more. Just notice how many ads don't really tell you in the ad what company or even what product/service is involved.
Unlike most of the other media, web users often tend to be motivated for other goals at the moment the ad is impressed. For example when visiting a portal like Ask Jeeves, they have something on their mind they are looking for. The ad is just a diversion and they are unlikely to go there.
But... ad impressions still work. They just have a latent psychological effect that builds up over time. Seeing the ad once, if its something you are really interested in, might get you over to that site... later on today. Or it might even get you to buy that product... later on this week. And if it's something you have no interest in at all, when you see that ad (best if it's not intrusive which would make it negative) many many times, you build up "brand awareness". Later, maybe many months later, when you do have a need for that product or service, or happen to be talking with someone who does, then the brand name comes up. When shopping for that kind of product and you see several choices on the store shelves, you're more inclined to pick the brand that was more advertised just because it now seems to be the more familiar brand... and you never even visited their web site.
If you like fast food and McDonalds adds a new product to their lineup which you might like, the banner ad for it might clue you in to this wonderful new treat. But are you likely to visit their web site? A few people might. Most won't. Are you likely to pull in the next time you're driving down the street while hungry on your lunch break? Very likely.
Too many web site operators think they have to be paid for advertising based on click throughs. That's just wrong, and it needs to change for web advertising to survive (the interactivity goals based on ads was never a realistic concept).
Too many businesses in product areas, especially consumer, where there is no real value of a web site to their product (fast food, small appliances, groceries, clothing, etc) are just not advertising on the web at all because they know people won't click on the ads to visit their site (no obvious value to it). What they are missing is that the impression model still works... or that they are afraid of advertising based on impressions because of some difficulties in accounting and auditing (mostly because its still too click-through oriented and these problems are not yet well solved).
Impression ads, of course, have to be cheaper per impression than a click-through. And this won't rule out still having click-through ads. While writing this comment the Think Geek ad for Bawls is blinking away at me. I'm not going to be visiting because I have no interest today. But if next month I happen to have an interest in it, I know where to go get it. That's latent response impression advertising. But it only works when the ad makes it clear where to go (domain names help if it's an online place to go). And it only works if the web site is going to get paid even if no one ever clicks on the ad.
The whole study is biased based on who happens to advertise for jobs on those boards, or on any boards at all. New jobs tend to be more for newfangled languages, whereas old jobs... most of which are filled and not turning over, are for older languages, such as C. The funny thing is I do frequently see jobs for C programmers, either for embedded systems, or for kernel drivers, on some boards. Why there is no showing at all is curious. It may be because the jobs get listed as "C/C++" (often times form based choices lump them together incorrectly... by someone who doesn't know the difference), and so what might be the case is that what is listed as C++ might in fact be C/C++ and therein the C jobs as well as C++ jobs. But I do not know for sure what the case really is.
Maybe if we categorize the programming jobs by application role, e.g. business logic, web, embedded, driver, systems, etc., as well as language (e.g. a 2-way table), we might get a clearer picture of what is going on. Unfortunately, most job boards do a really screwed up method of categorizing jobs.
If you are genuinely qualified to work here in highly technical and specialized jobs for which there is a true shortage of people here, then not only should you be able to get in, but you should be eligible for a permanent residency in short order (6 months at most), and on track for citizenship within 4 years... IMHO. But it seems at least 2/3 of H-1B people won't qualify from what I hear.
I'm sure he won't really want it. But still, the offer should be there. People that good should be let in permanently as citizens. Those that decide to take it will be welcome. And they can shop around for the best jobs, too... once the economy rebounds, whenever that might be.
There are plenty of unqualified people for every qualified person here. I'm sure there are in Canada, too. Post a job opening and see what you get. Run interviews and see how many people are qualified. Most aren't, for sure.
But... there are plenty who are qualified, yet they can't find work, either. The big reason is they have families, car loans, mortgages, and soon kids going off the college (with a higher probability than average of going into a tech field). That means they need a decent salary. But the corporations are trying to cut costs, and the easiest target to cut is people.
In some specialized fields there are genuine shortages of people that simply doubling salaries won't fix. Bringing them in from another country where they can be found is one solution. Someone from Canada is probably not going to be here cheap, but someone from India probably is... just look at the costs back home they will be looking at when they return in 3-6 years.
My question to you is, are you here for the short term (3-6 years on H-1B) or are you here to hopefully stay here if you can get the paperwork put through? If you're here to stay, they I say a big welcome. That's why I think we should scrap the H-1B program altogether and replace it with a special expedited green card for special cases, where the INS has to process them ahead of everything else (but why they have a 2 years backlog seems totally insane to me... if they don't want to let them have a green card, just deny it within 3 months and move on).
How about totally dropping the H-1B program altogether, and replace it with a program to expedite green cards for certain people specifically qualified.
If America wants to retain its technological lead in the world (which is rapidly slipping away right now), then it should take the best and the brightest... that want to come here to stay... and keep them, instead of bringing them in on what amounts to a government sanctioned program to train foreigners (taught for a couple weeks by the people who they are replacing). This would certainly eliminate the abuses of people that many employers are doing, and give them as much right as anyone else to shop around for a better job, better pay, better working conditions, and basic human respect (something that is lacking in a lot of jobs these days, especially those in larger corporations).
I was once approached by a company in Germany to go work for them on what was roughly an equivalent program there. While that did in fact sound interesting, I also knew I had no interest to permanently emigrate to Germany (they weren't expecting me to). My thought was, why not hire someone from Germany who would want the job. I'm sure there was someone who would. I suspect one reason they were hunting for people over here is a perception that we only take 2 weeks holiday instead of 6-8 weeks as I hear is common over there.
Rackspace is the ISP that has called me three times to try to sell me service, even though my phone number has been listed with the Texas No Call list for months. But they aren't the only one to call me. Comindico called me all the way from Australia to try to threaten me for blocking them because of spam. Their threat? That they would block me back. Oh boy.
The blocking of Rackspace.com is not revenge blocking. It is simply being blocked because Rackspace.com is not doing its part in being a member of a spam-free network community. By being blocked, it is thus cut off from the spam-free network community. It can go on sending to the spammy network community all it wants.
The open relay obscures the ability to block spam. It's either all permitted or all denied based on IP address. Some selection can be made by sender email address. But then, the open relay operator could filter on that, too.
Open relays impose added costs on recipients to filter out the spam. And this is done by the open relay operator to lower his costs. And that's one of the reasons I block open relays. But I do whitelist individual senders, so they can still use the open relay. I block them at SMTP MAIL FROM, not at the router.
The spammer can send via their ISP's relay, directly, or via an open relay. The only way to stop the spammer is to remove the spammer's connection, and the only entity that can do that is the spammer's ISP.
You repeatedly make pointless statements like that. Not all ISPs are willing to remove the spammer's connection. Of course we block those ISPs that do that. But because the spammer can get around it through open relays and open proxies, those get blocked, too.
There are reasons where open relays are necessary.
I've still not seen any specific reason for an open relay that isn't shot down by there being shown a way to do it without an open relay. I can't say there isn't one, but I've just never seen one, despite your repeated statement. But I am at least certain that if one is found, it represents and extremely rare circumstance. In any case, if you must run an open relay, be it for some obscure technical reason, or just laziness, then don't run any other customers through it. And don't make threats against those who choose to not accept it. Then those who prefer to block only the open relays and not the whole network of the operator, can do so. It's the threats that I believe have resulted in most of the blocking of your entire net.
And BTW, any mail from wherever it cannot be delivered in a legitimate way, I consider not to be legitimate mail. So I wouldn't be losing any legitimate mail by blocking an open relay used only for such obscure cases. Whether anything else gets lost is up to you.
We clearly disagree as to what "the problem" is. One aspect of that disagreement could come from a difference in understanding what "spam is". Some people look at it as a message content issue. I believe you are one of those people. Others believe it is a behaviour issue. I see it that way. And thus, there are differences.
I also want spam stopped without stopping legitimate mail. But we disagree in how to accomplish this. Your position is that no matter how the sender of the legitimate mail wants to send that mail, even if they want to send it in a way in which it cannot be easily distinguished from spam, that the legitimate mail must get through no matter what, even if that means lots of spam gets through. My position differs in that I believe the senders of legitimate mail should take some reasonable steps to distinguish their legitimate mail from spam. There are a number of different ways to do that:
Send the mail from an email address the recipient knows.
Send the mail from a server the recipient trusts.
Send the mail from a server the recipient has no reason to distrust.
The recipient's ISP, if one is involved, will certainly play a role, and the recipient and ISP need to have a known and agreed relationship with each other (if the ISP is using a blocking list the recipient is unaware of or does not approve of, that relationship isn't a proper one, and is beyond the scope of this discussion... the recipient needs to regain control at their end).
So my position on how to accomplish stopping spam while letting all legitimate mail through is that the sender of the legitimate mail has to play some part in the process. They cannot be totally passive and expect the recipient to do all the work in distinguishing legitimate mail from spam.
You say your goal isn't stopping spam. Thank you for being honest and forthright.
I did not say that my goal isn't stopping spam. You made that up, which is something I've seen from you before, so I'm not surprised. So go back and read what I said. It's even in the title. I said that collateral damage is part of the design. It's part of the methods employed to stop spam.
Again, it comes down to the behaviour of the senders (and their agents, their ISPs) and the behaviour of spammers. In order to stop spammers, the senders need to take on part of work involved. Those that refuse to are part of the problem because they are forcing even more costs on the recipients (in addition to what spammers do) by forcing the recipients to have to do all the work to separate legitimate mail from spam.
Consider your open relays. What's happening here is that the inputs will accept both legitimate mail as well as spam. Any mail server is subject to spam coming in, but an open relay is particularly vulnerable to this. An ISP operating a closed relay can apply sanctions against their customer base, which is a fraction of the whole internet base. But an open relay is equivalent to an ISP that has as its customer base the entirety of the internet. Since legitimate senders that are not a customer of the ISP running an open relay won't use that relay, the volume of legitimate mail going through the open relay is still a function of the customer base. But spammers don't play by the rules, and will use any open relay they can find, law be damned. That means any open relay is going to have a substantially higher percentage of spam compared to legitimate mail.
That means there is less distinguishability of legitimate mail from spam, and greater costs to the recipient (and/or his agent, his ISP).
Therefore, it is reasonable to make demands on the ISP running an open relay to close it, so that the legitimate mail coming through it won't have such high costs imposed on the recipient. The "collateral damage" design is part of the pressure being applied. Blocking only your open relays has some degree of collateral damage, but you are certainly in a position to correct that by routing all legitimate mail through other servers which are not the open relays.
That all of 130.105/16 and 198.3.136/24 are blocked goes to other reasons, and I don't know what they all might be. Certainly the fact that you willfully operate open relays is part of it, I'm sure. The fact that you are blocking relay testers probably is, as well, although you'll find I am in agreement with you as to the legality of such testing without consent. But I also believe that much blocking of those addresses is simply due to how you personally are dealing with the situation. Perhaps you have moved the open relays around to various other output addresses. That would certainly warrant a large scale blocking.
So basically it comes down to you having legitimate mail to be sent, but you are mixing it up with possible spam through an open relay, and are expecting recipients and their ISPs to sort out which is, or is not, spam (and without the benefit of being able to do so based on the IP address, because the SMTP client at this point is your open relay), yet you refuse to do the very same vetting of the mail coming through your open relay.
Senders of legitimate mail need to carry some of the burden of the spam fight, too.
Some of your arguments are against some of the activities of DNSBL operators that include open relays. Among the problems are things like doing unconsented relay testing, and making relay input lists available. But consider what if I ran an open relay DNS blacklist that held to certain strict standards:
Only actual open relay outputs will be listed.
The inputs will not be made available except to a small set of trusted people who have a good reason to know.
The networks hosting open relays will not be listed unless there is activity of moving open relays around to evade the blacklist.
No testing will be done unless the owner of the machine at the address in question consents to the test.
Once listed, an open relay will remain listed for 12 months since the last time any relayed spam was detected.
A listing can be removed if the owner consents (in writing, including a clause to agree not to sue) to a relay test and that relay test passes (e.g. nothing is forwarded) without any indication of an attempt to block the test.
If spam continues soon after a relay test passes, the relay will be listed for 12 years.
A second separate DNSBL will also be operated, which users may elect to use instead, which will not include all open relays in which the owner disputes the determination.
That would still end up listing your open relays if they have ever passed spam in the past 12 months. If you actually do integrate spam detection and refusal on the inputs, the probably there would be no spam, and it would not be listed. Now the question is, how would you react to that kind of DNSBL?
Slashdotters: read Dean's paper justifying his open relays here. Judge for yourself.
The author of the article is yet another person who misunderstands the problem. The problem is not how to prevent the delivery of spam; that has already been solved. The problem is how to get the ISPs hosting the spammers that continue to eat up our bandwidth to disconnect them from the network. Decent ISPs will just do that upon the discovery they have spammers. And it is acceptable to slap their hand once or even twice, but three spams and you're out. The problem is many ISPs are not decent at all, and will only act upon a financial incentive. Blocking the whole ISP is what is required. DNSBLs such as SPEWS are doing that incrementally with the intent to minimize the number of others affected for long enough to show to the ISP that they had better get rid of the spammers. At this point most ISPs will realize they will lose customers in the future, and will get rid of the spammers. A few will be stubborn, and will eventually have their entire address space listed. Not only do we not want mail from spammers, we don't want mail from anyone who supports spammers. And if you are paying money to an ISP who runs in turn is providing services to a spammer, then you are indirectly supporting spammers through financial benefits, such as the ISP offering the spammers lower rates through economy of scale. And do not forget that if you are doing this, that you and your ISP are benefitting off the costs incurred by others. All this article is, is a reflection of frustration by an individual who just doesn't get it, that he needs to either turn his ISP around to be a decent member of the internet community, or he needs to switch to another ISP. It looks like a lot of work went into it, but the premise being all wrong, the article is worthless and offers no solutions.
Personally, I still hate having encryption being done by "loop" device mechanisms. Moving too much out of the kernel might mean better kernel stability in the absence of more work to keep it stable, but it also ruins the uniform and secure abstractions. Ultimately there needs to be a new layer between kernel and processes, but that's getting way beyond the topic at hand. Instead, it should be integrated into the virtual device layer and virtual filesystem layer. And maybe someone could add decryption to grub and lilo so that we can even encrypt/boot. But for the most part, it's the patient health data (for which there is a huge black market by insurance companies, who also buy data from your grocer about your eating habits), the credit card data (especially stored at porn sites), and your personal porn, music, and movie collections, that really need the encryption... not the kernel or even the/usr files.
The data on all media, including hard drives, should be encrypted. When a computer boots up and needs access to that data, an unswappable process needs to get the passphrase/key so that the information can be made available at run time.
In the not too distant future you might be turned down for health insurance. Why you might ask? Because your grocery buying habits should an excessive proportion of fatty foods that cause high cholesterol, as well as the tobacco products, and all those pain relievers. They track you in the stores now, especially if you have a savings card.
Well, you and I know that it's relevant for actually accomplishing work. The problem is, not all of us have the writing skills to persuade the ignorant who think they know everything already.
I saw an enticing job at a small startup being advertised through a recruiter and decided to give it a shot. So I sent in my resume by email. A week went by and no answer at all, so I decided to email again just to ask. Two days and no answer so I decided to call. Took a day to catch up to him but I finally did. When I asked if he even got my resume he stumbled around on his paper stack and finally found it. "Oh, the mainframe guy!" NO!! "Dude, mainframes were a long time ago. I do Unix now, and have for years, and the job wanted someone with strong Unix." But his response was "Well, with all that experience, I figured you wouldn't want to work for a small startup. You seem like someone who would want to work at EDS or IBM". I had to make it clear to him that he completely and totally misread my resume.
Here's my advice... don't go back any further than 10 years of experience on your resume. Anything you did any further back is worthless today, anyway. And employers don't really care about mere experience in numbers; they want experience in what they have, only". The more experience you have in something else, the more expensive you are with no benefit to them.
And if you have more than 10 years experience, you better make sure you get it clear to recruiters, HR types, and in some cases, even the hiring managers, that you're looking for work in current state of the art technology, not in digital antiquities.
The terms in the agreement are probably meant to provide Microsoft with information about the students, possibly including things like when they graduate (making them eligible for Microsoft to begin marketing more software products to them). Notice the registration requirements. They may also include a requirement to provide to Microsoft a detailed accounting of all computers on campus and what OS they are running. Almost certainly these terms are intended to give Microsoft some special advantage in the post-academic commercial market, and perhaps to some extent to head off more deployment of Linux on campus, especially in areas exposed to the general student population (e.g. the labs of rows of computers for students to use). Financially, the university will be gaining, not losing. The question is what non-financial issue is lost that the university leadership doesn't care about.
Slashdot Mirror
Modern operating systems juggle data between network stack layers using a buffering systems that usually leaves data in the same memory location once it is copied from virtual memory. If said buffer is allocated in a small space, and if the final push of that data into the ethernet hardware does not respect that small space, then this is the equivalent of a buffer overflow, except that it is reading beyond the buffer instead of writing. These being buffers in the network stack, and thus in the kernel in most systems, what you will most likely get is whatever follows that buffer in memory. Most likely that will be whatever data is in the same memory pool. That means it will be data the kernel itself is manipulating that requires similar allocation strategy as the network stack buffers. Most likely it will be data from other network stack buffers. Some of that data will be buffer pointers (not much use) or other packet data (in or out). In a modern switched LAN, sniffing is hard. To the machine getting these ethernet frames, which has to be in the same LAN, that's like being able to do a small bit of sniffing, but that the sniffing may include bits of kernel memory that were never part of packets, depending on the way the memory allocation in that kernel is handled.
I would agree the vulnerability is really really low. One reason for this is that most likely this memory will not include any virtual process space memory, since the allocation strategies are different. Only when a whole page is reclassified from being used for virtual memory to being used as allocation for small buffers, will there be any exposure of virtual memory from a process. And many programs that deal with sensitive information are already doing things like locking pages that contain clear passwords (to prevent them from ever reaching swap space) and actually clearing those fields when done.
In many cases the buffer location involved is in the ethernet device hardware itself. The driver would copy less than 46 bytes, but set the length to the minimum 46 and update the write queue registers to include it. Now the data sent is whatever was in the hardware memory. This won't expose kernel memory, but it can expose network transmitted data that would otherwise not been sniffable, to the one next hop machine it's destined to (assuming a switched LAN ... a hubbed LAN already has greater risk than this on its own). This risk exists if the attacker is on the same LAN, so a remote exploit from over the internet won't be able to make use of this. Routers are not likely to be copying the padding along with the packet, although I can't say that this is a zero exposure.
This non-zero risk is not much of a performance hit to fix. Unless the ethernet device is doing direct memory access right out of the stack buffer, then some copying has to be involved. And how often are you needing extreme CPU performance while also sending lots of packets less than 46 bytes? Two major scenarios exist for why such small packets are going through. One is keystrokes. The other is an attack against this small vulnerability (pardon the pun). In either of these cases, I don't see where adding the extra CPU time to pad out the buffer target with zeros is going to push things over the edge. The one case where there might be a difficulty is when the network stack buffer is used directly, and in such a case it would have to be holding the whole ethernet frame in that buffer. The fix there would be to always make sure the buffer is allocated with the minimum required size (never smaller) and pad it there.
Your Fortune 500 company is very unlikely to be colocating sensitive machines where outsiders would have access to the same ethernet segment. Either you're running things in-house, or have outsourced to a major outsourcer, or have colocated things with router isolation involved. Just due to these factors, your risk drops just about as close to zero as you can get.
The cost in time needed to pad the frame out to 46 bytes is about the same as the time needed to copy the data over from some buffer when the frame actually is 46 bytes. Now if the driver is so high performance that it never copies anything, and is transmitting into hardware straight from the originally queued packet buffer, then yeah, padding to 46 bytes at this point does cost a wee bit. But how often are you sending so many packets less than this size and needing the performance in the CPU? It's not an issue at all with larger packets.
This is where you are wrong. But I'm glad you are finally making it clear you expect people to accept the full body of every piece of junk mail and have to spend all that CPU time parsing each and every one of those headers.
You complain about standards, or lack thereof, for things like SMTP AUTH (even though a non-mandatory standard does exist for it, so we all can know how to do it in an interoperative way, which is what standards are really about). Yet there exists no standard on the syntax of the Received headers. The format might well be consistent for each piece of mail from your open relay, but that is just not so across the spectrum of all received header formats out there. The cost for me to parse these non-standardly formatted headers is greater than the cost to you to test the IP address, or user authentication, of incoming mail on your servers to be sure it's really your customer.
There is still the issue of having to accept message content and parse headers. See above.
Your concern is getting your legitimate mail through. To do that you need to find a way to make your legitimate mail distinguishable from any spam, or else make sure there is no spam. The choice is yours.
You've claimed this before. But I've never said such. You are apparently unable to distinguish between goals and methods.
If you run an open relay, your are responsible for making it difficult for me to distinguish legitimate mail sent through your server, from spam that irresponsible ISP is allowing their customers to send. You are responsible for your open relay. Why not mark which messages coming through are from your customers, and which are not?
I don't know if it's most or not, but a substantial number of ISPs do block open relays. It probably is most because the number of small ones run by the people in the trenches who really do know what is going on outnumber the few big ones run by pencil heads and golfing buddies who really don't have a clue about spam (or are looking to actually do some spamming for themselves some day). It sounds to me like you lied to a few ISPs because you very well know what blocking is all about. Or more likely you told them about the costs they would have litigating in court to a pinhead run ISP.
Joing boycotts, if you want to call it that, has nothing to do with privacy. It has everything to do with business relationships. Of course an ISP that blocks some mail a customer wanted in a manner outside of their business relationship is wrong. If the ISP advertised a service where all mail gets through, but secretly are blocking some mail for any reason, then that customer has cause to bring action against the ISP. Or they can take the easy route and switch to another ISP.
However, if the ISP offers as part of their service to help clean up the email by removing spam, and does not pretend that the system is perfect (no method is), then the business relationship is sound, and this is not a case of "playing with mail". That's what I offer to my customers now, and doing anything less would be against that business relationship.
Customers who have separate mail servers for their own domains (most of them) do get to have these things customized. A few have all anti-spam measures turned entirely off. Their choice, and it's easy to manage because it's a separate server. But I am planning on the next phase of mail services where customers can control their own email control policies even down to a single recipient address in the same domains as other users have different controls. Then it will be they who decide whether or not to trust your mail servers to carefully limit what they relay to just legitimate mail, or not.
I have no pre-existing business relation with Rackspace. I don't use their service. There is nothing to dump. They were cold-calling, probably from leads extracted from domain registrations (my guess). They did violate the No Call List.
Based on ads I do see, it still looks like most advertisers (decisions quite possibly being made at ad agencies) are expecting click-throughs. Those advertisers for which click-throughs are unexpected or unserving (e.g. McDonalds, and many of the other traditional consumer product categories I mentioned) tend not to be represented in web ads. The question is, is this because there is a perception that web advertising only works when click-through has significance (e.g. that there is no impressioning on people), or is it because even impression ads don't work?
Comparing web banner ads to say TV commercials is hard to do because TV commercials work different. They grab some time (of those not heading to the frig or the toilet, or fondling their remote) and get to tell a story, play a jingle, or just describe. Web ads have do have to make a more concise message. So the per impression price will be lower than the per impression price of a 30 second TV commercial. The question is how that affects advertising buying decisions. Just why is it that they are failing to buy impression based web advertising in the banner format?
Yes, I'll take a 5% commission on a new Mustang someone buys. But how likely is that to happen through my web page? Of course things like that are decisions I have to make. And I end up having to make that based on the demographics I bring in. Since my web page isn't about cars, or Mustangs, I suspect the probablity to be way too low to be worth it. I'll go with impression ads.
At the time of posting this comment, I have not changed my reply to the paper. That's still the first iteration on my reply. maybe you're reading into it more than is there.
I think the difference between what you perceive is going on, and what actually is going on, is more in the area of intention and goal, than in actual methods employed. I most certainly do add network ranges of ISPs, rather than just the spamming/relaying/proxying addressess, to the list, and use DNSBLs that also do such. So you are correct in understanding that my actions involve these full address ranges.
What you fail to understand are three critical things:
Certainly the annoyance is a big cost. Costs are reduced by employing automated methods to prevent the spam from causing the annoyance. The issues I am dealing with regard the matter of keeping those automated costs low. If it was the case that I wanted to cut off all spam at all costs, I'd block your entire network at the IP layer and never have a process forked for any mail from there. But not getting legitimate mail is itself a cost, so I don't usually go to that extreme. Mail servers in your network can still establish an SMTP connection, and can still offer legitimate mail, and I still check the sender address to see if it is legitimate to the extent I know about. Your email address is in fact recognized; despite our disagreements, I have no reason to believe email from you is spam.
As for your cost figures, there are lots of things you are leaving out, and lots of things I'd most likely be leaving out if I spent the time to begin detailing them here. I won't, because it's not necessary. The reason is because my goal is to achieve the lowest cost, whatever I can determine that to be, not some specific fixed threshhold of cost. The lowest cost is going to depend on a lot of things, including my time (posting on slashdot, newsgroups, and mailing lists is not figured in), and goals of comfort, such as making sure my mail servers are typically running at less than 25% capacity (if one is regularly running at 30%, it's going to get upgraded somehow soon).
Banner ads are still done wrong on a lot of sites. The problem is they are too often arranged to be paid based on the number of times clicked, and ignore payment based on impression. Impression is how ads work in newspapers, magazines, television, and radio. But on the web, many advertisers saw the possibility of interactive clicking and just assumed a consumer would click on the ad whenever they wanted to find out more. Just notice how many ads don't really tell you in the ad what company or even what product/service is involved.
Unlike most of the other media, web users often tend to be motivated for other goals at the moment the ad is impressed. For example when visiting a portal like Ask Jeeves, they have something on their mind they are looking for. The ad is just a diversion and they are unlikely to go there.
But ... ad impressions still work. They just have a latent psychological effect that builds up over time. Seeing the ad once, if its something you are really interested in, might get you over to that site ... later on today. Or it might even get you to buy that product ... later on this week. And if it's something you have no interest in at all, when you see that ad (best if it's not intrusive which would make it negative) many many times, you build up "brand awareness". Later, maybe many months later, when you do have a need for that product or service, or happen to be talking with someone who does, then the brand name comes up. When shopping for that kind of product and you see several choices on the store shelves, you're more inclined to pick the brand that was more advertised just because it now seems to be the more familiar brand ... and you never even visited their web site.
If you like fast food and McDonalds adds a new product to their lineup which you might like, the banner ad for it might clue you in to this wonderful new treat. But are you likely to visit their web site? A few people might. Most won't. Are you likely to pull in the next time you're driving down the street while hungry on your lunch break? Very likely.
Too many web site operators think they have to be paid for advertising based on click throughs. That's just wrong, and it needs to change for web advertising to survive (the interactivity goals based on ads was never a realistic concept).
Too many businesses in product areas, especially consumer, where there is no real value of a web site to their product (fast food, small appliances, groceries, clothing, etc) are just not advertising on the web at all because they know people won't click on the ads to visit their site (no obvious value to it). What they are missing is that the impression model still works ... or that they are afraid of advertising based on impressions because of some difficulties in accounting and auditing (mostly because its still too click-through oriented and these problems are not yet well solved).
Impression ads, of course, have to be cheaper per impression than a click-through. And this won't rule out still having click-through ads. While writing this comment the Think Geek ad for Bawls is blinking away at me. I'm not going to be visiting because I have no interest today. But if next month I happen to have an interest in it, I know where to go get it. That's latent response impression advertising. But it only works when the ad makes it clear where to go (domain names help if it's an online place to go). And it only works if the web site is going to get paid even if no one ever clicks on the ad.
The whole study is biased based on who happens to advertise for jobs on those boards, or on any boards at all. New jobs tend to be more for newfangled languages, whereas old jobs ... most of which are filled and not turning over, are for older languages, such as C. The funny thing is I do frequently see jobs for C programmers, either for embedded systems, or for kernel drivers, on some boards. Why there is no showing at all is curious. It may be because the jobs get listed as "C/C++" (often times form based choices lump them together incorrectly ... by someone who doesn't know the difference), and so what might be the case is that what is listed as C++ might in fact be C/C++ and therein the C jobs as well as C++ jobs. But I do not know for sure what the case really is.
Maybe if we categorize the programming jobs by application role, e.g. business logic, web, embedded, driver, systems, etc., as well as language (e.g. a 2-way table), we might get a clearer picture of what is going on. Unfortunately, most job boards do a really screwed up method of categorizing jobs.
If you are genuinely qualified to work here in highly technical and specialized jobs for which there is a true shortage of people here, then not only should you be able to get in, but you should be eligible for a permanent residency in short order (6 months at most), and on track for citizenship within 4 years ... IMHO. But it seems at least 2/3 of H-1B people won't qualify from what I hear.
I'm sure he won't really want it. But still, the offer should be there. People that good should be let in permanently as citizens. Those that decide to take it will be welcome. And they can shop around for the best jobs, too ... once the economy rebounds, whenever that might be.
There are plenty of unqualified people for every qualified person here. I'm sure there are in Canada, too. Post a job opening and see what you get. Run interviews and see how many people are qualified. Most aren't, for sure.
But ... there are plenty who are qualified, yet they can't find work, either. The big reason is they have families, car loans, mortgages, and soon kids going off the college (with a higher probability than average of going into a tech field). That means they need a decent salary. But the corporations are trying to cut costs, and the easiest target to cut is people.
In some specialized fields there are genuine shortages of people that simply doubling salaries won't fix. Bringing them in from another country where they can be found is one solution. Someone from Canada is probably not going to be here cheap, but someone from India probably is ... just look at the costs back home they will be looking at when they return in 3-6 years.
My question to you is, are you here for the short term (3-6 years on H-1B) or are you here to hopefully stay here if you can get the paperwork put through? If you're here to stay, they I say a big welcome. That's why I think we should scrap the H-1B program altogether and replace it with a special expedited green card for special cases, where the INS has to process them ahead of everything else (but why they have a 2 years backlog seems totally insane to me ... if they don't want to let them have a green card, just deny it within 3 months and move on).
How about totally dropping the H-1B program altogether, and replace it with a program to expedite green cards for certain people specifically qualified.
If America wants to retain its technological lead in the world (which is rapidly slipping away right now), then it should take the best and the brightest ... that want to come here to stay ... and keep them, instead of bringing them in on what amounts to a government sanctioned program to train foreigners (taught for a couple weeks by the people who they are replacing). This would certainly eliminate the abuses of people that many employers are doing, and give them as much right as anyone else to shop around for a better job, better pay, better working conditions, and basic human respect (something that is lacking in a lot of jobs these days, especially those in larger corporations).
I was once approached by a company in Germany to go work for them on what was roughly an equivalent program there. While that did in fact sound interesting, I also knew I had no interest to permanently emigrate to Germany (they weren't expecting me to). My thought was, why not hire someone from Germany who would want the job. I'm sure there was someone who would. I suspect one reason they were hunting for people over here is a perception that we only take 2 weeks holiday instead of 6-8 weeks as I hear is common over there.
Rackspace is the ISP that has called me three times to try to sell me service, even though my phone number has been listed with the Texas No Call list for months. But they aren't the only one to call me. Comindico called me all the way from Australia to try to threaten me for blocking them because of spam. Their threat? That they would block me back. Oh boy.
The blocking of Rackspace.com is not revenge blocking. It is simply being blocked because Rackspace.com is not doing its part in being a member of a spam-free network community. By being blocked, it is thus cut off from the spam-free network community. It can go on sending to the spammy network community all it wants.
The open relay obscures the ability to block spam. It's either all permitted or all denied based on IP address. Some selection can be made by sender email address. But then, the open relay operator could filter on that, too.
Open relays impose added costs on recipients to filter out the spam. And this is done by the open relay operator to lower his costs. And that's one of the reasons I block open relays. But I do whitelist individual senders, so they can still use the open relay. I block them at SMTP MAIL FROM, not at the router.
You repeatedly make pointless statements like that. Not all ISPs are willing to remove the spammer's connection. Of course we block those ISPs that do that. But because the spammer can get around it through open relays and open proxies, those get blocked, too.
I've still not seen any specific reason for an open relay that isn't shot down by there being shown a way to do it without an open relay. I can't say there isn't one, but I've just never seen one, despite your repeated statement. But I am at least certain that if one is found, it represents and extremely rare circumstance. In any case, if you must run an open relay, be it for some obscure technical reason, or just laziness, then don't run any other customers through it. And don't make threats against those who choose to not accept it. Then those who prefer to block only the open relays and not the whole network of the operator, can do so. It's the threats that I believe have resulted in most of the blocking of your entire net.
And BTW, any mail from wherever it cannot be delivered in a legitimate way, I consider not to be legitimate mail. So I wouldn't be losing any legitimate mail by blocking an open relay used only for such obscure cases. Whether anything else gets lost is up to you.
We clearly disagree as to what "the problem" is. One aspect of that disagreement could come from a difference in understanding what "spam is". Some people look at it as a message content issue. I believe you are one of those people. Others believe it is a behaviour issue. I see it that way. And thus, there are differences.
I also want spam stopped without stopping legitimate mail. But we disagree in how to accomplish this. Your position is that no matter how the sender of the legitimate mail wants to send that mail, even if they want to send it in a way in which it cannot be easily distinguished from spam, that the legitimate mail must get through no matter what, even if that means lots of spam gets through. My position differs in that I believe the senders of legitimate mail should take some reasonable steps to distinguish their legitimate mail from spam. There are a number of different ways to do that:
- Send the mail from an email address the recipient knows.
- Send the mail from a server the recipient trusts.
- Send the mail from a server the recipient has no reason to distrust.
The recipient's ISP, if one is involved, will certainly play a role, and the recipient and ISP need to have a known and agreed relationship with each other (if the ISP is using a blocking list the recipient is unaware of or does not approve of, that relationship isn't a proper one, and is beyond the scope of this discussionSo my position on how to accomplish stopping spam while letting all legitimate mail through is that the sender of the legitimate mail has to play some part in the process. They cannot be totally passive and expect the recipient to do all the work in distinguishing legitimate mail from spam.
I did not say that my goal isn't stopping spam. You made that up, which is something I've seen from you before, so I'm not surprised. So go back and read what I said. It's even in the title. I said that collateral damage is part of the design. It's part of the methods employed to stop spam.
Again, it comes down to the behaviour of the senders (and their agents, their ISPs) and the behaviour of spammers. In order to stop spammers, the senders need to take on part of work involved. Those that refuse to are part of the problem because they are forcing even more costs on the recipients (in addition to what spammers do) by forcing the recipients to have to do all the work to separate legitimate mail from spam.
Consider your open relays. What's happening here is that the inputs will accept both legitimate mail as well as spam. Any mail server is subject to spam coming in, but an open relay is particularly vulnerable to this. An ISP operating a closed relay can apply sanctions against their customer base, which is a fraction of the whole internet base. But an open relay is equivalent to an ISP that has as its customer base the entirety of the internet. Since legitimate senders that are not a customer of the ISP running an open relay won't use that relay, the volume of legitimate mail going through the open relay is still a function of the customer base. But spammers don't play by the rules, and will use any open relay they can find, law be damned. That means any open relay is going to have a substantially higher percentage of spam compared to legitimate mail.
That means there is less distinguishability of legitimate mail from spam, and greater costs to the recipient (and/or his agent, his ISP).
Therefore, it is reasonable to make demands on the ISP running an open relay to close it, so that the legitimate mail coming through it won't have such high costs imposed on the recipient. The "collateral damage" design is part of the pressure being applied. Blocking only your open relays has some degree of collateral damage, but you are certainly in a position to correct that by routing all legitimate mail through other servers which are not the open relays.
That all of 130.105/16 and 198.3.136/24 are blocked goes to other reasons, and I don't know what they all might be. Certainly the fact that you willfully operate open relays is part of it, I'm sure. The fact that you are blocking relay testers probably is, as well, although you'll find I am in agreement with you as to the legality of such testing without consent. But I also believe that much blocking of those addresses is simply due to how you personally are dealing with the situation. Perhaps you have moved the open relays around to various other output addresses. That would certainly warrant a large scale blocking.
So basically it comes down to you having legitimate mail to be sent, but you are mixing it up with possible spam through an open relay, and are expecting recipients and their ISPs to sort out which is, or is not, spam (and without the benefit of being able to do so based on the IP address, because the SMTP client at this point is your open relay), yet you refuse to do the very same vetting of the mail coming through your open relay.
Senders of legitimate mail need to carry some of the burden of the spam fight, too.
Some of your arguments are against some of the activities of DNSBL operators that include open relays. Among the problems are things like doing unconsented relay testing, and making relay input lists available. But consider what if I ran an open relay DNS blacklist that held to certain strict standards:
- Only actual open relay outputs will be listed.
- The inputs will not be made available except to a small set of trusted people who have a good reason to know.
- The networks hosting open relays will not be listed unless there is activity of moving open relays around to evade the blacklist.
- No testing will be done unless the owner of the machine at the address in question consents to the test.
- Once listed, an open relay will remain listed for 12 months since the last time any relayed spam was detected.
- A listing can be removed if the owner consents (in writing, including a clause to agree not to sue) to a relay test and that relay test passes (e.g. nothing is forwarded) without any indication of an attempt to block the test.
- If spam continues soon after a relay test passes, the relay will be listed for 12 years.
- A second separate DNSBL will also be operated, which users may elect to use instead, which will not include all open relays in which the owner disputes the determination.
That would still end up listing your open relays if they have ever passed spam in the past 12 months. If you actually do integrate spam detection and refusal on the inputs, the probably there would be no spam, and it would not be listed. Now the question is, how would you react to that kind of DNSBL?Slashdotters: read Dean's paper justifying his open relays here . Judge for yourself.
The author of the article is yet another person who misunderstands the problem. The problem is not how to prevent the delivery of spam; that has already been solved. The problem is how to get the ISPs hosting the spammers that continue to eat up our bandwidth to disconnect them from the network. Decent ISPs will just do that upon the discovery they have spammers. And it is acceptable to slap their hand once or even twice, but three spams and you're out. The problem is many ISPs are not decent at all, and will only act upon a financial incentive. Blocking the whole ISP is what is required. DNSBLs such as SPEWS are doing that incrementally with the intent to minimize the number of others affected for long enough to show to the ISP that they had better get rid of the spammers. At this point most ISPs will realize they will lose customers in the future, and will get rid of the spammers. A few will be stubborn, and will eventually have their entire address space listed. Not only do we not want mail from spammers, we don't want mail from anyone who supports spammers. And if you are paying money to an ISP who runs in turn is providing services to a spammer, then you are indirectly supporting spammers through financial benefits, such as the ISP offering the spammers lower rates through economy of scale. And do not forget that if you are doing this, that you and your ISP are benefitting off the costs incurred by others. All this article is, is a reflection of frustration by an individual who just doesn't get it, that he needs to either turn his ISP around to be a decent member of the internet community, or he needs to switch to another ISP. It looks like a lot of work went into it, but the premise being all wrong, the article is worthless and offers no solutions.
Personally, I still hate having encryption being done by "loop" device mechanisms. Moving too much out of the kernel might mean better kernel stability in the absence of more work to keep it stable, but it also ruins the uniform and secure abstractions. Ultimately there needs to be a new layer between kernel and processes, but that's getting way beyond the topic at hand. Instead, it should be integrated into the virtual device layer and virtual filesystem layer. And maybe someone could add decryption to grub and lilo so that we can even encrypt /boot. But for the most part, it's the patient health data (for which there is a huge black market by insurance companies, who also buy data from your grocer about your eating habits), the credit card data (especially stored at porn sites), and your personal porn, music, and movie collections, that really need the encryption ... not the kernel or even the /usr files.
The data on all media, including hard drives, should be encrypted. When a computer boots up and needs access to that data, an unswappable process needs to get the passphrase/key so that the information can be made available at run time.
In the not too distant future you might be turned down for health insurance. Why you might ask? Because your grocery buying habits should an excessive proportion of fatty foods that cause high cholesterol, as well as the tobacco products, and all those pain relievers. They track you in the stores now, especially if you have a savings card.
Well, you and I know that it's relevant for actually accomplishing work. The problem is, not all of us have the writing skills to persuade the ignorant who think they know everything already.
I saw an enticing job at a small startup being advertised through a recruiter and decided to give it a shot. So I sent in my resume by email. A week went by and no answer at all, so I decided to email again just to ask. Two days and no answer so I decided to call. Took a day to catch up to him but I finally did. When I asked if he even got my resume he stumbled around on his paper stack and finally found it. "Oh, the mainframe guy!" NO!! "Dude, mainframes were a long time ago. I do Unix now, and have for years, and the job wanted someone with strong Unix." But his response was "Well, with all that experience, I figured you wouldn't want to work for a small startup. You seem like someone who would want to work at EDS or IBM". I had to make it clear to him that he completely and totally misread my resume.
Here's my advice ... don't go back any further than 10 years of experience on your resume. Anything you did any further back is worthless today, anyway. And employers don't really care about mere experience in numbers; they want experience in what they have, only". The more experience you have in something else, the more expensive you are with no benefit to them.
And if you have more than 10 years experience, you better make sure you get it clear to recruiters, HR types, and in some cases, even the hiring managers, that you're looking for work in current state of the art technology, not in digital antiquities.
The terms in the agreement are probably meant to provide Microsoft with information about the students, possibly including things like when they graduate (making them eligible for Microsoft to begin marketing more software products to them). Notice the registration requirements. They may also include a requirement to provide to Microsoft a detailed accounting of all computers on campus and what OS they are running. Almost certainly these terms are intended to give Microsoft some special advantage in the post-academic commercial market, and perhaps to some extent to head off more deployment of Linux on campus, especially in areas exposed to the general student population (e.g. the labs of rows of computers for students to use). Financially, the university will be gaining, not losing. The question is what non-financial issue is lost that the university leadership doesn't care about.
When to REALLY worry about your gun? When you notice what's stamped on the inside of the grip is an IPv6 address.