Chacham's Journal: Verbiage: On email: Spam and the approach (2)

I just checked my email, and received about 140 spams in two days. That is alot. Spam is annoying, but the filtration is worse, as i may miss something. I do have my own email server now, now to throw in a flexible IMAP server, and put Squirrelmail to use.

I was thinking about two ideas with spam. One is a challenge response. This helps in two aspects. One, it slows down sending time, and two, if the challenge is made more non-computer figureoutable, it should help, though lists would have to be approved.

Such as the challenge "how many letters are in this sentence?". A human would have to understand the question, at least for now, so a computer would not be able to respond to the challenge. The cons to this approach are many. For one, it is annoying for humans to do such work to make the response. Two, the questions would probably need to be rotated, making more work. Three, getting lists on everyone's white list would be quite a bit of work. Four, responding to large quantities of email (such as tech support) would make this untenable. Plus, the approach seems incorrect.The doesn't address the issue, it just adds barriers.

The other idea was pulling email, as opposed to the current pushing. Perhaps, instead of sending email, the sender only sends a token, mentioning where the email actually resides, then the receiver would have to pull the email. The advantages are many. The single point of failure as with a company's single email server is less important as it does not house the bodies. Spammers would have to have a real ip address that is availible for the entire time people are expected to read it (and if there was an incubation period a pre-screening crew could warn of the trash, similar to how usenet is better for downloads than ptp). Currently, POP3 and IMAP servers are completely open, and spam is dealt with afterwards. This way, they would be completely closed (unless whitelisted, which wouldn't be required except for very large lists). This would ultimately save on bandwith, and the non-read spam is never sent. The main con is that the sender can tell if and when the reader reads the email. Though, this can also be a pro, as if an email is mistakenly marked as spam, the sender can resend. I'd actually like that. It would remove the problem of deletion of valid emails when they were mistakenly deleted, for whatever the reason. Another con is the requirement for a place to send the email. But, i think enough ISPs have SMTP servers availbile.

smart programmers.

[capoccia]

If you write a challenge like, "how many letters are in this sentence?", and that is the only type of question, it will be very easy to create a program that will be able to respond with the correct answer.

It just needs to follow these steps:

1. Locate the beginning and end of the sentence in question
2. Remove all whitespace, punctuation and end-line characters
3. Count the characters

Even if you add questions, spammers will write bots that will respond. The only way this could work is if everyone created their

Re:smart programmers.

[Chacham]

I believe in discussing ideas before applying them to reality. Otherwise, unecessary and self-destructive compromises are likely to be made.

"Pulling" email

[Cyberdyne]

This [cr.yp.to] is Dan Bernstein's approach. One nasty flaw he doesn't seem to have addressed is how to avoid "confirmation": right now, spammers know your address is live if you click on any of the links, or reply to it - with his system, the spammer would automatically know as soon as you read the e-mail, just by watching for that message request. (On the other hand, removing the spammer's storage server would prevent the spam reaching anybody else, unlike the current system...)

Re:"Pulling" email

[Chacham]

This is Dan Bernstein's approach.

Wow! Thanx! Just subscribed. :)

One nasty flaw he doesn't seem to have addressed is how to avoid "confirmation":

Why is that a bad idea? Any time you read a page the reader has "confirmation". Anyway, let's address the problem properly. If the reader doesn't want the sender to know when it is sent, the reader should block it, not the sender. This can be easily done by checking off which emails to read, and then have the client pull the checked ones either at a random, or

Re:"Pulling" email

[Cyberdyne]

Why is that a bad idea? Any time you read a page the reader has "confirmation". Anyway, let's address the problem properly. If the reader doesn't want the sender to know when it is sent, the reader should block it, not the sender. This can be easily done by checking off which emails to read, and then have the client pull the checked ones either at a random, or the same time every day.

The question isn't when the e-mail is read, but if. The problem is, the spammer still knows the e-mail was read; with SMTP,

Re:"Pulling" email

[Chacham]

OK. Interesting. The confirmation thing is an issue, but i don't care that much about it. The main issue is spammers, yet this will avoid the problem for the most part, making confirmation a non-issue.

The privacy aspect is a problem, but then again, it isn't much of an issue, because we'll only read it if it isn't spam, and if it's a list (say, from a company invading our privacy to know when we read it) the timming issue can be addressed, as to know that we read it is irrelevant, as the list was probably