I'll be so angry, there's no way I'll buy more than 500 shares.
But seriously, folks, RedHat is walking a very thin line here. I suspect would take the position that if you wrote code that ended up in RedHat, that would constitute a prior relationship. That's not a completely unreasonable position, either. Then again, there are a lot of anti-spam people out there are ARE completely unreasonable. I'm sure spammers love them, too, because they make tend to make all anti-spammer look stupid.
I just hope it's not something real stupid like those X10 spams I keep getting. Dammit, if I get something that reads like a porno spam, there damn well better be some naked chicks on their site!
Well, no quite enough for every particle in the universe. 2^128 is about 10^38 or so. A mole of atoms is 6.023e23 atoms, and a mole of carbon atoms (assuming C-12) has a mass of 12 grams. In molar units, there are about 5.6e14 moles of IP numbers in the IPv6 namespace. If IP numbers were carbon atoms, they'd weigh about 6.8e12 kg. That's only about 7000 metric tonnes. A mere drop in the ocean.
Yes, Linux 2.2 has IPv6, but you have to enable it. You probably have to update some net tools as well. Check out the 6bone web site. 6bone is IPv6 tunnelled over IPv4. There's also a registry there for IP addresses, thought perhaps that'll be one the way out now.
Try Amanda. It uses dump or tar on UNIX, and I think there may be some clients for Windoze. Also look for BURT on Freshmeat. That one looked interesting, requires TCL.
Fine. E-mail is not a fax, even if his computer is a fax machine. You would be very hard pressed to find a judge to side with the position that junk e-mail is in violation of the junk fax law.
Re:An *EASY* and *OBVIOUS* solution to SPAM.
on
Austria Bans Spam
·
· Score: 1
If it's easy and obvious, where's the code?
Sheesh. What's this supposed to mean?
If it were easy and obvious, it would have been done already.
For your spam signature program, be prepared to deal with hashbusters in the subject and body.
For each indidivual message?
Damn straight. There is at least one bulk mailing program which throws in a message counter (body and subject), a line of astericks, and varies the subject line. If you can find a reliable means of counteracting this, by all means, write it.
I don't think network bandwidth is the worst thing about SPAM. The time lost on the part of the end user who has to download the mail, read it, spend time working out it's not something they want, etc. is more of a problem.
It's been claimed that 10% of an ISP bill is to covering the costs of spamming. Unless you have to pay a metered rate, which is not too common in the US, the end-user part is not that big of a problem.
The real impact of spam is on the ISP mail server. Spam, by nature, tends to be spikey. One spammer, even with a modem, can deliver 50K messages in under an hour. These messages often have lots of bounces, and they have to be delivered, and usually those bounce. If you are running sendmail, you better hope you have a separate machine that just does your customer's SMTP, because when you get that many messages, your load average is going to increase to the point where it will start refusing connections. When your customers can't send mail, they tend to call, usually all at once.
I am skeptical about your spam signature scheme working (it's not as easy as you think), but don't let that discourage you from trying.
Re:An *EASY* and *OBVIOUS* solution to SPAM.
on
Austria Bans Spam
·
· Score: 1
If it's easy and obvious, where's the code? For your spam signature program, be prepared to deal with hashbusters in the subject and body. Also, such a system will not stop the transmission of spam, since all the spam signature can only be computed after the message is sent, so this does not alliviate the main problem of the spam eating up network bandwidth. In fact, testing will eat up more CPU bandwidth, and a distributed spam signature network will eat even more network bandwidth. Even if it worked and kept spam out of end-user mailboxes, it wouldn't solve the real problems.
Here's a tip for a real-time spam monitoring system (this would be implemented on the SMTP server): Track IP numbers, and see how many recipients/sec each host sends to. Real MTAs take the time to check the SMTP return codes. Some spam MTAs don't. As it so happens, the dial-up spammers send at a faster recipient rate than is normal. particularly if they start multiple simultaneous SMTP sessions. Those hosts can then be given special treatment. I leave that to your imagination.
Suffice it to say that this system does exist somewhere and is not hard at all to implement (at least with qmail; sendmail would be rough, due to the use of syslog), and it does a hilarous job of killing off spammers before they even get to send a DATA command, and it continues to stomp on them until they go away.
Telemarketers can call you collect, but since you can selectively refuse collect calls, it's not effective.
A better telco analogy would be a fly-by-night telemarketing service which orders a trunk of lines, calls half of North America, skips out on the bill, and repeats the process. The telco then raises everyone's rates to cover losses.
Spammers (and the fly-by-night telemarketers) shift costs to the guy in the middle, the one providing transport (ISPs on both ends or telco). Eventually all end-users pay indirectly with higher rates, even if they never personally get spam or fraudelent telemarketer calls.
I bet you never collected one cent either, because your computer is not a fax machine. People who spout off this 227(b)(1)(c) baloney are just as annoying as spammers, maybe more so. Criminal statutes are always narrowly interpreted, and you better be thankful of that. Think about it: If that really was true, why bother with the spammer's favorite friend, S.1618 from last year? If I had a buck for each time a spammer quoted that piece of crap to "prove" their spam was legal, I'd be retired.
I'm the double-bounce postmaster for over a thousand domains, so I get a lot of spam that bounces (because the recipient doesn't exist) and then bounces again (because the envelope sender is bogus). In the last month or so, the spammers have shifted heavily back to using multiple relays. I report these to ORBS and lately RRSS. We don't filter based on these lists, in the usual sense, but we do use them for "quality-of-service". I.e. the more lists you are on, the worse your service gets, and the more your queue backs up...
Once upon a time I would notify relay postmasters that their relays were open and that they should fix them. That became impractical, so now I'm taking another approach: If I get a double bounced spam that has come from a host listed on ORBS, RRSS, or IMRSS, I have a script that automagically sends it back to the relay's postmaster. This doesn't always work; some of those hosts don't have a postmaster address, or won't accept mail for their own IP. Most of the time it works. This tends to magically break language barriers and soon thereafter the relays seem to close up, or at least I stop getting spam from them.
So, if you have the bandwidth to pull this off, make your postmaster policy "return to sender": Send undeliverable spam back to the relay. And report open relays to one or more of the above lists. I report 30-70 relays a DAY, which probably makes it relatively expensive to spam us. Who are we? HA! Keep guessing, spammers...
Slashdot Mirror
I'll be so angry, there's no way I'll buy more than 500 shares.
But seriously, folks, RedHat is walking a very thin line here. I suspect would take the position that if you wrote code that ended up in RedHat, that would constitute a prior relationship. That's not a completely unreasonable position, either. Then again, there are a lot of anti-spam people out there are ARE completely unreasonable. I'm sure spammers love them, too, because they make tend to make all anti-spammer look stupid.
I just hope it's not something real stupid like those X10 spams I keep getting. Dammit, if I get something that reads like a porno spam, there damn well better be some naked chicks on their site!
Well, no quite enough for every particle in the universe. 2^128 is about 10^38 or so. A mole of atoms is 6.023e23 atoms, and a mole of carbon atoms (assuming C-12) has a mass of 12 grams. In molar units, there are about 5.6e14 moles of IP numbers in the IPv6 namespace. If IP numbers were carbon atoms, they'd weigh about 6.8e12 kg. That's only about 7000 metric tonnes. A mere drop in the ocean.
But it's a lot of friggin' addresses anyway.
Yes, Linux 2.2 has IPv6, but you have to enable it. You probably have to update some net tools as well. Check out the 6bone web site. 6bone is IPv6 tunnelled over IPv4. There's also a registry there for IP addresses, thought perhaps that'll be one the way out now.
Try Amanda. It uses dump or tar on UNIX, and I think there may be some clients for Windoze. Also look for BURT on Freshmeat. That one looked interesting, requires TCL.
Fine. E-mail is not a fax, even if his computer is a fax machine. You would be very hard pressed to find a judge to side with the position that junk e-mail is in violation of the junk fax law.
Sheesh. What's this supposed to mean?
If it were easy and obvious, it would have been done already.
For your spam signature program, be prepared to deal with hashbusters in the subject and body.
For each indidivual message?
Damn straight. There is at least one bulk mailing program which throws in a message counter (body and subject), a line of astericks, and varies the subject line. If you can find a reliable means of counteracting this, by all means, write it.
I don't think network bandwidth is the worst thing about SPAM. The time lost on the part of the end user who has to download the mail, read it, spend time working out it's not something they want, etc. is more of a problem.
It's been claimed that 10% of an ISP bill is to covering the costs of spamming. Unless you have to pay a metered rate, which is not too common in the US, the end-user part is not that big of a problem.
The real impact of spam is on the ISP mail server. Spam, by nature, tends to be spikey. One spammer, even with a modem, can deliver 50K messages in under an hour. These messages often have lots of bounces, and they have to be delivered, and usually those bounce. If you are running sendmail, you better hope you have a separate machine that just does your customer's SMTP, because when you get that many messages, your load average is going to increase to the point where it will start refusing connections. When your customers can't send mail, they tend to call, usually all at once.
I am skeptical about your spam signature scheme working (it's not as easy as you think), but don't let that discourage you from trying.
If it's easy and obvious, where's the code? For your spam signature program, be prepared to deal with hashbusters in the subject and body. Also, such a system will not stop the transmission of spam, since all the spam signature can only be computed after the message is sent, so this does not alliviate the main problem of the spam eating up network bandwidth. In fact, testing will eat up more CPU bandwidth, and a distributed spam signature network will eat even more network bandwidth. Even if it worked and kept spam out of end-user mailboxes, it wouldn't solve the real problems.
Here's a tip for a real-time spam monitoring system (this would be implemented on the SMTP server): Track IP numbers, and see how many recipients/sec each host sends to. Real MTAs take the time to check the SMTP return codes. Some spam MTAs don't. As it so happens, the dial-up spammers send at a faster recipient rate than is normal. particularly if they start multiple simultaneous SMTP sessions. Those hosts can then be given special treatment. I leave that to your imagination.
Suffice it to say that this system does exist somewhere and is not hard at all to implement (at least with qmail; sendmail would be rough, due to the use of syslog), and it does a hilarous job of killing off spammers before they even get to send a DATA command, and it continues to stomp on them until they go away.
Telemarketers can call you collect, but since you can selectively refuse collect calls, it's not effective.
A better telco analogy would be a fly-by-night telemarketing service which orders a trunk of lines, calls half of North America, skips out on the bill, and repeats the process. The telco then raises everyone's rates to cover losses.
Spammers (and the fly-by-night telemarketers) shift costs to the guy in the middle, the one providing transport (ISPs on both ends or telco). Eventually all end-users pay indirectly with higher rates, even if they never personally get spam or fraudelent telemarketer calls.
I bet you never collected one cent either, because your computer is not a fax machine. People who spout off this 227(b)(1)(c) baloney are just as annoying as spammers, maybe more so. Criminal statutes are always narrowly interpreted, and you better be thankful of that. Think about it: If that really was true, why bother with the spammer's favorite friend, S.1618 from last year? If I had a buck for each time a spammer quoted that piece of crap to "prove" their spam was legal, I'd be retired.
Once upon a time I would notify relay postmasters that their relays were open and that they should fix them. That became impractical, so now I'm taking another approach: If I get a double bounced spam that has come from a host listed on ORBS, RRSS, or IMRSS, I have a script that automagically sends it back to the relay's postmaster. This doesn't always work; some of those hosts don't have a postmaster address, or won't accept mail for their own IP. Most of the time it works. This tends to magically break language barriers and soon thereafter the relays seem to close up, or at least I stop getting spam from them.
So, if you have the bandwidth to pull this off, make your postmaster policy "return to sender": Send undeliverable spam back to the relay. And report open relays to one or more of the above lists. I report 30-70 relays a DAY, which probably makes it relatively expensive to spam us. Who are we? HA! Keep guessing, spammers...