As a professional sender of spam, I just want to tell you slashdotters to keep on playing with your spam filters. As long as you use spam filters on your e-mail, I can continue to reach my real intended targets, those non-slashdotters who do not know better and will buy my products or click through to my client's websites.
Complete BS.
Geeks are ones that set up the spam filters for everyone else. End users will no more have to install spam filters than they have to install DNS entries, multi-peered lines ot the backbone, etc. (In fact, the problem is that often ISPs don't tell you they are filter, or give you the chance to turn it off.)
Your filters really help cut down on the complaints to the Internet service providers I do business with, and as long as not too many complaints come in their marketing people assure me we can do business.
Sorry, but my delete key is tied to your ISP's abuse box.
Ok, I actually have a separate "this is spam" key that send the spam off to spamcop. I also use the following procmail script to report anything that scores too high on spamassassin:
The spam_report script is very simple, it just encodes the spam and sends it off to spamcop. It can be found on http://spamcop.net/reporter.pl. I modify the number of stars (spamassassin score) depending on how much time I have on my hand right now. If too many reports get sent to spamcop for me to deal with, I increase the number of stars, when a spammer pisses me off, I decrease the score.
Even a small number of vindictive anit-spammers reporting spam will get the spammer's IP address onto spamcop's DNSBL, which feeds back into things like spamassassin.
The amount of spam that reaches my inbox in the last 6 months has been far lower than any time since the mid 1990s. Even with the reporting to spamcop, I'm spending less time dealing with spam now that two or three years ago. Over the last year or so, I've come to believe that Spammer's days are numbered.
Oh, one final note. The original article complained about the fact that spamassassin mine-defangs the spam and then says that it is hard to get the original email back. This isn't true at all. On older versions, you just run it through "spamassassin -d". While you can still do that with newer versions (as per my scripts above), they now create an attachment so you can just click on it if you want to see it.
if you have a C/R system set up and I have a C/R system set up, then
when I email you for the first time and you send a challenge to me, will
my system then send a challenge back to you?
With the "bounce" challenge-response system that I use, no it wouldn't. Bounces create a null return-path, thus preventing double bounces. Other challenge-response systems are not so well designed.
There are several such authentication systems out there that have been around for years, have been formalized via RFCs, have been implemented in the MTAs and MUAs and are mostly unused.
Do a google search on terms such as "SASL", "SMTP AUTH", "GPG", "SMTP TLS", etc.
Before you get your hopes up that "the spam problem could be largely mitigated by altering the SMTP protocal to include cryptographic signatures", you should do some investigation about previous systems that have failed to largely mitigate spam.
I like Challenge/response systems and have recently increased my use of them.
The one I use works like this: During the SMTP session when the email is attempting to be transfered, I run SpamAssassin from exim (my MTA). If the score is high enough, I send an SMTP 5xx rejection code. This causes the sending MTA to generate a challenge message. Because it is the sending MTA that creates this message, it is usually not fooled by forged From: addresses. More over, even if the sending MTA is fooled by a forged From: address, it is likely that the sender is on a blacklist and the domain of the forged sender can deal with it correctly.
Since this challenge is only generated when the email is almost certainly spam, most people will never see it. Most spamware will not be able to deal with the 5xx rejection code and therefore will not generate a challenge message to anyone.
Also, since this challenge message is created by the sender's MTA, it will more likely be in the correct language.
This challenge message, created by the sender's MTA, must be correctly interpreted and the correct action must be taken. This almost always requires a real human to do and moreover, it requires a cluefull human. It works very, very well.
I call this kind of challenge-response system a "bounce".
Gore most definately did not win a "majority" of the recounts. In fact, he only won under one scenario, and that was if they counted every single "overvote" that included Gore as a vote for Gore.
Your recollection of what was said in that article differed quite a bit from what I remmebered, but it has been a couple of years so I re-read it.
What you say is simply not true. Gore would have won under several scenarios, and the "overcount" scenario is to count cases where people both voted for a candidate and also wrote in their name. While I can understand this being counted as an overvote, it seems pretty clear to me what the intent of the voter was.
Well, I signed up only two hours after it was open, and I still haven't gotten my confirmation emails.
Apparently, there are also problems if you try to use email addresses with "funny" characters, like +, % or &. (All of these are perfectly valid and useful characters, but they are rejected anyway.)
Moderated Funny? This is informative!
on
42-Volt Autos
·
· Score: 1
To create 36v out of 3 12v batteries, you just run them in serial. yeah, you need three jumper cables too, so instead of carrying one spare you might want to carry three.
Heck, a 12v battery is made out of a bunch of 1.5v cells anyway. (That's what a "battery" is, a group of cells.)
A challenge-response system is one where the mail system sends a "challenge" to the sender of an email that makes the sender prove that they are human.
In case anyone hasn't noticed, this is basically what a "bounce" message does. The challenge of figuring out what caused the bounce and how to get around it not only makes you prove that you are human, but that you can think. Bounces caused by DNSBLs make prove that you know how to send email from some place that doesn't send spam or have an open relay/proxy.
The statement that Ipsos asked people if they agree with is "Downloading free music off the Internet is wrong". Only 9% sgrongly or somewhat agreed.
There is a difference between what is illegal and what people believe is wrong. Before the civil war, it was illegal to help a run-away slave, even if you were in the North. Many people worked on the "Underground railroad" anyway and didn't think it was "wrong" to help slaves.
Now a days, the whole concept that you could "own" a person seems pretty strange. But then, some people today also think that the whole concept that you could "own" an idea is pretty strange.
If "temporary delivery failure" was an end-to-end message, that would be effective. But it only goes back one hop. So open relays will resend their queued spam.
Yes, using a tempfail for first time email is not a perfect solution, but it does help. In particular, making an open relay queue lots of spam will make the open relay's problem much more noticable to them.
Worse, the spammers who send their messages multiple times will still get through.
You shouldn't really tempfail the "first" time you see a sender-recipient pair, you should consider any pair that you have seen "recently" (weeks? months?) to be effectively a "first time". You should also tempfail any emails from a "new" pair for the first hour or two.
This will give you an hour or two warning about potential spam, giving spamtraps and blacklists a chance to kick in.
Remember, any email from a working mail server will still get through, it is just the first time there will be a slight delay.
Summary of IETF ASRG discussions
on
IETF to Look at Spam
·
· Score: 5, Informative
Four days ago when this was mentioned on slashdot, I posted the following summary of what had been discussed. Sadly, this summary is still pretty complete.
From what I take from all this discussion is that the only "solution" to spam is to do the types of things that we have been doing for years, but to do more of it and quicker. Use well run DNS blacklists (Spamhaus SBL, ordb, dsbl, etc.), use good content filters (bayesian filters, etc.), use bulk mail detectors such as DCC or vipul's razor, etc.) and per-user whitelists and blacklists.
Or, combine all of the above techniques by using SpamAssassin
--
I've been subscribed to the list since near the beginning and have been following it fairly closely. Much of the discussion has been rehashes of old topics such as "what exactly is spam?", "make the sender pay something, either money or CPU", etc.
The most interesting discussions that I've seen so far are:
Mail transfer programs (MTA) such as sendmail, exim, qmail, etc., should keep track of sender-recipient pairs. The first time the sender-recipient pair shows up, sendmail (or whatever) should issue a "temporary delivery failure". This will force the sending mail transfer program to queue the mail and resend it later. This is completely backwards compatible and doesn't require end users to do anything.
Most spam specific programs will not queue and retry, and thus the spam will be dropped.
Spammers that use real mail transfer programs or open relays will need to be able to hold all their outgoing spam for a while, increasing the spammer's costs and slowing down the delivery of spam. Legitimate email will not be thrown out, it will only be delayed and only for the first time.
Of course, you don't really want the databases to remember every sender-recipient pair forever, nor do you want to remember pairs that were added by spam so this really isn't a "first time" database, but it is close.
Apparently the "canit" program already does this, but I had not heard of this technique before.
Spam filtering really needs to be done while the email is being received. Sendmail can already do this with the milter filter, but other MTAs should also. Most mail servers are I/O bound, not CPU bound so this really isn't much of a burden on the server.
If you filter during the email receive process, you can make the sending MTA do the bounce. This means that you will not have to deal with spammers forging "from" and "reply-to" headers. You won't have to clean up bounces that never succeed, nor will you be responsible for bouncing spam to another victim that the spammer selected for the "from" or "reply-to" headers.
Also, false positives will recieve a bounce message instead of just disappearing. This reduces the danger of important email being lost.
There are also several proposals to deal with ways of verifying that email being sent from a given IP address and claiming to be from a certain domain is actually authorized to send email claiming it is from that domain.
Right now, there are DNS records that tell you which IP addresses are valid to try and send email to for a given domain (the MX records), but many ISPs have different machines for sending and recieving email. There are currently no DNS records to tell you which tell you which IP addresses a domain will send email from.
The problem with this kind of proposal is that there are many people who think they have legitimate reasons to forge "from" or "reply-to" addresses. It also forces ISPs to make sure that every time they add a new outgoing mail server, they need to update the list of valid IP addresses. If they forget to do this, then only bleeding edge spam filters will detect a problem.
Most IETF work is done on mailing lists
on
Cornucopia of Spam
·
· Score: 2, Informative
The meetings are really just get togethers and a chance to hold more formal proceedings. Most of the real work has always been done via mailing lists and such.
Even if no one buys anything from a spammer....
on
Cornucopia of Spam
·
· Score: 1
Spam will not disappear even if every stops buy from spammers.
First, there are religous and political spam that isn't at all related to monitary gain.
Secondly, many spammers make their money off of people paying them to spam rather than directly from the sales. As long as there are people who think that since there is so much spam, people must be making money off it and therefore are willing to pay a spammer to try for a while, there will be spam. Many businesses will start spamming when times are really bad for them and they think "hey, it only costs $500 to pay the spammer, and it might save my business!".
Thirdly, there appears to be "spam" which is really just a DOS attack.
Forth, you can use "forged" spam to tarnish your competitor or political opponent.
Fifth, you can spam and claim that the spam was "forged" by a competitor and/or political opponent in order to tarnish you.
Summary of IETF ASRG discussions
on
Cornucopia of Spam
·
· Score: 4, Informative
I've been subscribed to the list since near the beginning and have been following it fairly closely. Much of the discussion has been rehashes of old topics such as "what exactly is spam?", "make the sender pay something, either money or CPU", etc.
The most interesting discussions that I've seen so far are:
Mail transfer programs (MTA) such as sendmail, exim, qmail, etc., should keep track of sender-recipient pairs. The first time the sender-recipient pair shows up, sendmail (or whatever) should issue a "temporary delivery failure". This will force the sending mail transfer program to queue the mail and resend it later.
Most spam specific programs will not queue and retry, and thus the spam will be dropped.
Spammers that use real mail transfer programs or open relays will need to be able to hold all their outgoing spam for a while, increasing the spammer's costs and slowing down the delivery of spam.
Legitimate email will not be thrown out, it will only be delayed and only for the first time.
Of course, you don't really want the databases to remember every sender-recipient pair forever, nor do you want to remember pairs that were added by spam so this really isn't a "first time" database, but it is close.
Apparently the "canit" program already does this, but I had not heard of this technique before.
Spam filtering really needs to be done while the email is being received. Sendmail can already do this with the milter filter, but other MTAs should also. Most mail servers are I/O bound, not CPU bound so this really isn't much of a burden on the server. This is completely backwards compatible and doesn't require end users to do anything.
If you filter during the email receive process, you can make the sending MTA do the bounce. This means that you will not have to deal with spammers forging "from" and "reply-to" headers. You won't have to clean up bounces that never succeed, nor will you be responsible for bouncing spam to another victim that the spammer selected for the "from" or "reply-to" headers.
Also, false positives will recieve a bounce message instead of just disappearing. This reduces the danger of important email being lost.
There are also several proposals to deal with ways of verifying that email being sent from a given IP address and claiming to be from a certain domain is actually authorized to send email claiming it is from that domain.
Right now, there are DNS records that tell you which IP addresses are valid to try and send email to for a given domain (the MX records), but many ISPs have different machines for sending and recieving email. There are currently no DNS records to tell you which tell you which IP addresses a domain will send email from.
The problem with this kind of proposal is that there are many people who think they have legitimate reasons to forge "from" or "reply-to" addresses. It also forces ISPs to make sure that every time they add a new outgoing mail server, they need to update the list of valid IP addresses. If they forget to do this, then only bleeding edge spam filters will detect a problem.
While the moderators seem to think this is a "funny" idea, I personally kind of like it. Only, I would recommend creating increasingly long delays in the response or to increase the number of dropped requests. You want that sysadmin who pulls his head out of his ass to at least be able to download fixes and such.
The GPL requires people/companies that distrubute software under the GPL and hold patents for that software to grant royalty free use of those patents for everyone. Since SCO distributes a version of Linux, all code their distribution must be free of any problems with their patents.
There is no way for a subscriber to know what IP address our e-mails will come from, they change dynamically based on load.
The same basic solutions to letting your customers know what public key(s) you use can be used to let your customers know what IP addresses you use.
While most DNS based systems are blacklists, there are DNS based whitelists such as Bonded Sender. The current version of spamassassin recognizes them.
The IP address is an identity and the IP sequence numbers prevent the identity from being spoofed/forged. Authentication based on the IP address is not the ultimate solution, but it has the advantage that it is already in use.
I believe that the way to stop spam in the long term is to deploy signed email ubiquitously. Self signed certificates are sufficient for this purpose if we can provide a lightweight authentication via a DNS-linked PKI.
SMTP already has a good way of authenticating who you are receiving email from. It is called the IP address of the machine that is contacting you and the IP sequence numbers of the packets that have to travel between you. All you need is a list of the IP addresses of the people who you want to receive email from and a list of ones you don't.
But, of course, this is what the current blacklists do!
Any email authentication system is going to run into most, if not all, of the same problems that DNSBLs run into. They are also going to have the problem of trying to get the entire world to change.
Any measure for stopping spam must ensure that all non-spam messages reach their intended recipients.
This sounds so nobel, but there isn't any system out there that won't have ANY false positives. Some false positives are just more obvious than others.
For example, the common technique of not letting your email address out in the public means that people who you would like receive email from (and vice versa) will often never happen because you don't know how to contact each other. Sure, this doesn't generate a bounce, or an error message, but it still means that this "solution" to the spam problem has interfered with legitimate email.
If you switch email addresses when old email addresses get too spammy, you will lose email from people who don't know about your new email address.
If you obscure your email address to try to prevent bots from collecting your address will also prevent some people from figuring out how to email you. The same goes to email responders that require the sender to prove they are human before the email gets through.
Blacklists are judging everything based off an IP address and that can't possibly have no false positives.
Filters will trigger on keywords when the keywords aren't used in a spammy way.
I propose a different goal: People should be allowed to deal with spam any (legal) way they want. They can choose the method(s) that create an acceptable level of false positives for them. If you can't send email to them because they have made a choice, DON'T WHINE ABOUT IT.
I personally use spamassassin with modified DNSBL checks and RAZOR enabled. I have used DNSBLs before the block all email, but decided that created too many false positives for me, but I respect the choices of other people.
Convservatives think that women who have sex outside a monogamous unbreakable marriage are bad. Homosexual sex is evil. (Women involved in a three-way or are performaning for men don't really count as homosexuals.)
When AOL was sued over this, there were a lot of similar comments about it not being worth it to help the blind use the Internet, or "let the market decide", etc.
In response, Curtis Chung, Director of Technology for the National Federation of the Blind, was asked a bunch of questions by/. readers and I was very impressed with his answers. I went from being somewhat skeptical (but not hostile), to realizing that a great deal of what I want to see in website design is the same things that blind people need. Cut out the flash. Add ALT tags to your images. Stop using images to send text. Keep navigation simple. Concentrate on content.
I was talking to someone (I forget who) about webpages that disappeared and how much information was lost that way. He mentioned that he had modified a caching proxy so that ever read off the web would be saved forever. At first I thought that would burn up way to much disk space, but after thinking about it, with the price of disks today, it really is a fairly reasonable approach.
Slashdot Mirror
Complete BS.
Geeks are ones that set up the spam filters for everyone else. End users will no more have to install spam filters than they have to install DNS entries, multi-peered lines ot the backbone, etc. (In fact, the problem is that often ISPs don't tell you they are filter, or give you the chance to turn it off.)
Your filters really help cut down on the complaints to the Internet service providers I do business with, and as long as not too many complaints come in their marketing people assure me we can do business.
Sorry, but my delete key is tied to your ISP's abuse box.
Ok, I actually have a separate "this is spam" key that send the spam off to spamcop. I also use the following procmail script to report anything that scores too high on spamassassin:
The spam_report script is very simple, it just encodes the spam and sends it off to spamcop. It can be found on http://spamcop.net/reporter.pl. I modify the number of stars (spamassassin score) depending on how much time I have on my hand right now. If too many reports get sent to spamcop for me to deal with, I increase the number of stars, when a spammer pisses me off, I decrease the score.Even a small number of vindictive anit-spammers reporting spam will get the spammer's IP address onto spamcop's DNSBL, which feeds back into things like spamassassin.
The amount of spam that reaches my inbox in the last 6 months has been far lower than any time since the mid 1990s. Even with the reporting to spamcop, I'm spending less time dealing with spam now that two or three years ago. Over the last year or so, I've come to believe that Spammer's days are numbered.
Oh, one final note. The original article complained about the fact that spamassassin mine-defangs the spam and then says that it is hard to get the original email back. This isn't true at all. On older versions, you just run it through "spamassassin -d". While you can still do that with newer versions (as per my scripts above), they now create an attachment so you can just click on it if you want to see it.
With the "bounce" challenge-response system that I use, no it wouldn't. Bounces create a null return-path, thus preventing double bounces. Other challenge-response systems are not so well designed.
Do a google search on terms such as "SASL", "SMTP AUTH", "GPG", "SMTP TLS", etc.
Before you get your hopes up that "the spam problem could be largely mitigated by altering the SMTP protocal to include cryptographic signatures", you should do some investigation about previous systems that have failed to largely mitigate spam.
The one I use works like this: During the SMTP session when the email is attempting to be transfered, I run SpamAssassin from exim (my MTA). If the score is high enough, I send an SMTP 5xx rejection code. This causes the sending MTA to generate a challenge message. Because it is the sending MTA that creates this message, it is usually not fooled by forged From: addresses. More over, even if the sending MTA is fooled by a forged From: address, it is likely that the sender is on a blacklist and the domain of the forged sender can deal with it correctly.
Since this challenge is only generated when the email is almost certainly spam, most people will never see it. Most spamware will not be able to deal with the 5xx rejection code and therefore will not generate a challenge message to anyone.
Also, since this challenge message is created by the sender's MTA, it will more likely be in the correct language.
This challenge message, created by the sender's MTA, must be correctly interpreted and the correct action must be taken. This almost always requires a real human to do and moreover, it requires a cluefull human. It works very, very well.
I call this kind of challenge-response system a "bounce".
Gore most definately did not win a "majority" of the recounts. In fact, he only won under one scenario, and that was if they counted every single "overvote" that included Gore as a vote for Gore.
Your recollection of what was said in that article differed quite a bit from what I remmebered, but it has been a couple of years so I re-read it.
What you say is simply not true. Gore would have won under several scenarios, and the "overcount" scenario is to count cases where people both voted for a candidate and also wrote in their name. While I can understand this being counted as an overvote, it seems pretty clear to me what the intent of the voter was.
Go RTFA.
Apparently, there are also problems if you try to use email addresses with "funny" characters, like +, % or &. (All of these are perfectly valid and useful characters, but they are rejected anyway.)
Heck, a 12v battery is made out of a bunch of 1.5v cells anyway. (That's what a "battery" is, a group of cells.)
Actually, it would be neither blackmail nor extortion, it would be an out of court settlement.
In case anyone hasn't noticed, this is basically what a "bounce" message does. The challenge of figuring out what caused the bounce and how to get around it not only makes you prove that you are human, but that you can think. Bounces caused by DNSBLs make prove that you know how to send email from some place that doesn't send spam or have an open relay/proxy.
There is a difference between what is illegal and what people believe is wrong. Before the civil war, it was illegal to help a run-away slave, even if you were in the North. Many people worked on the "Underground railroad" anyway and didn't think it was "wrong" to help slaves.
Now a days, the whole concept that you could "own" a person seems pretty strange. But then, some people today also think that the whole concept that you could "own" an idea is pretty strange.
Yes, using a tempfail for first time email is not a perfect solution, but it does help. In particular, making an open relay queue lots of spam will make the open relay's problem much more noticable to them.
Worse, the spammers who send their messages multiple times will still get through.
You shouldn't really tempfail the "first" time you see a sender-recipient pair, you should consider any pair that you have seen "recently" (weeks? months?) to be effectively a "first time". You should also tempfail any emails from a "new" pair for the first hour or two.
This will give you an hour or two warning about potential spam, giving spamtraps and blacklists a chance to kick in.
Remember, any email from a working mail server will still get through, it is just the first time there will be a slight delay.
From what I take from all this discussion is that the only "solution" to spam is to do the types of things that we have been doing for years, but to do more of it and quicker. Use well run DNS blacklists (Spamhaus SBL, ordb, dsbl, etc.), use good content filters (bayesian filters, etc.), use bulk mail detectors such as DCC or vipul's razor, etc.) and per-user whitelists and blacklists.
Or, combine all of the above techniques by using SpamAssassin
--
I've been subscribed to the list since near the beginning and have been following it fairly closely. Much of the discussion has been rehashes of old topics such as "what exactly is spam?", "make the sender pay something, either money or CPU", etc.
The most interesting discussions that I've seen so far are:
Most spam specific programs will not queue and retry, and thus the spam will be dropped.
Spammers that use real mail transfer programs or open relays will need to be able to hold all their outgoing spam for a while, increasing the spammer's costs and slowing down the delivery of spam. Legitimate email will not be thrown out, it will only be delayed and only for the first time.
Of course, you don't really want the databases to remember every sender-recipient pair forever, nor do you want to remember pairs that were added by spam so this really isn't a "first time" database, but it is close.
Apparently the "canit" program already does this, but I had not heard of this technique before.
If you filter during the email receive process, you can make the sending MTA do the bounce. This means that you will not have to deal with spammers forging "from" and "reply-to" headers. You won't have to clean up bounces that never succeed, nor will you be responsible for bouncing spam to another victim that the spammer selected for the "from" or "reply-to" headers.
Also, false positives will recieve a bounce message instead of just disappearing. This reduces the danger of important email being lost.
Right now, there are DNS records that tell you which IP addresses are valid to try and send email to for a given domain (the MX records), but many ISPs have different machines for sending and recieving email. There are currently no DNS records to tell you which tell you which IP addresses a domain will send email from.
The problem with this kind of proposal is that there are many people who think they have legitimate reasons to forge "from" or "reply-to" addresses. It also forces ISPs to make sure that every time they add a new outgoing mail server, they need to update the list of valid IP addresses. If they forget to do this, then only bleeding edge spam filters will detect a problem.
The meetings are really just get togethers and a chance to hold more formal proceedings. Most of the real work has always been done via mailing lists and such.
First, there are religous and political spam that isn't at all related to monitary gain.
Secondly, many spammers make their money off of people paying them to spam rather than directly from the sales. As long as there are people who think that since there is so much spam, people must be making money off it and therefore are willing to pay a spammer to try for a while, there will be spam. Many businesses will start spamming when times are really bad for them and they think "hey, it only costs $500 to pay the spammer, and it might save my business!".
Thirdly, there appears to be "spam" which is really just a DOS attack.
Forth, you can use "forged" spam to tarnish your competitor or political opponent.
Fifth, you can spam and claim that the spam was "forged" by a competitor and/or political opponent in order to tarnish you.
The most interesting discussions that I've seen so far are:
Most spam specific programs will not queue and retry, and thus the spam will be dropped.
Spammers that use real mail transfer programs or open relays will need to be able to hold all their outgoing spam for a while, increasing the spammer's costs and slowing down the delivery of spam. Legitimate email will not be thrown out, it will only be delayed and only for the first time.
Of course, you don't really want the databases to remember every sender-recipient pair forever, nor do you want to remember pairs that were added by spam so this really isn't a "first time" database, but it is close.
Apparently the "canit" program already does this, but I had not heard of this technique before.
If you filter during the email receive process, you can make the sending MTA do the bounce. This means that you will not have to deal with spammers forging "from" and "reply-to" headers. You won't have to clean up bounces that never succeed, nor will you be responsible for bouncing spam to another victim that the spammer selected for the "from" or "reply-to" headers.
Also, false positives will recieve a bounce message instead of just disappearing. This reduces the danger of important email being lost.
Right now, there are DNS records that tell you which IP addresses are valid to try and send email to for a given domain (the MX records), but many ISPs have different machines for sending and recieving email. There are currently no DNS records to tell you which tell you which IP addresses a domain will send email from.
The problem with this kind of proposal is that there are many people who think they have legitimate reasons to forge "from" or "reply-to" addresses. It also forces ISPs to make sure that every time they add a new outgoing mail server, they need to update the list of valid IP addresses. If they forget to do this, then only bleeding edge spam filters will detect a problem.
While the moderators seem to think this is a "funny" idea, I personally kind of like it. Only, I would recommend creating increasingly long delays in the response or to increase the number of dropped requests. You want that sysadmin who pulls his head out of his ass to at least be able to download fixes and such.
The GPL requires people/companies that distrubute software under the GPL and hold patents for that software to grant royalty free use of those patents for everyone. Since SCO distributes a version of Linux, all code their distribution must be free of any problems with their patents.
The same basic solutions to letting your customers know what public key(s) you use can be used to let your customers know what IP addresses you use.
While most DNS based systems are blacklists, there are DNS based whitelists such as Bonded Sender. The current version of spamassassin recognizes them.
The IP address is an identity and the IP sequence numbers prevent the identity from being spoofed/forged. Authentication based on the IP address is not the ultimate solution, but it has the advantage that it is already in use.
SMTP already has a good way of authenticating who you are receiving email from. It is called the IP address of the machine that is contacting you and the IP sequence numbers of the packets that have to travel between you. All you need is a list of the IP addresses of the people who you want to receive email from and a list of ones you don't.
But, of course, this is what the current blacklists do!
Any email authentication system is going to run into most, if not all, of the same problems that DNSBLs run into. They are also going to have the problem of trying to get the entire world to change.
This sounds so nobel, but there isn't any system out there that won't have ANY false positives. Some false positives are just more obvious than others.
For example, the common technique of not letting your email address out in the public means that people who you would like receive email from (and vice versa) will often never happen because you don't know how to contact each other. Sure, this doesn't generate a bounce, or an error message, but it still means that this "solution" to the spam problem has interfered with legitimate email.
If you switch email addresses when old email addresses get too spammy, you will lose email from people who don't know about your new email address.
If you obscure your email address to try to prevent bots from collecting your address will also prevent some people from figuring out how to email you. The same goes to email responders that require the sender to prove they are human before the email gets through.
Blacklists are judging everything based off an IP address and that can't possibly have no false positives.
Filters will trigger on keywords when the keywords aren't used in a spammy way.
I propose a different goal: People should be allowed to deal with spam any (legal) way they want. They can choose the method(s) that create an acceptable level of false positives for them. If you can't send email to them because they have made a choice, DON'T WHINE ABOUT IT.
I personally use spamassassin with modified DNSBL checks and RAZOR enabled. I have used DNSBLs before the block all email, but decided that created too many false positives for me, but I respect the choices of other people.
No, no, no!
Convservatives think that women who have sex outside a monogamous unbreakable marriage are bad. Homosexual sex is evil. (Women involved in a three-way or are performaning for men don't really count as homosexuals.)
And, in chapter four, the show this image which has the correct scaling. Guess what. It looks exponential to me.
In response, Curtis Chung, Director of Technology for the National Federation of the Blind, was asked a bunch of questions by /. readers and I was very impressed with his answers. I went from being somewhat skeptical (but not hostile), to realizing that a great deal of what I want to see in website design is the same things that blind people need. Cut out the flash. Add ALT tags to your images. Stop using images to send text. Keep navigation simple. Concentrate on content.
See Interview: Answers About Blind Computer Use
I sure wish robots.txt allowed wildcards or regular expressions.
I may have to start doing that too.