so then you are doing this when the MTA on the clients machine or the server receives it which bounces it back and asks for the user to verify that they are human?
I take it this test would be automated?
What about mailing lists, automated password mailouts (used by places like slashdot when registering or users have lost passwords)?
Then there is also the fact that the spam will bounce (most often) to a non valid adress, or one which actually exists but is not of the spammers.
and re the kid not being free; I had a couple of spare hours so I wrote a small app which simulates mass mailouts, and the addresses mta would send back an authentication (another email which you reply with the word in the email as the subject), with a well designed app, I could do (on average) 12 a minute, and a know tonnes of kids (not necisarily of _legal_ age to work, who's parents and who themselves would be happy to work for $5 an hour (AUD). All my app did was with every incoming mail (an auth email) it would automaticaly display it in a 2 pain window with the bottom being the message body, and the top being the reply. When that window closed (sending) another would be behind it for authentication etc) As the questions would be simple, they would take less time to write the answers than copying the text.
And finaly, one point I did not make: I think that authing people would be the death of email - people like the fact they can click the send button and go onto the next email - if they have to undertake some form of authentication then they will just not bother.
true - which end are you relying on the authentication to be done by. If it is by the receiving end then you run into language barriers, problems with understanding etc, if it is sending end then the spammer will use their own server without authentication.. These tests also need to be written. If you make a standard set then the spammers will obtain these and write applications which recognise them, if you rely on ISP's/server admins then many will not bother or will use simple charactor strings.
The second you do that, the writters of mass mailers will set their systems up to use OCR to sus out the key. Then there is also the fact that with the reduction in automated spam, companies will probably start hireing kids for a couple of dollars an hour to send emails for them... and the fact that SMTP servers used by spammers are usually run by the spammers themselves (so as to allow mucking up of the headers etc).
Then there is also another problem - of POP, IMAP and SMTP, only SMTP is standard. Should you modify SMTP's protocol you are guaranteed it's uptake will be almost as slow as the uptake of IMAP over POP. IMAP is a technicaly better protocol, POP is simple and easy and widely used. POP and IMAP have nothing to do with the sending however, so as long as you have a client and server which can deal with the prefered protocol you are fine, however SMTP and NSMTP (New Send Mail Transfer Protocol) will most likely be totaly incompatable - so SMTP would be able to talk to SMTP enabled servers, and NSMTP to NSMTP enabled servers, but should someone send using SMTP to an NSMTP enabled server, well you get the picture.
Slashdot Mirror
so then you are doing this when the MTA on the clients machine or the server receives it which bounces it back and asks for the user to verify that they are human?
I take it this test would be automated?
What about mailing lists, automated password mailouts (used by places like slashdot when registering or users have lost passwords)?
Then there is also the fact that the spam will bounce (most often) to a non valid adress, or one which actually exists but is not of the spammers.
and re the kid not being free; I had a couple of spare hours so I wrote a small app which simulates mass mailouts, and the addresses mta would send back an authentication (another email which you reply with the word in the email as the subject), with a well designed app, I could do (on average) 12 a minute, and a know tonnes of kids (not necisarily of _legal_ age to work, who's parents and who themselves would be happy to work for $5 an hour (AUD). All my app did was with every incoming mail (an auth email) it would automaticaly display it in a 2 pain window with the bottom being the message body, and the top being the reply. When that window closed (sending) another would be behind it for authentication etc) As the questions would be simple, they would take less time to write the answers than copying the text.
And finaly, one point I did not make: I think that authing people would be the death of email - people like the fact they can click the send button and go onto the next email - if they have to undertake some form of authentication then they will just not bother.
true - which end are you relying on the authentication to be done by. If it is by the receiving end then you run into language barriers, problems with understanding etc, if it is sending end then the spammer will use their own server without authentication.. These tests also need to be written. If you make a standard set then the spammers will obtain these and write applications which recognise them, if you rely on ISP's/server admins then many will not bother or will use simple charactor strings.
The second you do that, the writters of mass mailers will set their systems up to use OCR to sus out the key. Then there is also the fact that with the reduction in automated spam, companies will probably start hireing kids for a couple of dollars an hour to send emails for them... and the fact that SMTP servers used by spammers are usually run by the spammers themselves (so as to allow mucking up of the headers etc).
Then there is also another problem - of POP, IMAP and SMTP, only SMTP is standard. Should you modify SMTP's protocol you are guaranteed it's uptake will be almost as slow as the uptake of IMAP over POP. IMAP is a technicaly better protocol, POP is simple and easy and widely used. POP and IMAP have nothing to do with the sending however, so as long as you have a client and server which can deal with the prefered protocol you are fine, however SMTP and NSMTP (New Send Mail Transfer Protocol) will most likely be totaly incompatable - so SMTP would be able to talk to SMTP enabled servers, and NSMTP to NSMTP enabled servers, but should someone send using SMTP to an NSMTP enabled server, well you get the picture.