Unit testing doesn't help me; it just doesn't. It sucked time away from other more important things, and it always will for me.
My feeling is, when you are a neophyte, unit testing helps you get your code up to speed while you are learning about the pitfalls of programming. However, once you pass a certain point, unit testing is simply a wasteful phase.
The bad code you see comes from neophytes. Unit testing won't help them much because by the time they become disciplined enough to actually use them regularly enough to be helpful, they'll probably be at, or close, to being disciplined enough to not load code with bugs.
If you are dealing with programmers who continually pack their code with bugs, and it really eats up so much time that unit testing is saving you time, you might want to change out your coders; they don't sound very proficient to me. Code isn't supposed to be pressed through an extruder such as unit testing; it's an art, and it should be done by talented, intelligent people with enough experience to avoid obvious problems. Unit testing will only catch the most obvious of problems, and only in certain parts of your code, all the while slowing down development. If your team is operating at that level, I really feel your pain. I hate having to deal with programmers whose code is a constant source of problems.
I wholeheartedly disbelieve that the time you saved skipping unit tests was eaten up at QA. I've done it both ways, and it's much, much faster developing in the requirements. Unit tests are good quality assurance, but they are NOT a time-saver.
You also touched on another problem I have with unit testing: it influences the design pattern too much. I don't believe that the design which best fits with the unit testing framework is the best design pattern for the project. If your only goal is to make lots of happy unit tests, yeah, then alter your design to suit the tests...but that's WAY too restrictive for me. There are lots and lots of design patterns that are tough to write unit tests for, and the last thing I need is the wrong wheel squeaking for grease. I want my patterns to focus on the needs of the project, not the needs of a unit testing framework.
#1: No, the bugs aren't in the UI itself, the bugs originate through the UI. Users can do things in such a way that you simply can't predict.
#2: But you know, if you have time, there are LOTS of things you can do that might help, or might not. I stopped writing unit tests thinking that they one day *might* catch a bug. If I don't have an immediate or at least imminent benefit from it, I don't do it. It's simply a waste of time.
#3: I don't hack away at code, so I don't think unit tests will save me from something I don't do. My interfaces are developed exactly at the level of quality called for; no more and no less. So in the sense that unit tests can help me "think"...I never found myself lacking in that area. Perhaps it's something that helps less experienced programmers ramp up...I don't know. I've been programming for 20+ years and I'm alright in that regard.
Well, let's just say that the OVERWHELMING MAJORITY of software you use right now was developed WITHOUT the benefit of unit testing.
Have you never developed anything of significance without unit testing? I ask because it seems like you can't understand how it could be done. It not only CAN be done, it IS done, and some very solid, worthwhile code has been developed with absolutely no unit testing framework whatsoever.
But in answer to your question, (please understand that whatever I say cannot be construed as a template for ALL cases) in general, my development goes along these lines:
A rough blocking of the modules involved takes place. Basic interfaces between modules are planned tentatively. Development usually starts from the whole to the part, but sometimes modules are developed separately and integrated in later. At various points, re-factoring and code clean up. Interfaces are refined as things progress. Code is tested at intervals during development, and the tests are usually thrown away, but sometimes saved (depends on how stable the interface design is). At later stages, betas are delivered to the client and/or testers and the software is run through tests described on paper. After a certain period of time, when the software is deemed stable enough, it is considered "shipped" and checks are cut.
No, my unit tests were pretty good. I even wrote a testing framework after studying one framework and improving on it. You're talking to a person who took it PRETTY DARN SERIOUSLY and set time aside to develop an entire project dedicated to unit testing.
Despite the solid try, however, they never, or rarely, found any bugs.
Pair programming, refactoring, code review, etc...all excellent ways to increase the quality of your code: provided you have the time and budget. I'm sure with enough time spent on the task, I could write unit tests that can spear bugs with one parameter tied behind its back. The problem is, I could never make the time spent on it come back to me in time saved later on locating bugs. If the time had come back to me later on down the line, I'd take a different stand, but as it is, the time spent is just wasted.
I've given it enough of a chance that I wrote unit tests for about 3 small projects and developed my own framework for it.
I had three primary problems with it.
#1: My biggest problems always revolve around the user interface. Users encounter FAR more bugs than my internals do, and I never found a good way to unit test GUIs.
#2: I spent many hours developing tests for things that ended up rarely/never choking my tests, meaning they rarely/never caught any bugs. Yet, I still had bugs to work out. I found that it just wasn't worth the time.
#3: Whenever I re-factor, unless I'm Mr. Perfect and all my interfaces are perfect from the get-go, I end up having to edit a bunch of unit tests to match up with the new, re-factored code.
I know the party line on this, but I think it's just the current fad.
Clearly, if you applied unit testing to your own vstr project, then you have the luxury and authority to spend as much time as you see fit crafting out helpful unit tests. It is, nonetheless, a luxury, not an essential task. Pair programming is another luxury that people would do well with, but I wouldn't call it a requirement.
My experience has been that "unit testing" slows development to a painfully slow crawl. I find that the "gain" in quality I get is offset heavily by the reduction (or slow implementation) of features (usability, requirements, etc.). I did unit testing (once upon a time), and even developed my own test suite for C++, but I find that it catches VERY few bugs and I end up spending time writing unit tests AS WELL AS hunting down bugs the same old ways I always have. I just stopped bothering; I personally got little or nothing out of them.
They are, however, sort of fun to write. Like picking lint from your belly-button.
Re:KDE 3.2 is a piece of crap
on
Review: KDE 3.2
·
· Score: 1
You need to stop talking out of your ass and go look at the list of applications that are part of the KDE 3.2 release.
Re:KDE 3.2 is a piece of crap
on
Review: KDE 3.2
·
· Score: 2, Interesting
I shouldn't have said "KDE 3.2"; I should have said "the KDE 3.2 release packages" because most of the bugs are with the applications released.
Let's see, I've only been using it for 3 hours so far and I've got:
no sound
kopete crashes
pixieplus doesn't remember its window location anymore
the file browser hide all the context menu selections in sub-menus, making the context menu HIGHLY inconvenient now
my desktop is ugly; some of the icons in the new default set are just plain ugly, and my desktop no longer seems like a "theme" as much as a hodge-podge of images.
the login window also hides the selection to launch old KDE 3.1 and the other desktops; it used to be right on the dialog, but now it's buried in sub-menus.
The "loading" dialog also uses a funky color scheme that hides the progress percentage.
In fairness, I should say that, aside from the sound issue, I guess it's not very buggy, but it IS a HELL OF A LOT MORE ANNOYING than it used to be. It seems VERY, VERY *NOT* polished.
By tomorrow I should be happy with it again, assuming I can fix my sound issue.
It's chock-full of bugs, seriously...I'm grappling non-stop with problems. 3.1.4 was a FAR more stable release...I'm sorry I upgraded. Buggy, buggy, buggy. It really breaks my heart to see KDE at this phase...I have such high hopes for it.
What the hell are you talking about? What the hell is "U.K Standard?" "U.S. Standard" refers to the weights and measures system used in the U.S., of which feet, inches, yards, rods, etc. are all units.
>> A fucking meter is almost exactly the length of >> one fucking yard.
> Yeah, thats apparently what the disney people > thought too...
You know, I catch the humor you're pointing at in my semi-gaffe, but in all seriousness it's not even as intelligent as mistaking a yard for a meter. If the U.S. used fractions of a yard, then it might be understandable because the measurements would be so similar between U.S. Standard and metric (who could eyeball the difference between a 1/100 of a meter and 1/100 of a yard?). But we don't use fractions of yards! We use feet and inches for fuck's sake! The difference between something measuring half an inch and half a centimeter is PROFOUND! You can see that mistake a mile away! Gah!!! Our roadside signposts don't even TRY to demonstrate distances in kilometers to people; everything is 100% U.S. Standard (miles). It's truly, truly pathetic.
This is one thing that really embarrasses me as an American. How fucking hard is the metric system, really? I mean, really. A fucking meter is almost exactly the length of one fucking yard. Jesus H. Livingston.
Wow. So because both entities use the letter string "m-a-i-l" in their name, they should both be subject to full-fledged government regulation,
Yes, with adjustments to account for the actual difference. They are not the same thing precisely, but people depend on email just as much as they used to depend on postal mail. Integrity should be a high priority.
What about a private intranet? Should they open up a closed mail system to allow external sources to send them mail?
I don't what "open up a closed mail system" has to do with the price of tea in china. It's not remotely related to anything I've said.
I only mean these laws to apply to mail service providers. Meaning, mail could not be blocked by any provider as it travels to you unless done so by a compliant RBL. Once it arrives in your domain, you're free to fuck up delivery however you see fit.
What about when a mailserver goes down due to a technical problem. Should the admins be held legally responsible for the downtime, subject to criminal penalties for email being lost?
Is someone automatically criminally indicted when an airplane carrying postal mail crashes? No. Don't make me answer questions you could easily discern for yourself. This was an obvious question. What does this have to do with SPEWS anyway?
Can you give me something more tangible to justify your assertion that email should be subject to the same regulations as postal mail?
This is clearly a value issue. I could offer arguments, but whether or not you feel they're important is what really matters. Is freedom of speech a justifiable right? Perhaps. Some people argue for it, some against it. It's your own personal values that will decide, not my words. Why is U.S. postal mail protected so well, legally-speaking? It's a matter of integrity. I feel email should have the same integrity. Why? I just do: it reflects on my values.
So if an ISP determined that absolutely none of its customers wanted to receive mail from South America, China or the networks run by Cogentco, it would be okay for the ISP to refuse to accept mail from any mailservers hosted in South America, China or Cogentco, or do you support the US government forcing someone to accept unwanted email at their own expense?
The customer can opt out of anything they want, but the ISP couldn't opt them out automatically. A clear request by the customer would be one way to circumvent the law.
What about faxes? Should people be required, by law, to accept unsolicited junk faxes at their expense?
Somewhere along the line, you stopped listening to what I have been saying and have decided I'm anti-RBL. Why would I support a law that says people are required to receive faxes they don't want? What does that have to do with an RBL operating with integrity?
Okay. So you do advocate forcing private entities to allow all kinds of network abuse to be perpetuated on their systems, and they should just eat the cost even though there are simple means for averting the damage.
Yes, they should eat the cost. We have a choice: we can strive for integrity or we can strive to save money. My feeling is, fuck grubbing around for money. If you won't deliver email to your customers because it comes from a server that has an IP address which is on the same block as a known spamming mail server, you're a fucking money-grubbing bitch and should go back to your pyramid schemes.
If you're telling me that email should be expected to be delivered with the same level of guarantee of postal mail, I'll tell you to lay off of the crack pipe.
You're missing my point. I'm not advocating delivery assurance.
That's like if I said "I think it should be illegal for people to steal cars" you coming back at me with "are you telling me people should all get cars for free?"
I'm not advocating delivery assurance. I'm advocating legislation to ensure RBL
Are you saying that you want INTERNATIONAL regulation of email?
No, the U.S. takes care of themselves, Europe themselves, etc.
What is your justification for this?
If regular mail deserves protection to ensure its integrity, so does email.
Also, you didn't address my question about ISPs who decide to construct their own private filter lists, as has been done well before public RBLs existed.
So long as they don't violate regulations, they can make their own RBL and subscribe to any external, compliant RBL.
In other words, you DO want ISPs to bear the burden (billions of dollars per year) of processing and storing junk email messages without the option of stopping them at the router level.
No, they can block at the router, but they have to perform blacklistings according to some rules which promote a lot more integrity than SPEWS exhibits. However, where the RBLs fail, yes, the ISPs should carry that burden. They are carrying mail. If they can't handle the job, and handle it properly, they should go do something else. This is mail. They shouldn't cut off legitimate email because it mixes in with email that they don't want to deliver. They shouldn't be delivering mail if their level of integrity puts money higher on their list of priorities than delivering valid letters. Physical mail is a HELL of a lot more expensive to deliver, and U.S. Postal Service has vowed to deliver through "rain, sleet, wind, snow" etc. How spineless is an ISP to fail to deliver a valid letter because someone told them that the server it comes from sends spam? That's pretty spineless.
Okay. Say I want to block all Verizon traffic at the router, because Verizon is known to support criminal activity. How do I go about contacting EVERY Verizon user to let them know that they'll no longer be able to access my servers?
First of all, let's make the assumption that there's a new set of laws governing this, and it works in the following way:
To blacklist a single IP address temporarily as a means to effectively halt a massively spewing mail server, you could list the IP address for a period of no more than 48 hours without notice to anyone, immediately, and no more than once every 3 days.
To continue the blacklisting on a more permanent basis, you would have to walk through a series of arbitration attempts to reconcile the issue with Verizon. If these fail, you would be required to send an email notice to the postmaster at the ipaddress of the offending mail server 24 hours before permanently (or long-term) listing the IP address.
In this way, you could blacklist spamming servers INSTANTLY and never be required to de-list them if you can't get them to stop spewing spam. You have 48 hours to work. 24 to arbitrate, another 24 goes to the postmaster. There no break in blacklisting, and every postmaster knows they will never have to experience more than 48 hours of downtime (easily handled by anyone semi-competent).
To resolve chronic spam problems, you could take one of three routes:
1) If you notice the same IP address repeats the spamming operation, you shut them down exactly as you did above, except your argument for permanent listing is very strong, so it's likely that IP address would go dark indefinitely. Again, this shuts down servers instantly and keeps them down if arbitration fails.
2) If you notice that spam has hopped from one IP to another in the same net block, you would shut down the IP address instantly as before, except the arbitration, instead of aiming to resolve or permanently shut down just the IP address, could be that the entire netblock should be shut down. This not only shuts the spamming server down instantly, it shuts down the entire netblock so the spam can't be hopped again.
3) If the ISP itself is simply harboring spammers, you have to shut down their entire operation. Go to court, get a real judgement against them, have them dissolved, and b
The U.S. takes care of the U.S., Europe takes care of Europe, etc. The thing is, you can hold the ISPs themselves accountable, for blacklisting servers illegally through a renegade RBL. Jurisdiction is very easy to manage. Sure, your ISP can start using an RBL that operates out of Iran and DOESN'T adhere to guidelines, but if they operate in the U.S., they'll be the ones "illegally tampering with electronic mail." If you want to jump hoops and have your email forwarded outside the U.S. to have it filtered through a renegade RBL, feel free. However, that would mean only the technically-inclined get their mail filtered improperly. All the non-techies out there signed up at RandomISP, Inc. will not have their mail filtered, and thus the problem of an RBL irresponsibly is drastically mitigated.
Why do I think the users should be notified? So the users can take action in advance of the shutdown. SPEWS isn't using innocent users who run honorable mail servers against their will, are they? They aren't shutting blacklisting innocents by design, are they? I see no problem in requiring ISPs to notify all affected users when their IPs are threatened to be blacklisted.
Pretty straight-forward. Make laws governing RBLs and then go after ISPs who illegally subject their U.S. customers' email to non-compliant RBLs. While you're at it, make a law that says when an ISP receives a notice that any IPs may be blocked, they must notify all users of those IPs.
Do you really think that, so long as you continue to debate a topic, that you're winning the debate? That the first person to cease expounding their point of view loses? Put the vodka down, comrade, and steer away from the pre-school.
Hey, since I lose, what did you win? Can I no longer rail against SPEWS and support legal action to curb their activities? Yes? No?
My argument stands. Blabber all you want, you've changed nothing in this corner. Actually, no, I take that back. I was sitting on the fence pretty much before you started in with your drivel. Now I'm dead-fucking-against SPEWS and their ilk.
I know how SPEWS operates, and I know how they're used; no need to offer me lessons. I know it only TOO well. They do NOTHING to notify the people involved. They send notices to ISP's with ZERO hard proof, assert that crap they forward is hard proof, then simply shut off IP blocks. Which doesn't actually stop the spam because when a spammer does a run, it's as a paid service, so that mail is going out regardless...it's just going to get moved to another server.
Spammers are prepared to jump servers quickly. The innocents on the IP blocked who find their mail server suddenly unable to send typically aren't as prepared, and it costs a LOT of time and money. We lost THOUSANDS of dollars because of SPEWS.
Frivolous lawsuits? That's in the eye of the beholder. What appears frivolous to you appears LOOOOONG overdue to me. Thank god EVERYONE has a say, and not just the SPEWS facists.
Slashdot Mirror
Unit testing doesn't help me; it just doesn't. It sucked time away from other more important things, and it always will for me.
My feeling is, when you are a neophyte, unit testing helps you get your code up to speed while you are learning about the pitfalls of programming. However, once you pass a certain point, unit testing is simply a wasteful phase.
The bad code you see comes from neophytes. Unit testing won't help them much because by the time they become disciplined enough to actually use them regularly enough to be helpful, they'll probably be at, or close, to being disciplined enough to not load code with bugs.
If you are dealing with programmers who continually pack their code with bugs, and it really eats up so much time that unit testing is saving you time, you might want to change out your coders; they don't sound very proficient to me. Code isn't supposed to be pressed through an extruder such as unit testing; it's an art, and it should be done by talented, intelligent people with enough experience to avoid obvious problems. Unit testing will only catch the most obvious of problems, and only in certain parts of your code, all the while slowing down development. If your team is operating at that level, I really feel your pain. I hate having to deal with programmers whose code is a constant source of problems.
I wholeheartedly disbelieve that the time you saved skipping unit tests was eaten up at QA. I've done it both ways, and it's much, much faster developing in the requirements. Unit tests are good quality assurance, but they are NOT a time-saver.
You also touched on another problem I have with unit testing: it influences the design pattern too much. I don't believe that the design which best fits with the unit testing framework is the best design pattern for the project. If your only goal is to make lots of happy unit tests, yeah, then alter your design to suit the tests...but that's WAY too restrictive for me. There are lots and lots of design patterns that are tough to write unit tests for, and the last thing I need is the wrong wheel squeaking for grease. I want my patterns to focus on the needs of the project, not the needs of a unit testing framework.
#1: No, the bugs aren't in the UI itself, the bugs originate through the UI. Users can do things in such a way that you simply can't predict.
#2: But you know, if you have time, there are LOTS of things you can do that might help, or might not. I stopped writing unit tests thinking that they one day *might* catch a bug. If I don't have an immediate or at least imminent benefit from it, I don't do it. It's simply a waste of time.
#3: I don't hack away at code, so I don't think unit tests will save me from something I don't do. My interfaces are developed exactly at the level of quality called for; no more and no less. So in the sense that unit tests can help me "think"...I never found myself lacking in that area. Perhaps it's something that helps less experienced programmers ramp up...I don't know. I've been programming for 20+ years and I'm alright in that regard.
Well, let's just say that the OVERWHELMING MAJORITY of software you use right now was developed WITHOUT the benefit of unit testing.
Have you never developed anything of significance without unit testing? I ask because it seems like you can't understand how it could be done. It not only CAN be done, it IS done, and some very solid, worthwhile code has been developed with absolutely no unit testing framework whatsoever.
But in answer to your question, (please understand that whatever I say cannot be construed as a template for ALL cases) in general, my development goes along these lines:
A rough blocking of the modules involved takes place. Basic interfaces between modules are planned tentatively. Development usually starts from the whole to the part, but sometimes modules are developed separately and integrated in later. At various points, re-factoring and code clean up. Interfaces are refined as things progress. Code is tested at intervals during development, and the tests are usually thrown away, but sometimes saved (depends on how stable the interface design is). At later stages, betas are delivered to the client and/or testers and the software is run through tests described on paper. After a certain period of time, when the software is deemed stable enough, it is considered "shipped" and checks are cut.
No, my unit tests were pretty good. I even wrote a testing framework after studying one framework and improving on it. You're talking to a person who took it PRETTY DARN SERIOUSLY and set time aside to develop an entire project dedicated to unit testing.
Despite the solid try, however, they never, or rarely, found any bugs.
Pair programming, refactoring, code review, etc...all excellent ways to increase the quality of your code: provided you have the time and budget. I'm sure with enough time spent on the task, I could write unit tests that can spear bugs with one parameter tied behind its back. The problem is, I could never make the time spent on it come back to me in time saved later on locating bugs. If the time had come back to me later on down the line, I'd take a different stand, but as it is, the time spent is just wasted.
I've given it enough of a chance that I wrote unit tests for about 3 small projects and developed my own framework for it.
I had three primary problems with it.
#1: My biggest problems always revolve around the user interface. Users encounter FAR more bugs than my internals do, and I never found a good way to unit test GUIs.
#2: I spent many hours developing tests for things that ended up rarely/never choking my tests, meaning they rarely/never caught any bugs. Yet, I still had bugs to work out. I found that it just wasn't worth the time.
#3: Whenever I re-factor, unless I'm Mr. Perfect and all my interfaces are perfect from the get-go, I end up having to edit a bunch of unit tests to match up with the new, re-factored code.
I know the party line on this, but I think it's just the current fad.
Clearly, if you applied unit testing to your own vstr project, then you have the luxury and authority to spend as much time as you see fit crafting out helpful unit tests. It is, nonetheless, a luxury, not an essential task. Pair programming is another luxury that people would do well with, but I wouldn't call it a requirement.
My experience has been that "unit testing" slows development to a painfully slow crawl. I find that the "gain" in quality I get is offset heavily by the reduction (or slow implementation) of features (usability, requirements, etc.). I did unit testing (once upon a time), and even developed my own test suite for C++, but I find that it catches VERY few bugs and I end up spending time writing unit tests AS WELL AS hunting down bugs the same old ways I always have. I just stopped bothering; I personally got little or nothing out of them.
They are, however, sort of fun to write. Like picking lint from your belly-button.
10 years ago, using gopher on sunos at netcom.com
You need to stop talking out of your ass and go look at the list of applications that are part of the KDE 3.2 release.
I shouldn't have said "KDE 3.2"; I should have said "the KDE 3.2 release packages" because most of the bugs are with the applications released.
Let's see, I've only been using it for 3 hours so far and I've got:
no sound
kopete crashes
pixieplus doesn't remember its window location anymore
the file browser hide all the context menu selections in sub-menus, making the context menu HIGHLY inconvenient now
my desktop is ugly; some of the icons in the new default set are just plain ugly, and my desktop no longer seems like a "theme" as much as a hodge-podge of images.
the login window also hides the selection to launch old KDE 3.1 and the other desktops; it used to be right on the dialog, but now it's buried in sub-menus.
The "loading" dialog also uses a funky color scheme that hides the progress percentage.
In fairness, I should say that, aside from the sound issue, I guess it's not very buggy, but it IS a HELL OF A LOT MORE ANNOYING than it used to be. It seems VERY, VERY *NOT* polished.
By tomorrow I should be happy with it again, assuming I can fix my sound issue.
It's chock-full of bugs, seriously...I'm grappling non-stop with problems. 3.1.4 was a FAR more stable release...I'm sorry I upgraded. Buggy, buggy, buggy. It really breaks my heart to see KDE at this phase...I have such high hopes for it.
What the hell are you talking about? What the hell is "U.K Standard?" "U.S. Standard" refers to the weights and measures system used in the U.S., of which feet, inches, yards, rods, etc. are all units.
Talk about needing to hit the books.
>> A fucking meter is almost exactly the length of
>> one fucking yard.
> Yeah, thats apparently what the disney people
> thought too...
You know, I catch the humor you're pointing at in my semi-gaffe, but in all seriousness it's not even as intelligent as mistaking a yard for a meter. If the U.S. used fractions of a yard, then it might be understandable because the measurements would be so similar between U.S. Standard and metric (who could eyeball the difference between a 1/100 of a meter and 1/100 of a yard?). But we don't use fractions of yards! We use feet and inches for fuck's sake! The difference between something measuring half an inch and half a centimeter is PROFOUND! You can see that mistake a mile away! Gah!!! Our roadside signposts don't even TRY to demonstrate distances in kilometers to people; everything is 100% U.S. Standard (miles). It's truly, truly pathetic.
This is one thing that really embarrasses me as an American. How fucking hard is the metric system, really? I mean, really. A fucking meter is almost exactly the length of one fucking yard. Jesus H. Livingston.
Wow. So because both entities use the letter string "m-a-i-l" in their name, they should both be subject to full-fledged government regulation,
Yes, with adjustments to account for the actual difference. They are not the same thing precisely, but people depend on email just as much as they used to depend on postal mail. Integrity should be a high priority.
What about a private intranet? Should they open up a closed mail system to allow external sources to send them mail?
I don't what "open up a closed mail system" has to do with the price of tea in china. It's not remotely related to anything I've said.
I only mean these laws to apply to mail service providers. Meaning, mail could not be blocked by any provider as it travels to you unless done so by a compliant RBL. Once it arrives in your domain, you're free to fuck up delivery however you see fit.
What about when a mailserver goes down due to a technical problem. Should the admins be held legally responsible for the downtime, subject to criminal penalties for email being lost?
Is someone automatically criminally indicted when an airplane carrying postal mail crashes? No. Don't make me answer questions you could easily discern for yourself. This was an obvious question. What does this have to do with SPEWS anyway?
Can you give me something more tangible to justify your assertion that email should be subject to the same regulations as postal mail?
This is clearly a value issue. I could offer arguments, but whether or not you feel they're important is what really matters. Is freedom of speech a justifiable right? Perhaps. Some people argue for it, some against it. It's your own personal values that will decide, not my words. Why is U.S. postal mail protected so well, legally-speaking? It's a matter of integrity. I feel email should have the same integrity. Why? I just do: it reflects on my values.
So if an ISP determined that absolutely none of its customers wanted to receive mail from South America, China or the networks run by Cogentco, it would be okay for the ISP to refuse to accept mail from any mailservers hosted in South America, China or Cogentco, or do you support the US government forcing someone to accept unwanted email at their own expense?
The customer can opt out of anything they want, but the ISP couldn't opt them out automatically. A clear request by the customer would be one way to circumvent the law.
What about faxes? Should people be required, by law, to accept unsolicited junk faxes at their expense?
Somewhere along the line, you stopped listening to what I have been saying and have decided I'm anti-RBL. Why would I support a law that says people are required to receive faxes they don't want? What does that have to do with an RBL operating with integrity?
Okay. So you do advocate forcing private entities to allow all kinds of network abuse to be perpetuated on their systems, and they should just eat the cost even though there are simple means for averting the damage.
Yes, they should eat the cost. We have a choice: we can strive for integrity or we can strive to save money. My feeling is, fuck grubbing around for money. If you won't deliver email to your customers because it comes from a server that has an IP address which is on the same block as a known spamming mail server, you're a fucking money-grubbing bitch and should go back to your pyramid schemes.
If you're telling me that email should be expected to be delivered with the same level of guarantee of postal mail, I'll tell you to lay off of the crack pipe.
You're missing my point. I'm not advocating delivery assurance.
That's like if I said "I think it should be illegal for people to steal cars" you coming back at me with "are you telling me people should all get cars for free?"
I'm not advocating delivery assurance. I'm advocating legislation to ensure RBL
Are you saying that you want INTERNATIONAL regulation of email?
No, the U.S. takes care of themselves, Europe themselves, etc.
What is your justification for this?
If regular mail deserves protection to ensure its integrity, so does email.
Also, you didn't address my question about ISPs who decide to construct their own private filter lists, as has been done well before public RBLs existed.
So long as they don't violate regulations, they can make their own RBL and subscribe to any external, compliant RBL.
In other words, you DO want ISPs to bear the burden (billions of dollars per year) of processing and storing junk email messages without the option of stopping them at the router level.
No, they can block at the router, but they have to perform blacklistings according to some rules which promote a lot more integrity than SPEWS exhibits. However, where the RBLs fail, yes, the ISPs should carry that burden. They are carrying mail. If they can't handle the job, and handle it properly, they should go do something else. This is mail. They shouldn't cut off legitimate email because it mixes in with email that they don't want to deliver. They shouldn't be delivering mail if their level of integrity puts money higher on their list of priorities than delivering valid letters. Physical mail is a HELL of a lot more expensive to deliver, and U.S. Postal Service has vowed to deliver through "rain, sleet, wind, snow" etc. How spineless is an ISP to fail to deliver a valid letter because someone told them that the server it comes from sends spam? That's pretty spineless.
Okay. Say I want to block all Verizon traffic at the router, because Verizon is known to support criminal activity. How do I go about contacting EVERY Verizon user to let them know that they'll no longer be able to access my servers?
First of all, let's make the assumption that there's a new set of laws governing this, and it works in the following way:
To blacklist a single IP address temporarily as a means to effectively halt a massively spewing mail server, you could list the IP address for a period of no more than 48 hours without notice to anyone, immediately, and no more than once every 3 days.
To continue the blacklisting on a more permanent basis, you would have to walk through a series of arbitration attempts to reconcile the issue with Verizon. If these fail, you would be required to send an email notice to the postmaster at the ipaddress of the offending mail server 24 hours before permanently (or long-term) listing the IP address.
In this way, you could blacklist spamming servers INSTANTLY and never be required to de-list them if you can't get them to stop spewing spam. You have 48 hours to work. 24 to arbitrate, another 24 goes to the postmaster. There no break in blacklisting, and every postmaster knows they will never have to experience more than 48 hours of downtime (easily handled by anyone semi-competent).
To resolve chronic spam problems, you could take one of three routes:
1) If you notice the same IP address repeats the spamming operation, you shut them down exactly as you did above, except your argument for permanent listing is very strong, so it's likely that IP address would go dark indefinitely. Again, this shuts down servers instantly and keeps them down if arbitration fails.
2) If you notice that spam has hopped from one IP to another in the same net block, you would shut down the IP address instantly as before, except the arbitration, instead of aiming to resolve or permanently shut down just the IP address, could be that the entire netblock should be shut down. This not only shuts the spamming server down instantly, it shuts down the entire netblock so the spam can't be hopped again.
3) If the ISP itself is simply harboring spammers, you have to shut down their entire operation. Go to court, get a real judgement against them, have them dissolved, and b
The U.S. takes care of the U.S., Europe takes care of Europe, etc. The thing is, you can hold the ISPs themselves accountable, for blacklisting servers illegally through a renegade RBL. Jurisdiction is very easy to manage. Sure, your ISP can start using an RBL that operates out of Iran and DOESN'T adhere to guidelines, but if they operate in the U.S., they'll be the ones "illegally tampering with electronic mail." If you want to jump hoops and have your email forwarded outside the U.S. to have it filtered through a renegade RBL, feel free. However, that would mean only the technically-inclined get their mail filtered improperly. All the non-techies out there signed up at RandomISP, Inc. will not have their mail filtered, and thus the problem of an RBL irresponsibly is drastically mitigated.
Why do I think the users should be notified? So the users can take action in advance of the shutdown. SPEWS isn't using innocent users who run honorable mail servers against their will, are they? They aren't shutting blacklisting innocents by design, are they? I see no problem in requiring ISPs to notify all affected users when their IPs are threatened to be blacklisted.
Pretty straight-forward. Make laws governing RBLs and then go after ISPs who illegally subject their U.S. customers' email to non-compliant RBLs. While you're at it, make a law that says when an ISP receives a notice that any IPs may be blocked, they must notify all users of those IPs.
The force of law governs physical postal mail, it should govern email.
Sure you were.
I suppose you mean "disinclined." Dispose yourself on the matter how you wish. If you haven't already, pin a medal on yourself.
Do you really think that, so long as you continue to debate a topic, that you're winning the debate? That the first person to cease expounding their point of view loses? Put the vodka down, comrade, and steer away from the pre-school.
Hey, since I lose, what did you win? Can I no longer rail against SPEWS and support legal action to curb their activities? Yes? No?
My argument stands. Blabber all you want, you've changed nothing in this corner. Actually, no, I take that back. I was sitting on the fence pretty much before you started in with your drivel. Now I'm dead-fucking-against SPEWS and their ilk.
You're like talking to a drunk who insists on driving.
Fail to see whatever you wish to fail to see. Declare yourself the winner, while you're at it.
I know how SPEWS operates, and I know how they're used; no need to offer me lessons. I know it only TOO well. They do NOTHING to notify the people involved. They send notices to ISP's with ZERO hard proof, assert that crap they forward is hard proof, then simply shut off IP blocks. Which doesn't actually stop the spam because when a spammer does a run, it's as a paid service, so that mail is going out regardless...it's just going to get moved to another server.
Spammers are prepared to jump servers quickly. The innocents on the IP blocked who find their mail server suddenly unable to send typically aren't as prepared, and it costs a LOT of time and money. We lost THOUSANDS of dollars because of SPEWS.
Frivolous lawsuits? That's in the eye of the beholder. What appears frivolous to you appears LOOOOONG overdue to me. Thank god EVERYONE has a say, and not just the SPEWS facists.