Motors initially draw an excess of current as they start up (they would also do this if the mechanical load were suddenly increased). If the voltage drops so low as to not allow the motor actually get going, it would be "stuck" in the high current situation for quite some time. This is why you see the lights dim briefly in many places when motors like A/C compressors start up.
In 2-phase circuits, the transformer is center tapped on the secondary, and the primary is on just one phase of the three phase source. You get 120v between either leg and the center (ground/neutral), and 240v between the opposing legs. A phase difference would certainly lower the voltage, but that's not going to happen on a 2-phase circuit unless you have other reactive loads there.
But, it may have actually been a 208v circuit between 2 legs of a 3-phase circuit. Most modern A/C systems are rated to operate even on 208 volts, so this kind of thing is not uncommon. It's cheaper to supply 208v instead of 240v to comemrcial buildings which already have a need for 3-phase motors (larger motors and A/C systems) than it is to supply genuine 240v (because this would require making the 3 transformers center tapped, and running 7 wires (6 point star and neutral) rather than 4 (3 point star and neutral). If a leg changed phase relative to the others, it could certainly upset the voltage balance, and the A/C could get undervoltage or overvoltage.
A frequency change can also cause problems, especially with 3-phase motors. A sudden phase shift (a brief frequency change) can cause a motor to go out of sync and draw more current to get back in sync.
It might not have even been necessary for the SCADA systems to be directly affected. If other computers had been affected in some way, and if there were shared networks involved (the current trend, so as to reduce costs), the overload in networks due to Blaster effects, could have delayed measurements or responses by other systems. A few lost packets can do things like cause TCP to delay recovery equally as long as the period of the problem (because it doubles the time interval between each retry).
So even if the control systems were running highly secure and reliable systems, simply deploying it over a load vulnerable network can make the whole system itself vulnerable to a denial of service attack (as Blaster effectively was). These are cases where total isolation and mandatory quality of service are required.
Ok, then let's implement an open source version of OpenOffice that is 100% DRM compliant, and will refuse to allow the user to open documents they are not allowed to. Now that would be legal, right? And then it would be illegal to hack the source code to make a DRM-circumvention device, right?
In order to ensure that older versions of Office or Word cannot read a DRM restricted document, they have to make it "incompatible" in some way. If they do that by having a few fields that will choke older programs, it still won't do anything to prevent developers of other office productivity software from making it readable in theirs. So Microsoft will almost certainly have to encrypt the document, and serve up the key from the DRM server (using a proprietary protocol, of course). That encryption is involved makes it the kind of rights-restricting scheme the DMCA makes illegal to re-engineer. And don't think Microsoft doesn't know this; they are not dumb. They will try to do at least as much as they can get away with (and perhaps more, which we can then pounce on). Be sure you use the word "interoperability" more, now.
My big fear is that this new protocol and server will be full of the kinds of bugs that Microsoft traditionally puts in new software expecting the public to help them debug it. Imagine the impact when people assume this DRM will protect their confidential documents (such as health records, bank records, and such), and stop using other methods. In a few years we'll see lots of these documents not only cracked, but cracked via the internet en masse. Oh the horror.
Spammers do more than just flood email and usenet with garbage. They are also doing it via blog and other feedback methods, especially those on spiderable web pages since that can raise search engine ratings for the spammers.
"People are assuming that every e-mail publisher is a spammer."
That's not necessarily the issue. Instead, I think, lots of people just don't want to have to deal with separating the newsletter they want from the spam they don't want. And lots of others might be afraid their email address will leak (be sold) to a spammer. Unique mailbox addresses to sign up with might help, but most people don't have these nor know how to create them.
In some cases, signups to legitimate newsletters or mailing lists are failing because they are hosted by providers that have had, or maybe still have, spammers operating, and some ISPs are blocking them. Other disadvantages of email include the hassle of having to do a confirmation cycle (switch to the mail program) to sign up.
RSS seems like an interesting solution, but it's basically a one way feed although you can hyperlink to a web submission form if the newsletter provides two-way communication. Many have suggested NNTP (running isolated from the global USENET) for the more discussion oriented mailing lists. And another option is for the mailing list operator to host the mailboxes (stored shared) with access via IMAP. Perhaps integrating all of these into a web browser will make it all work better. Oh wait...
"That's what my 2nd item is, when everyone has that goal."
I don't think everyone is needed. Significant effects have been seen from single systems. If I were going for everyone I'd say "Just Hit Delete." If you get EVERYONE involved then it's trivial.
True, not everyone is needed. What I was referring to is what the definition of my goal is. That 2nd goal is to prevent even so much as a DNS lookup to find my servers, and certainly not a SYN packet to try to make a connection (which can be stopped at this point with a border router access list, but still, that uses up some bandwidth and router cycles, which I should not have to pay for, but wouldn't have worried about had it stayed at a miniscule level). By extending my goal to "everyone", it eliminates all spam.
"What the hell are you talking about? ALL spam is abuse."
Excellent point. Since you understand I'll rephrase it as targeting spam that can be targeted using a honeypot. If you're seeing the spammer connection attempts but stopping them how do you know they aren't looking for an open relay? In any case you get bonus points for seeing it - if more people watched then more reports could go to ISPs about the abuse. Even those ISPs who smugly harbor the spammers might change attitude if they saw even a small stream of ABUSE reports - not SPAM reports. I know I've gotten a spammer knocked off UUNET when all others were saying UUNET harbored them. I didn't have to "raise my voice" or issue threats: I just sent them the SMTP logs that showed the abuse, along with a sample spam. For that matter Michael Tokarev got Ralsky knocked off UUNET again and again, all in the same weekend. The spam stopped when Ralsky ran out of his then-current stock of throwaway accounts in his Dallas operation. More recently Ron Guilmette has gotten what appears to be Ralsky's own servers in his $3/4 million house near Detroit knocked off. This is easy stuff.
They may well be looking for an open relay. I've seen those. I can tell because the recipient address is not one which would have led any normal MX-record-following SMTP client to my server. I have seen an "attack" by several hundred (worst case was a little over 23 thousand) such hits from the same IP, doing the relay thing. But that has only been on the server of one of my clients, who once many years ago did have an open relay there (and perhaps someone is running an antique list). My own have never seen any significant open relay attemps, so I suspect what I do see are test probes, either by spammers looking for lush new territory (didn't find it here), or by an operator of some open-relay blocking DNSBL. But the vast majority of hits on my servers are some combination of big colocated spammers (such as yourbigvote.com), and thousands of small time hustlers on cable modems and such. I've blocked both at the mail servers, so I see logs of attempts to deliver that fail. And they keep coming and keep getting 550 responses, and never clean their lists on the basis of that. The small time ones I can understand as they are running from some CDROM, typically. But the big ones could do this... they just don't.
"Even the small time spammers, who seem to be the ones you focus on..."
With a honeypot you catch who you catch. See above: Ralsky is NOT a small-time spammer. I believe most spammers now use abuse (open relay abuse, open proxy abuse, Jeem-type abuse) to send spam. Direct spam is fairly easy to stop using blocklists. It's also fairly easy to trace. I don't think most spammers use it. Scelson has claimed he does but then Scelson has filed for bankruptcy.
You're still using "abuse" in a restricted venue. Relaying spam through someone else's server is TWO cases of abuse... 1: the abuse of the open relay (IMHO, they got what t
I go for the BIG GOAL: end spam. Why settle for less?
That's what my 2nd item is, when everyone has that goal.
If you limit the goal you limit the range of solutions that can be tried.
I do have the goal to eliminate spam. But to do it, everyone has to also have the goal and co-operate.
Waht I actually aim at is spam sent by abuse, not all spam (so spam sent directly by the spammer to the recipients isn't included. That's a small portion of the spam.)
What the hell are you talking about? ALL spam is abuse. That includes spam sent directly by the spammer (assuming you mean not bouncing it via open relays or open proxies). My mail server logs are full of connection attempts, and subsequent refusals, by spammers connecting from their own high speed access lines or colocated servers. That's abuse, too, because it uses up some bandwidth and server resources to fork the SMTPD process, receive the MAIL and RCPT commands, look up the reverse DNS of the connecting host, and send back a 55X error response if they are not whitelisted and either have no reverse DNS, or it fails a forward verification, or their domain name is blacklisted, or another DNS blacklist lookup shows them to be a spammer. At least I keep my costs to a minimum by not accepting the DATA and not running some content analysis on the message body and not trying to save what looks like spam in a separate folder.
There's two closely-related tools to do this: open relay honeypots and open proxy honeypots. Both accept spam directed elsewhere, both keep that spam from being delivered. If the initial source of the spam can be identified (as it frequently can be for open proxy spam) then the ISP can be notified of the abuse by the customer. Many ISPs will boot the spammer on the basis of that evidence. If the spammer gets a new account but spams in the same way he'll get caught again, get booted again.
A great many ISPs refuse to terminate their big spammers. And I'm talking about spammers that colocate or rent dozens to hundreds of servers. These are big revenues sources to the ISPs, so they often look the other way.
Even the small time spammers, who seem to be the ones you focus on, can get lots of spam out over and over through the use of multiple accounts. By the time the ISP does discover there is spam going out, and terminate the account, it's been 24 to 48 hours, and the spammer has usually quit using that account (it's generally considered you can get 12 to 24 hours of spam run out of one dialup/ISDN account, when spamming direct, and a bit longer when going through safe open proxies).
If ISPs really wanted to stop these kinds of accounts from spamming, they would block outgoing connections to port 25 or any proxy ports (except port 25 would still be allowed to the ISP's smart host mail server... which needs to have quotas limiting the volume of mail from any one customer to say about 30 per hour).
These are real good, but what I've described is single-IP honeypots. If ISPs would watch for abuse traffic coming in (particularly proxy port traffic) they could run ISP-wide honeypots. The ISPs could strike a significant blow against the spammers and fairly quickly cause the spammers to leave their IP space alone. If spammers feared they'd get caught and punished when they sent spam they'd lose a lot of their motivation. Being booted is a weak punishment but even that could, if repeated, get the spammer thinking about no longer sending UCE.
What about having ISPs also watch for abuse traffic going out from their own customer base?
Running honeypots isn't even necessary for this. They can block incoming ports for open proxies either at the border routers, or in the customer RADIUS profiles, and blocking incoming port 25 in the RADIUS profiles (except for those authorized to run a mail server). Same for any ports eventually discovered to have been deployed by viruses.
Oh yeah? I did the signups for family and friends, and created a new email address for each one, given only for that purpose and no other. I can dispose of those email addresses. But I'll leave them there for now and see how long it takes before they are abused.
I think they would notice, and end up purging everything that came from whoever did that. But if it were done from a variety of addresses (open proxies) using a variety of free-mail mailboxes, it might be possible to slip it past them, at least maybe for every phone number in a small town.
Telemarketing groups have sued to scratch the effort, arguing that it abridges free-speech rights and could wreak havoc on an industry that employs 2 million.
We know the industry uses automated dialers to make sure the the time spent by each person is not wasted dialing numbers that don't answer. Instead, the telemarketing staff are constantly online with the next number that answers. So if there are 2 million people working in that industry, and some significant portion of those at their station at any given time, imagine how much havoc that wreaks on the rest of the population. For every minute some telemarketer is working the phones, that's a minute someone else is not doing something productive. The higher the industry quotes these figures, the more it seems this law will actually help the rest of us.
And just where did you get that IP address from? If you got it from ARIN, RIPE, APNIC, LACNIC, etc, then you are the ISP or other network operator. But if you got it from an ISP, then it's your mistake if you got it from an ISP that harbors spammers.
If you think SPEWS might block a whole/16 just because some ISP with only a/19 is harboring spammers in there, then that's where your ignorance of the process is showing. SPEWS will not expand a listing beyond the business relationships that exist.
You further show your ignorance of the issues by insisting that everyone use tools that test content. Such tools are a valid choice for those that want that approach, but they do not have any effect, and even make things worse, when the goal is to reduce the costs associated with incoming spam.
If you think the only goal is to keep spam out of the mailbox at any cost, then you are again showing just how ignorant you really are. If you were the one who had to install hundreds of additional mail servers like they do at AOL just to keep up with the load of SMTP connections which attempt to deliver mail that is doomed to be rejected (more than 60% of what AOL gets will be rejected one way or another, and at great cost if it involves content analysis), then you'd realize that cost is a critical factor.
And SPEWS has been very effective in turning around quite a number of ISPs. Sadly, many others have decided to ignore SPEWS and focus their business on hosting spammers. Before SPEWS, thousands of networks were doing private blacklisting, and that's where most of the damage was done. The DNSBL approach provided a means to quickly update a central database to show addresses which have been removed and should no longer be blocked.
SPEWS is very selective. You're just pissed off because your ISP happens to be one which was selected. Next time, switch ISP and you can help encourage ISPs to stop hosting spammers (assuming you are not a spammer in disguise).
If you are not doing it in bulk, then it does not fit the definition of spam. The definition I use is UBE... Unsolicited Bulk Email. It has to be both unsolicited and bulk to be considered spam. That means if you gathered a list of all the email addresses of everyone at your high school, and sent mail to each one using bulk methods, you would be a spammer. But if you were to manually type each address into your mail program, and manually type in each message personally, then I would not call that spam. There are some in betweens and it might be a fuzzy boundary between what is or is not spam. But sending ONE message to ONE person is NOT spam under the UBE definition since it didn't meet the 'B' requirement.
Maybe this is NOT even a DDoS attack at all. The SoBig.F virus includes its own SMTP engine, and so, is bypassing the smart host mail server at each of the various ISPs the infected machines are served by. It is now making SMTP connections to various MX hosts all over the network directly from that access IP address which probably never was used that way in the past by most people. DNSBLs are, or were, scalable because the queries done by the receiving MX servers to verify each sending IP address would be cached by the DNS server there for usually at least a day or two. That caching is effective when the number of connecting SMTP clients (the sending role) is small. What SoBig.F did was greatly increase the number of different IP addresses being SMTP clients. This could be immensely greater, many times the number originally seen. That would mean the resolving DNS server at the MX server site would be missing its cache much more often, both due to the more diverse queries being done, as well as the increased volume of mail. My theory is that this alone, if the increase factor is high enough, could overwhelm the authoritative DNS servers for the DNSBL zones and appear like a DDoS attack.
DNSBLs might have also be configured in more servers as a result of the SoBig.F virus going around, too, to help block it.
How to verify this would be to examine the range of source addresses hitting the authoritative servers. If the range is about the same as before, or generally represents the resolving DNS servers those MX servers are using, then I could be right. Still, it is possible for a real DDoS attack to fake exactly that so as to look like this theory holds.
If the attack has source addresses that are not functioning as resolving DNS servers, then the theory would be wrong. But resolving servers, when run separate from authoritative servers, are usually blocked from outside usage. So simple testing would be inadequate to show that they are not real DNS servers.
That is what the blacklists are for, to force the spam blocking on the client side of the SMTP transaction. Or better yet, to even prevent that SMTP transaction at all by having the ISP disconnect the spammer.
Oh wait, you were talking about POP3/IMAP clients. Oh yeah, that just doesn't work well due to the bandwidth problem you do mention. So how about this: let's shoot all those who send spam to those who don't want it. That way those who do want penis-enlarging offers can get them (then it's not really spam).
The decision being made for DNSBLs isn't about who is sending what content. It is about who is sending whatever content to people who didn't request it, and doing so only a bulk basis. Spam isn't about content at all; it is about consent. If I ask for penis-enlarging offers, it's not spam to me. If the sender verifies that I really do own the email address before sending it, they can be protected against someone abusing them tricking them into sending to someone who did not ask for it. What DNSBLs blocked are those operations that didn't do the proper sending verifications. It's nothing about content.
Anyone who wants to get internet access better get a clause in their contract guaranteeing that the IPs they get weren't abused by someone in the past, or else they might be getting a useless connection.
Maybe this will be the thing that speeds up the transition to IPv6. There has been too little motive (even from those who claim to be pushing IPv6) to do it. The idea of huge expanses of never-abused address space could be enticing. And further, once an ISP gets some space in IPv6, it will be next to impossible to get more, because what they get will be so huge already (enough to run every computer in the world a million times over). So said ISP had better not do anything stupid like let it get blacklisted (which will be even easier to blacklist because it will be a single contiguous block).
If you pay money to an ISP that harbors spammers, then you are part of the problem. The motive in blocking all of an ISP's address space (and SPEWS started small and gradually increased it so the ISP would get the message before a lot of customers were impacted) is to make that ISP realize they have to choose between hosting spammers (whom they could terminate) or hosting legitimate customers (who might be leaving due to the poor reachability).
Your thinking that the only reason you could be blacklisted is for actually sending spam is your big mistake. If you support spammers, even indirectly, you are part of the problem and in that case expect to get listed eventually (the less direct your support is, the later you are likely to be listed). Customers of ISPs that persist in harboring spammers are not innocent.
I have seen very very few networks listed unfairly by blacklists, including SPEWS. Care to go into any specifics?
What makes you think spam will die out if lots of people use intelligent filtering? Instead, spammers are constantly working on ways to evade those filters, and they do so effectively in some cases. They can, and some now do, make their "ads" look like conversations between people, who just happen to talk about the products really being advertised. Unless they used certain words like maybe "viagra", it can pass the filter. If your filter cuts out every message with "viagra", then even your own friends can't talk about it unless you whitelist them. And even then the spammers can find out who your friends are, if your computer got infected or you participate with them on a mailing list.
And none of this solves the other half of the spam problem, which is that networks and mail servers are being overloaded by the spam. For many businesses, mail uses more bandwidth than web access, and spam makes a substantial portion of that. They end up having to upgrade their mail server and/or their connection bandwidth sooner than they should have... sooner than they would have had there been no spam at all.
The goal I and many other people have is to make it so that repeat/habitual spammers (I'm not talking about people who made the mistake of spamming once and got slapped for it) have no net access at all, and cannot even send a SYN packet, much less make an SMTP connection. Only then are they not stealing my resources.
I've found Bayesian to be totally ineffective in getting spammers to stop trying to send spam to my mail servers. DNS plus private blacklists are so far the most effective. No, they are not perfect as some legitimate mail occaisionally gets rejected. But I'm at around 99.95% spam blocked now, and see maybe 1 legitimate message lost per month or two. I can live with that. I can understand that some other people cannot live with that.
I do agree that ISPs that choose to use some particular method (i.e. don't let the customers choose) should at the very least tell the customers what method they use, so the customers can make the informed choice to stay or switch to another ISP or sue someone.
Slashdot Mirror
Motors initially draw an excess of current as they start up (they would also do this if the mechanical load were suddenly increased). If the voltage drops so low as to not allow the motor actually get going, it would be "stuck" in the high current situation for quite some time. This is why you see the lights dim briefly in many places when motors like A/C compressors start up.
In 2-phase circuits, the transformer is center tapped on the secondary, and the primary is on just one phase of the three phase source. You get 120v between either leg and the center (ground/neutral), and 240v between the opposing legs. A phase difference would certainly lower the voltage, but that's not going to happen on a 2-phase circuit unless you have other reactive loads there.
But, it may have actually been a 208v circuit between 2 legs of a 3-phase circuit. Most modern A/C systems are rated to operate even on 208 volts, so this kind of thing is not uncommon. It's cheaper to supply 208v instead of 240v to comemrcial buildings which already have a need for 3-phase motors (larger motors and A/C systems) than it is to supply genuine 240v (because this would require making the 3 transformers center tapped, and running 7 wires (6 point star and neutral) rather than 4 (3 point star and neutral). If a leg changed phase relative to the others, it could certainly upset the voltage balance, and the A/C could get undervoltage or overvoltage.
A frequency change can also cause problems, especially with 3-phase motors. A sudden phase shift (a brief frequency change) can cause a motor to go out of sync and draw more current to get back in sync.
It might not have even been necessary for the SCADA systems to be directly affected. If other computers had been affected in some way, and if there were shared networks involved (the current trend, so as to reduce costs), the overload in networks due to Blaster effects, could have delayed measurements or responses by other systems. A few lost packets can do things like cause TCP to delay recovery equally as long as the period of the problem (because it doubles the time interval between each retry).
So even if the control systems were running highly secure and reliable systems, simply deploying it over a load vulnerable network can make the whole system itself vulnerable to a denial of service attack (as Blaster effectively was). These are cases where total isolation and mandatory quality of service are required.
But can it open password-protected documents when you supply the correct password?
Ok, then let's implement an open source version of OpenOffice that is 100% DRM compliant, and will refuse to allow the user to open documents they are not allowed to. Now that would be legal, right? And then it would be illegal to hack the source code to make a DRM-circumvention device, right?
In order to ensure that older versions of Office or Word cannot read a DRM restricted document, they have to make it "incompatible" in some way. If they do that by having a few fields that will choke older programs, it still won't do anything to prevent developers of other office productivity software from making it readable in theirs. So Microsoft will almost certainly have to encrypt the document, and serve up the key from the DRM server (using a proprietary protocol, of course). That encryption is involved makes it the kind of rights-restricting scheme the DMCA makes illegal to re-engineer. And don't think Microsoft doesn't know this; they are not dumb. They will try to do at least as much as they can get away with (and perhaps more, which we can then pounce on). Be sure you use the word "interoperability" more, now.
My big fear is that this new protocol and server will be full of the kinds of bugs that Microsoft traditionally puts in new software expecting the public to help them debug it. Imagine the impact when people assume this DRM will protect their confidential documents (such as health records, bank records, and such), and stop using other methods. In a few years we'll see lots of these documents not only cracked, but cracked via the internet en masse. Oh the horror.
Spammers do more than just flood email and usenet with garbage. They are also doing it via blog and other feedback methods, especially those on spiderable web pages since that can raise search engine ratings for the spammers.
From the article:
That's not necessarily the issue. Instead, I think, lots of people just don't want to have to deal with separating the newsletter they want from the spam they don't want. And lots of others might be afraid their email address will leak (be sold) to a spammer. Unique mailbox addresses to sign up with might help, but most people don't have these nor know how to create them.
In some cases, signups to legitimate newsletters or mailing lists are failing because they are hosted by providers that have had, or maybe still have, spammers operating, and some ISPs are blocking them. Other disadvantages of email include the hassle of having to do a confirmation cycle (switch to the mail program) to sign up.
RSS seems like an interesting solution, but it's basically a one way feed although you can hyperlink to a web submission form if the newsletter provides two-way communication. Many have suggested NNTP (running isolated from the global USENET) for the more discussion oriented mailing lists. And another option is for the mailing list operator to host the mailboxes (stored shared) with access via IMAP. Perhaps integrating all of these into a web browser will make it all work better. Oh wait...
True, not everyone is needed. What I was referring to is what the definition of my goal is. That 2nd goal is to prevent even so much as a DNS lookup to find my servers, and certainly not a SYN packet to try to make a connection (which can be stopped at this point with a border router access list, but still, that uses up some bandwidth and router cycles, which I should not have to pay for, but wouldn't have worried about had it stayed at a miniscule level). By extending my goal to "everyone", it eliminates all spam.
They may well be looking for an open relay. I've seen those. I can tell because the recipient address is not one which would have led any normal MX-record-following SMTP client to my server. I have seen an "attack" by several hundred (worst case was a little over 23 thousand) such hits from the same IP, doing the relay thing. But that has only been on the server of one of my clients, who once many years ago did have an open relay there (and perhaps someone is running an antique list). My own have never seen any significant open relay attemps, so I suspect what I do see are test probes, either by spammers looking for lush new territory (didn't find it here), or by an operator of some open-relay blocking DNSBL. But the vast majority of hits on my servers are some combination of big colocated spammers (such as yourbigvote.com), and thousands of small time hustlers on cable modems and such. I've blocked both at the mail servers, so I see logs of attempts to deliver that fail. And they keep coming and keep getting 550 responses, and never clean their lists on the basis of that. The small time ones I can understand as they are running from some CDROM, typically. But the big ones could do this ... they just don't.
You're still using "abuse" in a restricted venue. Relaying spam through someone else's server is TWO cases of abuse ... 1: the abuse of the open relay (IMHO, they got what t
That's what my 2nd item is, when everyone has that goal.
I do have the goal to eliminate spam. But to do it, everyone has to also have the goal and co-operate.
What the hell are you talking about? ALL spam is abuse. That includes spam sent directly by the spammer (assuming you mean not bouncing it via open relays or open proxies). My mail server logs are full of connection attempts, and subsequent refusals, by spammers connecting from their own high speed access lines or colocated servers. That's abuse, too, because it uses up some bandwidth and server resources to fork the SMTPD process, receive the MAIL and RCPT commands, look up the reverse DNS of the connecting host, and send back a 55X error response if they are not whitelisted and either have no reverse DNS, or it fails a forward verification, or their domain name is blacklisted, or another DNS blacklist lookup shows them to be a spammer. At least I keep my costs to a minimum by not accepting the DATA and not running some content analysis on the message body and not trying to save what looks like spam in a separate folder.
A great many ISPs refuse to terminate their big spammers. And I'm talking about spammers that colocate or rent dozens to hundreds of servers. These are big revenues sources to the ISPs, so they often look the other way.
Even the small time spammers, who seem to be the ones you focus on, can get lots of spam out over and over through the use of multiple accounts. By the time the ISP does discover there is spam going out, and terminate the account, it's been 24 to 48 hours, and the spammer has usually quit using that account (it's generally considered you can get 12 to 24 hours of spam run out of one dialup/ISDN account, when spamming direct, and a bit longer when going through safe open proxies).
If ISPs really wanted to stop these kinds of accounts from spamming, they would block outgoing connections to port 25 or any proxy ports (except port 25 would still be allowed to the ISP's smart host mail server ... which needs to have quotas limiting the volume of mail from any one customer to say about 30 per hour).
What about having ISPs also watch for abuse traffic going out from their own customer base?
Running honeypots isn't even necessary for this. They can block incoming ports for open proxies either at the border routers, or in the customer RADIUS profiles, and blocking incoming port 25 in the RADIUS profiles (except for those authorized to run a mail server). Same for any ports eventually discovered to have been deployed by viruses.
Oh yeah? I did the signups for family and friends, and created a new email address for each one, given only for that purpose and no other. I can dispose of those email addresses. But I'll leave them there for now and see how long it takes before they are abused.
I think they would notice, and end up purging everything that came from whoever did that. But if it were done from a variety of addresses (open proxies) using a variety of free-mail mailboxes, it might be possible to slip it past them, at least maybe for every phone number in a small town.
I used disposable addresses for myself, family, and friends. I'll keep them active for now (all forward to me) and see if they do get abused.
From the article:
We know the industry uses automated dialers to make sure the the time spent by each person is not wasted dialing numbers that don't answer. Instead, the telemarketing staff are constantly online with the next number that answers. So if there are 2 million people working in that industry, and some significant portion of those at their station at any given time, imagine how much havoc that wreaks on the rest of the population. For every minute some telemarketer is working the phones, that's a minute someone else is not doing something productive. The higher the industry quotes these figures, the more it seems this law will actually help the rest of us.
And just where did you get that IP address from? If you got it from ARIN, RIPE, APNIC, LACNIC, etc, then you are the ISP or other network operator. But if you got it from an ISP, then it's your mistake if you got it from an ISP that harbors spammers.
If you think SPEWS might block a whole /16 just because some ISP with only a /19 is harboring spammers in there, then that's where your ignorance of the process is showing. SPEWS will not expand a listing beyond the business relationships that exist.
You further show your ignorance of the issues by insisting that everyone use tools that test content. Such tools are a valid choice for those that want that approach, but they do not have any effect, and even make things worse, when the goal is to reduce the costs associated with incoming spam.
If you think the only goal is to keep spam out of the mailbox at any cost, then you are again showing just how ignorant you really are. If you were the one who had to install hundreds of additional mail servers like they do at AOL just to keep up with the load of SMTP connections which attempt to deliver mail that is doomed to be rejected (more than 60% of what AOL gets will be rejected one way or another, and at great cost if it involves content analysis), then you'd realize that cost is a critical factor.
And SPEWS has been very effective in turning around quite a number of ISPs. Sadly, many others have decided to ignore SPEWS and focus their business on hosting spammers. Before SPEWS, thousands of networks were doing private blacklisting, and that's where most of the damage was done. The DNSBL approach provided a means to quickly update a central database to show addresses which have been removed and should no longer be blocked.
SPEWS is very selective. You're just pissed off because your ISP happens to be one which was selected. Next time, switch ISP and you can help encourage ISPs to stop hosting spammers (assuming you are not a spammer in disguise).
Listing Cogent was very fair. Cogent is responsible for harboring a number of spammers. What was SA doing to get spammers out of Cogent?
If you are not doing it in bulk, then it does not fit the definition of spam. The definition I use is UBE ... Unsolicited Bulk Email. It has to be both unsolicited and bulk to be considered spam. That means if you gathered a list of all the email addresses of everyone at your high school, and sent mail to each one using bulk methods, you would be a spammer. But if you were to manually type each address into your mail program, and manually type in each message personally, then I would not call that spam. There are some in betweens and it might be a fuzzy boundary between what is or is not spam. But sending ONE message to ONE person is NOT spam under the UBE definition since it didn't meet the 'B' requirement.
The network the nerds built was an excellent one. It's the MBA morons and spammers that came along and ruined it.
"Disconnect the network Scotty, there's no intelligent life here."
Maybe this is NOT even a DDoS attack at all. The SoBig.F virus includes its own SMTP engine, and so, is bypassing the smart host mail server at each of the various ISPs the infected machines are served by. It is now making SMTP connections to various MX hosts all over the network directly from that access IP address which probably never was used that way in the past by most people. DNSBLs are, or were, scalable because the queries done by the receiving MX servers to verify each sending IP address would be cached by the DNS server there for usually at least a day or two. That caching is effective when the number of connecting SMTP clients (the sending role) is small. What SoBig.F did was greatly increase the number of different IP addresses being SMTP clients. This could be immensely greater, many times the number originally seen. That would mean the resolving DNS server at the MX server site would be missing its cache much more often, both due to the more diverse queries being done, as well as the increased volume of mail. My theory is that this alone, if the increase factor is high enough, could overwhelm the authoritative DNS servers for the DNSBL zones and appear like a DDoS attack.
DNSBLs might have also be configured in more servers as a result of the SoBig.F virus going around, too, to help block it.
How to verify this would be to examine the range of source addresses hitting the authoritative servers. If the range is about the same as before, or generally represents the resolving DNS servers those MX servers are using, then I could be right. Still, it is possible for a real DDoS attack to fake exactly that so as to look like this theory holds.
If the attack has source addresses that are not functioning as resolving DNS servers, then the theory would be wrong. But resolving servers, when run separate from authoritative servers, are usually blocked from outside usage. So simple testing would be inadequate to show that they are not real DNS servers.
That is what the blacklists are for, to force the spam blocking on the client side of the SMTP transaction. Or better yet, to even prevent that SMTP transaction at all by having the ISP disconnect the spammer.
Oh wait, you were talking about POP3/IMAP clients. Oh yeah, that just doesn't work well due to the bandwidth problem you do mention. So how about this: let's shoot all those who send spam to those who don't want it. That way those who do want penis-enlarging offers can get them (then it's not really spam).
The decision being made for DNSBLs isn't about who is sending what content. It is about who is sending whatever content to people who didn't request it, and doing so only a bulk basis. Spam isn't about content at all; it is about consent. If I ask for penis-enlarging offers, it's not spam to me. If the sender verifies that I really do own the email address before sending it, they can be protected against someone abusing them tricking them into sending to someone who did not ask for it. What DNSBLs blocked are those operations that didn't do the proper sending verifications. It's nothing about content.
Maybe this will be the thing that speeds up the transition to IPv6. There has been too little motive (even from those who claim to be pushing IPv6) to do it. The idea of huge expanses of never-abused address space could be enticing. And further, once an ISP gets some space in IPv6, it will be next to impossible to get more, because what they get will be so huge already (enough to run every computer in the world a million times over). So said ISP had better not do anything stupid like let it get blacklisted (which will be even easier to blacklist because it will be a single contiguous block).
If you pay money to an ISP that harbors spammers, then you are part of the problem. The motive in blocking all of an ISP's address space (and SPEWS started small and gradually increased it so the ISP would get the message before a lot of customers were impacted) is to make that ISP realize they have to choose between hosting spammers (whom they could terminate) or hosting legitimate customers (who might be leaving due to the poor reachability).
Your thinking that the only reason you could be blacklisted is for actually sending spam is your big mistake. If you support spammers, even indirectly, you are part of the problem and in that case expect to get listed eventually (the less direct your support is, the later you are likely to be listed). Customers of ISPs that persist in harboring spammers are not innocent.
I have seen very very few networks listed unfairly by blacklists, including SPEWS. Care to go into any specifics?
What makes you think spam will die out if lots of people use intelligent filtering? Instead, spammers are constantly working on ways to evade those filters, and they do so effectively in some cases. They can, and some now do, make their "ads" look like conversations between people, who just happen to talk about the products really being advertised. Unless they used certain words like maybe "viagra", it can pass the filter. If your filter cuts out every message with "viagra", then even your own friends can't talk about it unless you whitelist them. And even then the spammers can find out who your friends are, if your computer got infected or you participate with them on a mailing list.
And none of this solves the other half of the spam problem, which is that networks and mail servers are being overloaded by the spam. For many businesses, mail uses more bandwidth than web access, and spam makes a substantial portion of that. They end up having to upgrade their mail server and/or their connection bandwidth sooner than they should have ... sooner than they would have had there been no spam at all.
The goal I and many other people have is to make it so that repeat/habitual spammers (I'm not talking about people who made the mistake of spamming once and got slapped for it) have no net access at all, and cannot even send a SYN packet, much less make an SMTP connection. Only then are they not stealing my resources.
What about the ISPs that let spammers stay connected? And what about the people that pay money to those ISPs so the ISPs can charge the spammers less?
I've found Bayesian to be totally ineffective in getting spammers to stop trying to send spam to my mail servers. DNS plus private blacklists are so far the most effective. No, they are not perfect as some legitimate mail occaisionally gets rejected. But I'm at around 99.95% spam blocked now, and see maybe 1 legitimate message lost per month or two. I can live with that. I can understand that some other people cannot live with that.
I do agree that ISPs that choose to use some particular method (i.e. don't let the customers choose) should at the very least tell the customers what method they use, so the customers can make the informed choice to stay or switch to another ISP or sue someone.