I submit that I have every right to have an open relay, and not risk having my e-mail blocked based solely on that basis.
I submit that I have a right to not accept e-mail from your open relay for no reason whatsoever (but generally I will do so because it is an open relay). If mail is relayed through your server, then I see that as sufficient proof for my purposes. I'm not asking the government to come take your personal freedom away, or take your driver's license away, or even take your network connection away (though many would want that taken away). IMHO, you have the right to be connected to the internet with an open relay if you want, but you have no right to expect that everyone must accept mail from your server, or even accept any IP packets from you, because of being an open relay.
Liken open relaying to doing bizarre behaviour, or having serious body odor because you don't shower. It's your right to do that. But it's also my right to have nothing to do with you and not even hire you. We just keep apart.
There is nothing wrong with running an open relay, if you manage it right and the volume is low enough that it is reasonable to do so. Shouldn't it be your right, without fear of someone else trying to modify your behavior?
First of all, in reality, it won't happen. As soon as the first spammer discovers your open relay they will spam. And I got hold of one of these spam lists and found that the very first entries are of spamware authors and other spammers. So they are going to be among the first to be spammed by the spammer that found your open relay. Now several spammers have your IP address. It will be like a shark feeding frenzy. Eventually the spamming gets down to the addresses that have will alert the blacklist operators, and you get blacklisted.
I don't want the spam, and I'll accept the collateral damage of loss of legitimate mail from your server in exchange for protection from the spam. And that's my choice and I have the right to make that choice, and base it on information I believe to be factual (e.g. ordb and orbz). You have the freedom to choose which way you want to behave, and all that comes with it (or not).
I make the decision whether to accept or reject mail before the headers and body are ever received. I don't want to be handling the returns on the rejections because I've accepted delivery, and then have to deal with huge queues of rejections that can't be delivered. I let the sending server do that.
These operations also get listed in other ways, too. The identity of their network generaly gets discovered and places like spamhaus.org will list them.
It seems a bit ridiculous that they can leave listings in their databases that misrepresent other company's standards, simply because an open SMTP relay was left active inside the host's network.
It is not ridiculous at all. In fact this is exactly what they are supposed to do. If there is an open relay, and they say there is an open relay, they are telling the truth, and you have absolutely no cause to complain. Blacklists are not saying that such-and-such company has bad standards... they saying that such-and-such IP address or network has an open relay (or whatever the case may be).
If your customer configured the server wrong, making it an open relay, then it is that customer you should be collecting recovery costs from. In the future, be sure terms that specify this is in your contact that you have each customer sign. Be sure the spam and open relay issues are discussed with them before the service is turned on.
And further, set up a testing facility which will probe all the IP addresses on your own network for open relays. Your own customers should not be relaying for any other of your customers, nor for your own machines, so you can do this entirely in-house. Leave the IP address of this testing machine out of the "local networks" list of your own mail servers and it can test them, too. Have it cycle through the network several times a day sending mail to an outside domain name which gets forwarded from there back to you. The contents of the message would be what the tester is testing, and with that and headers, you can see what server suddenly became an open relay before the spammers find it and cause you all this massive grief. And since it is your network, you have all the legal rights to probe it (but add this to your contact terms just to be on the safer side).
Now your next problem is those nasty form mail scripts that use a hidden field for where to send the mail. There is spamware available to use those to send spam. They simply fabricate the browser submission, with a false hidden address field containing the spam victim's address, and submit it to the web server. Such scripts should not be allowed on any web server in your network, with no exceptions made. Scanning around for them is harder due to the variety of potential pathnames they could be found it. The only form mail scripts that should be used are ones where the destination address is stored in the script itself, or in a database the script uses to lookup using the referer URL.
You didn't indicate if this is an on-campus or off-campus problem. Since most other schools have solved the problem, I'm assuming yours could, too, if you applied the correct solution.
First of all, mail coming in from off-campus is the issue with regard to open-relay. If you have students/staff spamming from on-campus, you do have better access to identifying who they are and dealing with it. But for off-campus, it's much harder, so it needs to be denied.
Many schools provide dialup services for staff and students off campus (some free, some for an added fee). This won't be a problem for the open relay issue as long as the dialup access itself is authenticated as usual.
Those off campus using a commercial ISP have a couple of choices. One is to just use the ISP's mail server for outbound, while picking up the mail at the school POP3 server for their dot.edu address. Most ISPs allow "From: anywhere" in the mail (means nothing, really). If a local ISP does not, you could ask them to allow the school's domain through (else you'd have to recommend to the school community not to use that ISP). And of course there is the POP-before-send approach which you can use to let the off-campus community send through the campus mail servers.
So basically, this is easier than you are making it out to be.
This is (by being dumb and setting up an open relay at first) how you get on 3000 (estimated) private blacklists. You get off mine by asking me to take you off (I do the first 2 times). Part of the problem is that many businesses just have their MCSE kid set it up.
It can't be a decent mailserver if the administrative staff who configure the network can't get it right. I'd worry that if they are too incompetent to get DNS right, they're probably too incompetent to get the mail server right. If it's not an open relay today, it might become one tomorrow.
Requiring reverse PTR names to provide a forward A record that matches the connecting IP is a bozo sysadmin filter. And it does a damn good job of filtering out huge numbers of direct marketers and eastern Asian pirated open relay MS Exchange servers.
I do have a list of a few IP addresses that I accept mail from regardless of any DNS problem or blacklist. If you really need to send me mail, have a static IP and an incompetent ISP, get on Hotmail and send me your story (why you can't change to competent ISP, and what your static IP address is), then I can open it up for you.
Doesn't matter. I don't want mail from generic dialup/DSL/broadband connections, anyway. If you're running a BSD or Linux box on such a connection, then either forward outbound mail through their central (presumably correctly DNS'd) mail servers, get a static IP with correct PTR+A entries, get a better ISP, or write to your MP.
An open relay is not necessary in order to make email function at the outlying offices. You don't even need a VPN. The mail server can be configured with the static IP addresses of each of the offices as valid "local" addresses. Of course a VPN is much better as that also improves your security.
As confirmed by another of your postings, your company management are morons who have apparently hired idiots for the IT department. Obviously you recognize it, and can leave if you feel that is necessary, or can stay as long as you can deal with it, and are not blamed for it. Should they ever offer to promote you into IT, be sure you insist that you be given the authority to fix the problems with no further permission from management to go ahead.
Basing the filter on the Reply-To header is rather stupid.
Maybe. If it is negative filtering, blocking the reply addresses that spammers actually use, which would hopefully not be what you use, then it may work. And it has less collateral damage, unless someone spams with the intent to hurt you by using your email address, or this happens out of coincidence.
Still, the best way to block spam, IMHO, is at the SMTP connection, before it is even delivered, despite some collateral damage. As long as eBay, Paypal, and other like places are not blocked (while I currently refuse to do any business with Paypal for several reasons, I do not block their email), you should be able to communicate with them using SMTP connection level anti-spam (e.g. DNS based blacklists, or local blacklists databases). Giving a 5XX rejection gives you notice (if your mail server does the right thing and sends it to you), so you do find out about the problem and know it's not someone ignoring you.
In general I don't like basing the filtering on any aspect of the message content because that means the message had to be delivered to see that (including the RFC822 headers). Since it was delivered, then if it is rejected, my servers have to send the rejection notice back. And, since so many are bogus, my outbound queue is huge, and my postmaster box gets flooded for the failures to deliver the rejection. Stopping the spam before it is even delivered (based on connecting IP address as looked up via DNS blacklists or a local DB, or that IP's domain name using reverse the forward verification, or even the MAIL FROM string) givs a 5XX rejection over SMTP and commits the sending server to return the rejection instead of mine.
Unfortunately we're not free and can't be everywhere.
That's not as big an "unfortunately" as you might think it is. The bigger "unfortunately" is that the Brightmail website does not give enough information up front to decide if this product/service is suitable enough to be worth contacting the company about.
It doesn't explain how the Brightmail server interacts with other mail servers and customer domains.
It doesn't explain how Brightmail works with variant email addresses.
It doesn't give any information whatsoever about pricing.
It doesn't explain how it deals with issues of customer privacy and confidentiality.
It doesn't explain what security audits have been done on the server software itself.
It just leaves people in the dark (that's not very "bright"). So for now it's a direction I won't be going, even though I have no qualms about paying for good service. Maybe if you can get the marketing people to make a better website, more people might become interested. It's not like you have anything to hide, being protected by patent 6052709.
One of my mail servers ended up on ORBZ as well as ORDB because I had made a mistake in the configuration, and I corrected it and was promptly removed after submitting a re-test request.
Did you learn from that experience to test your mail server after making configuration changes? I don't know if ORDB, ORBZ, and others track servers that get added back to the list repeatedly. But at some point (about 3 or 4), I'd want to start extending the time after being tested as clean, like maybe an additional week for every time above 3 that the server has been listed in the past 180 days). Surely you would no longer allow your mail server get go back to being an open relay. But some people it seems just don't really care, especially if they know where to go get delisted quickly.
I would agree an organized blacklist should be used in preference to private ones... as soon as one that meets my needs can be found.
Those that are out there either block stuff I do not want blocked (and don't separate the zones to give me a choice), or are not very effective in doing quick blocking.
So I do block some on my own. But unless it is clearly a spamhaus (no point in ever trying to communicate with them), or a direct dialup/DSL pool (I block them by reverse-to-forward-verified domain name), I do send abuse@ the complaint with instructions to ask me to unblock. They don't even have to tell me they fixed the server the first time... if they just ask to be removed, they get removed. They don't have to track me down because I sent them the report. Yet, the vast majority never ask.
Prevention is still the least costly route. Anyone running a mail server needs to prevent the problem from happening in the first place, or else pay the price.
It seems what we need now is a ratings system for blacklists. I personally do want to only use those blacklists which operate professionally. The only time I can see justifying a delay in removal from a list is after the offending server goes back to being an open relay for the 3rd time or more.
I also do not want to be blocking whole ISPs just because the ISP hosts a spamhaus (or even a spam promoted web site), as long as the spamhaus itself can be listed and stay that way. OTOH, if the ISP lets them keep changing IP addresses, then by the 3rd time I'd be willing to have the whole ISP listed until the ISP gets a clue. But even that needs to be a separate blacklist zone so those who don't want these blocked at all won't have to (again, a "truth" issue, as this is saying "this is an ISP that not only hosts spammers, but aids them in evading being blocked as well").
One of the things I want to know is why mail server admins let their servers be open relays in the first place. Is it because you became a mail server admin before you knew about open relaying? Or was it because you didn't really understand how your mailer software worked or was configured? Or was it because you inherited the machine from an idiot? Or was it because management didn't give you the time/resources to do the job right? Or was it because someone just didn't realize the impact of being blacklisted?
One problem I do see is lots of mail servers that are open relays from the very first day they go online. I can only suspect this is because the admin is a newbie and doesn't know about open relays or doesn't realize it can happen to him.
Another problem is that in a certain highly populous eastern Asian country, most servers are coming online with pirated copies of an older version of Microsoft Exchange, which not only is an open relay, but can't be made closed, either, even if the admin could read English. It seems in said country that piracy is the norm and virtually no one runs a legitimate copy.
Which blacklists are blocking whole ISPs when they could block just the offending server? If you genuinely know this is the case, then surely you know of examples of good blacklists and bad blacklists.
Colo/server hosting is one of the tougher areas to stop spamming. An ordinary dialup/DSL/broadband ISP can block port 25 and force the use of their mail servers, and rate control those servers and be effective. But colocated servers is harder to do because many of those machines have legitimate high mail volumes so the mechanics of controlling spam are much harder.
Part of the problem is that there are still new servers coming online all the time. And many of these servers are open relay right from the start. The reason I support being very harsh on sysadmins that did let a server do spam relaying is that I believe this problem won't get solved until it get so harsh that it becomes common public knowledge that you better do the job right from the very first day you get online, or you'll have trouble for a long time. Right now, new sysadmins are putting up open relays before they ever have any idea. That needs to change. Somehow they need to be educated about this before they ever have the root/Administrator password.
However, RBL, RSS, and DUL, are not free. And they don't even seem to be interested in money from the little guy as they have refused to respond to any of my mail (and no, I was not using any blacklist that might have blocked them).
Re:Why I won't be developing with .NET: $$$
on
What is .NET?
·
· Score: 2, Troll
To Microsoft, the only developers that count are the ones with $1,079 and more. That does mean big corporations and others with plenty of $$$. And Microsoft wants to favor those with $$$ so they can get more of that $$$ by creating a platform that requires more machines to run. More machines means more installed systems and more $$$ goes back to Microsoft. Microsoft can easily afford this because it is part of the strategy to cause more $$$ to be shifted to them. That is what business is about, like it or not (personally, I don't like it, but I deal with it).
And what will happen if the request you make (say to a Linux box with some clever scripting) has the request header like a CodeRed infected box might send out? There are a lot of things they could be doing with this. One might be to quench worms like CR. IMHO, that much would be a good thing.
Of course there are many bad things that could potentially be done with such a thing. If it disassociates the HTTP Host: header from the original destination IP address, and tries to lookup that hostname and connect there regardless of what the IP was, that could be bad. What if you are requesting a page from a web site in an alternate DNS realm like the Open Root Server Confederation... such as http://chrono.faq/ or http://watch.gallery/ or http://baby.mart/ or http://top-stories.news/?
I was approached by some execs who were setting up a startup a few years ago. They wanted me to design, build, and run the data center (a near perfect fit for me). Alas, when it got to the point of talking about stock options, I was asking questions the CFO couldn't... or wouldn't... answer. I guess it became apparent that I also knew enough financial stuff to not be fooled. I never heard from them again.
The H-1B program only requires that the visa holder be pay above the average wage for the kind of work they are doing. Check out the US Bureau of Labor Statistics data. The first problem is that all computer programmers are lumped together by USDLS into a single "computer programmers" category. This fails to take into account highly specialized areas that employers are claiming that Americans do not have and that they need to hire H-1B workers for. Assuming they found such skills in a foreign worker, they only need to pay that worker the average salary measured over all computer programmer jobs. This loophole is one of the big flaws of the H-1B program... you can hire someone who is trained in specialized area, and pay them as if they were not. Then on top of that, you can force them to work extra hours and on weekends because they can't go switch jobs to a decent employer, and always have the threat of being sent back home.
While the smaller businesses probably are paying decent to H-1B workers, and probably treating them more fairly, the big corporations do know how to work the system. This is where the wage problems are. While I don't believe the figure of 1/2 salary, I do believe 2/3 could very well be happening in many scenarios.
The smaller companies do genuinely hire for talent. The larger companies often hire for warm bodies... cheaply.
If the job is a management job that needs an MBA, the by all means fill it with the MBA guy. The HTML coder isn't a fit. If you have a job doing HTML markups, put the HTML coder there.
Most of the jobs H-1B workers take in the IT sector are more technical jobs like programmer or system administrator. When their H-1B terms are over, fill the job with a domestic worker (there always were some available, and there are a lot more now). When new positions are created, post the job online (most H-1B jobs never even got posted as they were just filled by pending contacts from overseas recruitment firms, anyway), take resumes, and choose the top few to come in for an interview, and hire the best. Is that too complicated?
Slashdot Mirror
I submit that I have a right to not accept e-mail from your open relay for no reason whatsoever (but generally I will do so because it is an open relay). If mail is relayed through your server, then I see that as sufficient proof for my purposes. I'm not asking the government to come take your personal freedom away, or take your driver's license away, or even take your network connection away (though many would want that taken away). IMHO, you have the right to be connected to the internet with an open relay if you want, but you have no right to expect that everyone must accept mail from your server, or even accept any IP packets from you, because of being an open relay.
Liken open relaying to doing bizarre behaviour, or having serious body odor because you don't shower. It's your right to do that. But it's also my right to have nothing to do with you and not even hire you. We just keep apart.
First of all, in reality, it won't happen. As soon as the first spammer discovers your open relay they will spam. And I got hold of one of these spam lists and found that the very first entries are of spamware authors and other spammers. So they are going to be among the first to be spammed by the spammer that found your open relay. Now several spammers have your IP address. It will be like a shark feeding frenzy. Eventually the spamming gets down to the addresses that have will alert the blacklist operators, and you get blacklisted.
I don't want the spam, and I'll accept the collateral damage of loss of legitimate mail from your server in exchange for protection from the spam. And that's my choice and I have the right to make that choice, and base it on information I believe to be factual (e.g. ordb and orbz). You have the freedom to choose which way you want to behave, and all that comes with it (or not).
So be it. That means people running open relays get pounced on. Serves 'em right.
I make the decision whether to accept or reject mail before the headers and body are ever received. I don't want to be handling the returns on the rejections because I've accepted delivery, and then have to deal with huge queues of rejections that can't be delivered. I let the sending server do that.
These operations also get listed in other ways, too. The identity of their network generaly gets discovered and places like spamhaus.org will list them.
It is not ridiculous at all. In fact this is exactly what they are supposed to do. If there is an open relay, and they say there is an open relay, they are telling the truth, and you have absolutely no cause to complain. Blacklists are not saying that such-and-such company has bad standards ... they saying that such-and-such IP address or network has an open relay (or whatever the case may be).
If your customer configured the server wrong, making it an open relay, then it is that customer you should be collecting recovery costs from. In the future, be sure terms that specify this is in your contact that you have each customer sign. Be sure the spam and open relay issues are discussed with them before the service is turned on.
And further, set up a testing facility which will probe all the IP addresses on your own network for open relays. Your own customers should not be relaying for any other of your customers, nor for your own machines, so you can do this entirely in-house. Leave the IP address of this testing machine out of the "local networks" list of your own mail servers and it can test them, too. Have it cycle through the network several times a day sending mail to an outside domain name which gets forwarded from there back to you. The contents of the message would be what the tester is testing, and with that and headers, you can see what server suddenly became an open relay before the spammers find it and cause you all this massive grief. And since it is your network, you have all the legal rights to probe it (but add this to your contact terms just to be on the safer side).
Now your next problem is those nasty form mail scripts that use a hidden field for where to send the mail. There is spamware available to use those to send spam. They simply fabricate the browser submission, with a false hidden address field containing the spam victim's address, and submit it to the web server. Such scripts should not be allowed on any web server in your network, with no exceptions made. Scanning around for them is harder due to the variety of potential pathnames they could be found it. The only form mail scripts that should be used are ones where the destination address is stored in the script itself, or in a database the script uses to lookup using the referer URL.
You didn't indicate if this is an on-campus or off-campus problem. Since most other schools have solved the problem, I'm assuming yours could, too, if you applied the correct solution.
First of all, mail coming in from off-campus is the issue with regard to open-relay. If you have students/staff spamming from on-campus, you do have better access to identifying who they are and dealing with it. But for off-campus, it's much harder, so it needs to be denied.
Many schools provide dialup services for staff and students off campus (some free, some for an added fee). This won't be a problem for the open relay issue as long as the dialup access itself is authenticated as usual.
Those off campus using a commercial ISP have a couple of choices. One is to just use the ISP's mail server for outbound, while picking up the mail at the school POP3 server for their dot.edu address. Most ISPs allow "From: anywhere" in the mail (means nothing, really). If a local ISP does not, you could ask them to allow the school's domain through (else you'd have to recommend to the school community not to use that ISP). And of course there is the POP-before-send approach which you can use to let the off-campus community send through the campus mail servers.
So basically, this is easier than you are making it out to be.
This is (by being dumb and setting up an open relay at first) how you get on 3000 (estimated) private blacklists. You get off mine by asking me to take you off (I do the first 2 times). Part of the problem is that many businesses just have their MCSE kid set it up.
It can't be a decent mailserver if the administrative staff who configure the network can't get it right. I'd worry that if they are too incompetent to get DNS right, they're probably too incompetent to get the mail server right. If it's not an open relay today, it might become one tomorrow.
Requiring reverse PTR names to provide a forward A record that matches the connecting IP is a bozo sysadmin filter. And it does a damn good job of filtering out huge numbers of direct marketers and eastern Asian pirated open relay MS Exchange servers.
I do have a list of a few IP addresses that I accept mail from regardless of any DNS problem or blacklist. If you really need to send me mail, have a static IP and an incompetent ISP, get on Hotmail and send me your story (why you can't change to competent ISP, and what your static IP address is), then I can open it up for you.
Doesn't matter. I don't want mail from generic dialup/DSL/broadband connections, anyway. If you're running a BSD or Linux box on such a connection, then either forward outbound mail through their central (presumably correctly DNS'd) mail servers, get a static IP with correct PTR+A entries, get a better ISP, or write to your MP.
An open relay is not necessary in order to make email function at the outlying offices. You don't even need a VPN. The mail server can be configured with the static IP addresses of each of the offices as valid "local" addresses. Of course a VPN is much better as that also improves your security.
As confirmed by another of your postings, your company management are morons who have apparently hired idiots for the IT department. Obviously you recognize it, and can leave if you feel that is necessary, or can stay as long as you can deal with it, and are not blamed for it. Should they ever offer to promote you into IT, be sure you insist that you be given the authority to fix the problems with no further permission from management to go ahead.
Maybe. If it is negative filtering, blocking the reply addresses that spammers actually use, which would hopefully not be what you use, then it may work. And it has less collateral damage, unless someone spams with the intent to hurt you by using your email address, or this happens out of coincidence.
Still, the best way to block spam, IMHO, is at the SMTP connection, before it is even delivered, despite some collateral damage. As long as eBay, Paypal, and other like places are not blocked (while I currently refuse to do any business with Paypal for several reasons, I do not block their email), you should be able to communicate with them using SMTP connection level anti-spam (e.g. DNS based blacklists, or local blacklists databases). Giving a 5XX rejection gives you notice (if your mail server does the right thing and sends it to you), so you do find out about the problem and know it's not someone ignoring you.
In general I don't like basing the filtering on any aspect of the message content because that means the message had to be delivered to see that (including the RFC822 headers). Since it was delivered, then if it is rejected, my servers have to send the rejection notice back. And, since so many are bogus, my outbound queue is huge, and my postmaster box gets flooded for the failures to deliver the rejection. Stopping the spam before it is even delivered (based on connecting IP address as looked up via DNS blacklists or a local DB, or that IP's domain name using reverse the forward verification, or even the MAIL FROM string) givs a 5XX rejection over SMTP and commits the sending server to return the rejection instead of mine.
That's not as big an "unfortunately" as you might think it is. The bigger "unfortunately" is that the Brightmail website does not give enough information up front to decide if this product/service is suitable enough to be worth contacting the company about.
- It doesn't explain how the Brightmail server interacts with other mail servers and customer domains.
- It doesn't explain how Brightmail works with variant email addresses.
- It doesn't give any information whatsoever about pricing.
- It doesn't explain how it deals with issues of customer privacy and confidentiality.
- It doesn't explain what security audits have been done on the server software itself.
It just leaves people in the dark (that's not very "bright"). So for now it's a direction I won't be going, even though I have no qualms about paying for good service. Maybe if you can get the marketing people to make a better website, more people might become interested. It's not like you have anything to hide, being protected by patent 6052709.Did you learn from that experience to test your mail server after making configuration changes? I don't know if ORDB, ORBZ, and others track servers that get added back to the list repeatedly. But at some point (about 3 or 4), I'd want to start extending the time after being tested as clean, like maybe an additional week for every time above 3 that the server has been listed in the past 180 days). Surely you would no longer allow your mail server get go back to being an open relay. But some people it seems just don't really care, especially if they know where to go get delisted quickly.
What good is it to depend on reports of spam stopping after the spamming server gets listed as a basis for delisting it?
I would agree an organized blacklist should be used in preference to private ones ... as soon as one that meets my needs can be found.
Those that are out there either block stuff I do not want blocked (and don't separate the zones to give me a choice), or are not very effective in doing quick blocking.
So I do block some on my own. But unless it is clearly a spamhaus (no point in ever trying to communicate with them), or a direct dialup/DSL pool (I block them by reverse-to-forward-verified domain name), I do send abuse@ the complaint with instructions to ask me to unblock. They don't even have to tell me they fixed the server the first time ... if they just ask to be removed, they get removed. They don't have to track me down because I sent them the report. Yet, the vast majority never ask.
Prevention is still the least costly route. Anyone running a mail server needs to prevent the problem from happening in the first place, or else pay the price.
And perhaps we need better blacklists.
It seems what we need now is a ratings system for blacklists. I personally do want to only use those blacklists which operate professionally. The only time I can see justifying a delay in removal from a list is after the offending server goes back to being an open relay for the 3rd time or more.
I also do not want to be blocking whole ISPs just because the ISP hosts a spamhaus (or even a spam promoted web site), as long as the spamhaus itself can be listed and stay that way. OTOH, if the ISP lets them keep changing IP addresses, then by the 3rd time I'd be willing to have the whole ISP listed until the ISP gets a clue. But even that needs to be a separate blacklist zone so those who don't want these blocked at all won't have to (again, a "truth" issue, as this is saying "this is an ISP that not only hosts spammers, but aids them in evading being blocked as well").
One of the things I want to know is why mail server admins let their servers be open relays in the first place. Is it because you became a mail server admin before you knew about open relaying? Or was it because you didn't really understand how your mailer software worked or was configured? Or was it because you inherited the machine from an idiot? Or was it because management didn't give you the time/resources to do the job right? Or was it because someone just didn't realize the impact of being blacklisted?
One problem I do see is lots of mail servers that are open relays from the very first day they go online. I can only suspect this is because the admin is a newbie and doesn't know about open relays or doesn't realize it can happen to him.
Another problem is that in a certain highly populous eastern Asian country, most servers are coming online with pirated copies of an older version of Microsoft Exchange, which not only is an open relay, but can't be made closed, either, even if the admin could read English. It seems in said country that piracy is the norm and virtually no one runs a legitimate copy.
Which blacklists are blocking whole ISPs when they could block just the offending server? If you genuinely know this is the case, then surely you know of examples of good blacklists and bad blacklists.
Colo/server hosting is one of the tougher areas to stop spamming. An ordinary dialup/DSL/broadband ISP can block port 25 and force the use of their mail servers, and rate control those servers and be effective. But colocated servers is harder to do because many of those machines have legitimate high mail volumes so the mechanics of controlling spam are much harder.
Part of the problem is that there are still new servers coming online all the time. And many of these servers are open relay right from the start. The reason I support being very harsh on sysadmins that did let a server do spam relaying is that I believe this problem won't get solved until it get so harsh that it becomes common public knowledge that you better do the job right from the very first day you get online, or you'll have trouble for a long time. Right now, new sysadmins are putting up open relays before they ever have any idea. That needs to change. Somehow they need to be educated about this before they ever have the root/Administrator password.
However, RBL, RSS, and DUL, are not free. And they don't even seem to be interested in money from the little guy as they have refused to respond to any of my mail (and no, I was not using any blacklist that might have blocked them).
To Microsoft, the only developers that count are the ones with $1,079 and more. That does mean big corporations and others with plenty of $$$. And Microsoft wants to favor those with $$$ so they can get more of that $$$ by creating a platform that requires more machines to run. More machines means more installed systems and more $$$ goes back to Microsoft. Microsoft can easily afford this because it is part of the strategy to cause more $$$ to be shifted to them. That is what business is about, like it or not (personally, I don't like it, but I deal with it).
And what will happen if the request you make (say to a Linux box with some clever scripting) has the request header like a CodeRed infected box might send out? There are a lot of things they could be doing with this. One might be to quench worms like CR. IMHO, that much would be a good thing.
Of course there are many bad things that could potentially be done with such a thing. If it disassociates the HTTP Host: header from the original destination IP address, and tries to lookup that hostname and connect there regardless of what the IP was, that could be bad. What if you are requesting a page from a web site in an alternate DNS realm like the Open Root Server Confederation ... such as http://chrono.faq/ or http://watch.gallery/ or http://baby.mart/ or http://top-stories.news/?
I was approached by some execs who were setting up a startup a few years ago. They wanted me to design, build, and run the data center (a near perfect fit for me). Alas, when it got to the point of talking about stock options, I was asking questions the CFO couldn't ... or wouldn't ... answer. I guess it became apparent that I also knew enough financial stuff to not be fooled. I never heard from them again.
The H-1B program only requires that the visa holder be pay above the average wage for the kind of work they are doing. Check out the US Bureau of Labor Statistics data. The first problem is that all computer programmers are lumped together by USDLS into a single "computer programmers" category. This fails to take into account highly specialized areas that employers are claiming that Americans do not have and that they need to hire H-1B workers for. Assuming they found such skills in a foreign worker, they only need to pay that worker the average salary measured over all computer programmer jobs. This loophole is one of the big flaws of the H-1B program ... you can hire someone who is trained in specialized area, and pay them as if they were not. Then on top of that, you can force them to work extra hours and on weekends because they can't go switch jobs to a decent employer, and always have the threat of being sent back home.
While the smaller businesses probably are paying decent to H-1B workers, and probably treating them more fairly, the big corporations do know how to work the system. This is where the wage problems are. While I don't believe the figure of 1/2 salary, I do believe 2/3 could very well be happening in many scenarios.
The smaller companies do genuinely hire for talent. The larger companies often hire for warm bodies ... cheaply.
If the job is a management job that needs an MBA, the by all means fill it with the MBA guy. The HTML coder isn't a fit. If you have a job doing HTML markups, put the HTML coder there.
Most of the jobs H-1B workers take in the IT sector are more technical jobs like programmer or system administrator. When their H-1B terms are over, fill the job with a domestic worker (there always were some available, and there are a lot more now). When new positions are created, post the job online (most H-1B jobs never even got posted as they were just filled by pending contacts from overseas recruitment firms, anyway), take resumes, and choose the top few to come in for an interview, and hire the best. Is that too complicated?