If he wants to really shaft them he can try to have the contract declared null and void due to their non-payment and go after them for copyright violation, but that's more hassle than I think I would want to deal with, and definately requires a lawyer.
The real fun starts if you can prove (or persuade) that the other party negoiated the contract 'in bad faith;' in other words, that they planned to shaft you from the get go.
I'm confuzzled. Oh, and I'm probably screwing up my recp to/mail from (or is it rcpt from/mail to?) but you'll get my point.
smtp service OK.
>EHLO i-am-a-spammer.com
Hello, i-am-a-spammer.com.
>MAIL FROM: somebody@yourdomain.com
250 OK
>RCPT TO: somebodywhodoesn'twantspam@yourdomain.com
451: A temporary failure cuz your triplet is untrusted.
>curses, I'll be back later.
So who's going to vet it as 'spam?' Want to do it after the DATA message is sent? Then you're doubling your bandwidth.
Want to try to identify based on the fact that there's a ton of mails coming through in a short period of time? What if the spammer simply re-orders his spam database, so it's not sorted by domain? If he has 1,000,000 emails, with, oh, 10,000 separate domains, then only every 100th email he sends will be to your domain, if he spaces them properly.
I get annoyed when people attack something for not doing something the author specifically claims it won't do. What! It doesn't do your laundry? Shame. How clever of you to point that out.
I'm not attacking anything. I'm simply pointing out design issues (not necessarily flaws!) that the author, or you, might not have thought of. Isn't that one of the ideas behind open source? A sort of darwinian wheedling?
So the trade off is that you're (at least) doubling your bandwidth requirements to save on bandwidth?
I still don't see the benefit; currently, somebody gets a spam, off it goes to Razor,or pyzor, or DCC, or whatever, then you still get it, but you reject it.
Now, you reject it for an hour, get it again anyway, then check it against razor or whatever, doesn't seem to be a net gain.
Still, if it catches more than about five percent of total, I guess it's worth it.
Well, how about the part that in both America and Canada, there are plenty of laws about how phone systems need to work? How it's considered an 'essential service?' How there are SLAs built into law?
If you're capable of keeping an SMTP server up and running, but not a phone system, I'd say you've got problems. Or, you're not running a phone system, you're running a telephony system.
HTML wasn't supposed to be used for realtime stock quotes, banking software or content generation and control. I dare you to go up to your boss and tell him you're going to turn off those functions. See if you keep your job.
Yes, and it's changed and evolved to handle such things.
SMTP hasn't. It doesn't contain any provision for delivery notices, for alternate routing, proper failure notification, anything like that. That, and the fact that it relies on HOSTS YOU DO NOT CONTROL, means that you CANNOT make it a guarenteed system, without a major overhaul.
Or are you the kind of person who blames your IT department when the router of the company you're trying to send mail to is down, and it's delayed?
But you can already do that. And lots of people do. So spammers just hop IP addresses. So people block dynamic blocks. But that hurts legitimate users. And so on.
The only solution to the spammer problem is the granting of plenipotentary powers of execution to, well, me. I'll be like Judge Dredd, only not quite as big and menacing.
Exactly. That, and suddenly, if this system takes off, and all mail gets delayed by an hour, well, sure, the spammers need more resources, but so do legitimate mail senders. Suddenly you need to queue up your mail for an hour; disk space, send it twice; bandwidth, and so on.
This relies on the fact that spam software, unlike a real MTA, doesn't do things like care about 4xx series temp fail messages. So, you recode your software so that it does, or so that it simply runs through the script again. This implements a 1 hour delay. Not a 1 hour wait between different messages, or anything. People get their spam an hour after you initiate sending. BFD.
RIGHT NOW, this will stop spam cold. In six months, it will be useless.
Re:Interesting quote from ESR
on
My Visit to SCO
·
· Score: 1
Of course he considers code to be stolen property; it's really hard to have a concept of 'free code' unless there's an alternate state fo it to exist in.
So you mix up your spams; rather than sending all viagra, you send a few viagra, and a few mortgage, a few horny teen sluts, and so on.
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
Oh, I've seen it, and I warn people against it all the time.
But, hey, most companies are schizo when it comes to IT. You wouldn't let your accounts recieveable rely on random people who may or may not pass on your records unchanged and unread; so why do you trust your business communications to SMTP email?
As stated, the only reason the hour works right now is because the spammers don't see this in the wild. Re-running your database script an hour later isn't a big deal.
If you can send legitimate mail through a system from a random source on the Internet, you can run illegitimate mail through it. Period.
I did. Big freakin whoop. It pays attention to multiple incomings? Randomize your list so you're breaking them up. It wants you to wait an hour? Then WAIT AN HOUR.
The way to get around this, of course, being that you send each email twice. In other words, run through your database, then run through your database. Same IP addy, same sender, same recipient. As far as the MTA's concerned, it's retrying. Boom.
And this guy isn't able to open an FBI complaint on the behalf of his ISP. So, ipso facto, he was opening an FBI complaint on his own behalf, and the FBI couldn't be bothered to deal with it.
IF the ISP opens the same complaint, the FBI might do something about it.
That and the fact that any old idiot can call up and claim a problem; if you're not willing to put it in writing, you must not care very much about it, eh?
Slashdot Mirror
The real fun starts if you can prove (or persuade) that the other party negoiated the contract 'in bad faith;' in other words, that they planned to shaft you from the get go.
I'm confuzzled. Oh, and I'm probably screwing up my recp to/mail from (or is it rcpt from/mail to?) but you'll get my point.
smtp service OK.
>EHLO i-am-a-spammer.com
Hello, i-am-a-spammer.com.
>MAIL FROM: somebody@yourdomain.com
250 OK >RCPT TO: somebodywhodoesn'twantspam@yourdomain.com
451: A temporary failure cuz your triplet is untrusted.
>curses, I'll be back later.
So who's going to vet it as 'spam?' Want to do it after the DATA message is sent? Then you're doubling your bandwidth.
Want to try to identify based on the fact that there's a ton of mails coming through in a short period of time? What if the spammer simply re-orders his spam database, so it's not sorted by domain? If he has 1,000,000 emails, with, oh, 10,000 separate domains, then only every 100th email he sends will be to your domain, if he spaces them properly.
I'm not attacking anything. I'm simply pointing out design issues (not necessarily flaws!) that the author, or you, might not have thought of. Isn't that one of the ideas behind open source? A sort of darwinian wheedling?
So the trade off is that you're (at least) doubling your bandwidth requirements to save on bandwidth?
I still don't see the benefit; currently, somebody gets a spam, off it goes to Razor,or pyzor, or DCC, or whatever, then you still get it, but you reject it.
Now, you reject it for an hour, get it again anyway, then check it against razor or whatever, doesn't seem to be a net gain.
Still, if it catches more than about five percent of total, I guess it's worth it.
Well, how about the part that in both America and Canada, there are plenty of laws about how phone systems need to work? How it's considered an 'essential service?' How there are SLAs built into law?
If you're capable of keeping an SMTP server up and running, but not a phone system, I'd say you've got problems. Or, you're not running a phone system, you're running a telephony system.
Woah. Ok. Your qmail server is more stable than the phone system. With that, there is no longer any point to this discussion.
Hey, boy, cool down a bit.
Yes, and it's changed and evolved to handle such things.
SMTP hasn't. It doesn't contain any provision for delivery notices, for alternate routing, proper failure notification, anything like that. That, and the fact that it relies on HOSTS YOU DO NOT CONTROL, means that you CANNOT make it a guarenteed system, without a major overhaul.
Or are you the kind of person who blames your IT department when the router of the company you're trying to send mail to is down, and it's delayed?
But you can already do that. And lots of people do. So spammers just hop IP addresses. So people block dynamic blocks. But that hurts legitimate users. And so on.
The only solution to the spammer problem is the granting of plenipotentary powers of execution to, well, me. I'll be like Judge Dredd, only not quite as big and menacing.
Exactly. That, and suddenly, if this system takes off, and all mail gets delayed by an hour, well, sure, the spammers need more resources, but so do legitimate mail senders. Suddenly you need to queue up your mail for an hour; disk space, send it twice; bandwidth, and so on.
How, exactly, is it a big hit on their resources? It doesn't take very long to send out 250,000,000 emails.
Nothing to do with open relays, my friend.
This relies on the fact that spam software, unlike a real MTA, doesn't do things like care about 4xx series temp fail messages. So, you recode your software so that it does, or so that it simply runs through the script again. This implements a 1 hour delay. Not a 1 hour wait between different messages, or anything. People get their spam an hour after you initiate sending. BFD.
RIGHT NOW, this will stop spam cold. In six months, it will be useless.
Of course he considers code to be stolen property; it's really hard to have a concept of 'free code' unless there's an alternate state fo it to exist in.
So you mix up your spams; rather than sending all viagra, you send a few viagra, and a few mortgage, a few horny teen sluts, and so on.
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
Oh, I've seen it, and I warn people against it all the time.
But, hey, most companies are schizo when it comes to IT. You wouldn't let your accounts recieveable rely on random people who may or may not pass on your records unchanged and unread; so why do you trust your business communications to SMTP email?
No, it will not. It will simply delay it by ten minutes, or whatever the dupe window is.
As stated, the only reason the hour works right now is because the spammers don't see this in the wild. Re-running your database script an hour later isn't a big deal.
If you can send legitimate mail through a system from a random source on the Internet, you can run illegitimate mail through it. Period.
I did. Big freakin whoop. It pays attention to multiple incomings? Randomize your list so you're breaking them up. It wants you to wait an hour? Then WAIT AN HOUR.
The way to get around this, of course, being that you send each email twice. In other words, run through your database, then run through your database. Same IP addy, same sender, same recipient. As far as the MTA's concerned, it's retrying. Boom.
Besides, if you're using SMTP for time-critical things, you have a problem, as SMTP is NOT a guarenteed delivery system.
And this guy isn't able to open an FBI complaint on the behalf of his ISP. So, ipso facto, he was opening an FBI complaint on his own behalf, and the FBI couldn't be bothered to deal with it.
IF the ISP opens the same complaint, the FBI might do something about it.
Why..would your...plutonium containment computer...be hooked up...to a network..let alone..a public network..such as..the...Internet...?
That and the fact that any old idiot can call up and claim a problem; if you're not willing to put it in writing, you must not care very much about it, eh?
Also known as Bettas, it's a fun and inexpensive hobby.
Time consuming, though. And you need LOTS of little jars...those little buggers have HUGE clutches.
*knock knock* Hi, somebody here ordered pizza...? *roll credits*
Ah, but Japan is smaller than California, yes? Much easier to wire up the place.
Using people who claim to see the future, or get visions, to determine your payrolls is NEVER a good idea. :-)