The point is that once it's changed, anyone I want to email me will have to contact me and will be on my list, and I will be absolutely certain that everything else is spam (without having to glance at it before deleting it.)
If it escapes into the wild, who cares - that's the whole point.
One caveat is that I must inform my friends not to give my address to my OTHER friends - otherwise I'll never know about them and they don't end up on my list.
Granted, you have to be a bit of an isolationist but most people who I chat with about this as they're asking me for authorization are fascinated when I tell them that it removes 100% of spam, and want to learn more.
Anyway, I'm open minded. I try filters to further reduce my spam base but they just don't work. Give me an alternative that is 100% guaranteed and I'll switch. This is the only option right now.
I disagree with you. I have a more thorough thread on this below you might want to check out.
My position is that there is already an authorization step for virtually all senders of email - you need to get the recipients address.
Most people are careful not to publish their address for obvious reasons. To get someones address, you have to ask them in person somehow.
I use this system, and I haven't had any problems when I ask someone "by the way, what address will you be sending from? I need to add you to my list." Most don't ask why since most people don't ask for someone's address and refuse to give their own - it's stupid anyway, since pretty soon you'll see their from address in their message.
Anyone who doesn't want you to know their address before sending a message is probably malacious and you don't need their email anyway. Anyone who doesn't mind will gladly give it to you when they ask you for your email address.
I agree, and I have a more detailed discussion of this going on somewhere below, perhaps you can come and jump on my side, since I'm getting flamed down there.:)
When integrating it into the SMTP server, this is better than using an auto-reply to inform senders of how to get authorized.
When the connection is dropped, the 'reason' line reported by the mail server could be 'he doesn't know you! call him.' Thus, relying on existing SMTP technology to send this communique back to the sender without using any kind of auto-reply function that just consumes bandwidth and has other drawbacks.
I fully plan to write this system into my mail server and see no other reason that it will not work. Unfortuantely I'm on Exchange and don't know much about programming it, so I'll be doing this when I can switch to a Linux based email server. I'm just waiting for Mandrake 9...:)
I recieve approximately 50 legitimate emails per day and 100-200 spams. If these were all intermixed in my inbox, deleting the spams by hand is a major chore.
Glancing at a container filled with almost 100% spam to spot an out-of-place legitimate message takes only a second or two instead of 15 minutes.
After your contact list truly evolves to contain everyone you email, it gets to the point where you don't even have to look as hard in that container, since everything tends to be spam. Most days, I just nuke it without looking and if I miss one or two non-spams, no big deal.
Spam filters are just as likely to junk just as many legitimate messages as my system does. So you still have to look through it. How is a filter any better? Only a perfect filter would allow you to automatically delete the junk, but there is no such thing. Baiesian(sp) or whatever, it just won't ever happen. The spammers will always find a way around it.
But there is a more important point to all this that I think is being missed. My method only requires me to look into the trash box because I'm trying to be accomodating to those senders who I haven't emailed in a while and maybe don't have on my contact list. But, if this were a more standard and accepted method (just the general idea of authorization-based email) people would make an effort to be sure the recipient "knows" them before sending, because they would know that their message will otherwise be dropped.
Given any spam solution, if we all used it, it doesn't increase it's effectiveness. With this solution, if we all used it, it would be perfect.
Additionally, it could be integrated more tightly with the mail server to check the contact lists of everyone on the server, and not even deliver the message at all if it's unrecognized. As I heard recently, the SMTP connection could be dropped before the entire message is even transmitted. In other words, pause recieving after the FROM line until it's sure that it's authorized, and otherwise, drop the connection.
If I changed my email address tomorrow (which I'm considering), I could implement auto-delete and never see them. Why? Because anyone emailing me is going to have to ask me for my email, thus getting on my contact list. Nobody is going to find me otherwise, and the system becomes perfect. If you happen to be in a position where you're email address is changing anyway, you're in a unique position to implement this with perfect results.
Thanks for the comments and I'd like to discuss this more.
I realized one day that filtering spam out by content is a futile exercise.
I use a simple method that has worked perfectly: If the FROM address of an incoming message is not in my contact list, the message is Trashed.
Before emptying the trash, I'll glance through it to be sure that I didn't recieve a legitimate message from someone not in my list.
Since I've used this, not one spam has ever appeared in my Inbox. This is important since I use mobile devices and other strange ways to access my email that would be very sensitive to spam overload.
Fact is, 99.999% of email I receive is either 1.) From people already on my contact list, or 2.) People who inform me they're going to send an email. Before I give out my address, I inform them that I need to know their address first, and add it to my contact list.
If someone gets my email from someone other than me, or otherwise didn't talk to me first, I probably don't want their email anyway. And if it's important, they'll get in touch with me.
I'm using Outlook for this solution and use a rule that moves all the messages out of the Inbox that don't meet this criteria. I plan to switch to Evolution soon under Mandrake and I'm sure I can program a similar function.
It's much easier to spot 1 message from a legitimate sender out of 100 spams (takes only a few seconds in fact) than it takes to manually delete spams or constantly fiddle with filters. Each day, I'll glance at the list of 100-200 spams that have collected in my trash box, and within a few seconds, I can spot if someone I know has sent me something who isn't in my list. From that point forward, they're in my contact list, and it never happens again.
At some point I plan to set up an auto-reply system that gives people a URL that they can visit to "ask for permission" to send me email. Spammers won't use it. I haven't bothered yet because I'll need to carefully design this to prevent my address from being "confirmed" by spammers as a result of this message, but I have ideas for that (send from a null account, use a picture of my email address in the message, with instructions on how to ask permission.)
At that point, I can safely instant-trash all unrecognized recipients.
I'd love some feedback on this method. It's worked great for me, though admittedly it won't work for those who recieve many emails from new contacts, such as someone who publishes (eek!) their address on a site for inviting new messages.
Hover your mouse over links such as those at fark.com. You'll notice they run them all through a GO script to track where you go, then forward you there. It's almost invisible, it is invisible to new users. If a webadmin wants to track this, this is the best way - not to rely on a transient browser anomaly. "Anomaly" is a better term for this.
The above could be obfuscated further by altering the status bar text to the "destination" link rather than the actual, tracker-link.
I do not consider this a security flaw since web admins have the ability to track where you're going WITHOUT this anomaly using server-side.
There are several other ways: Remember that the link is on the page that they control. An OnClick event that runs a function that talks to a server CGI to log which link you clicked, your IP, date time, is easily done.
Some might think the resources used for such an implementation are more intensive: They need to run you through a CGI. But a CGI needs to read your cookie, and also relies on you coming back (what if you don't? The data is lost.) Anyone exploiting this isn't thinking through their implementation, and their solution will not work for most browsers, and will soon quit working altogether.
Another argument: The difference with server side tracking is that, when you return, they don't know "who" clicked "which" link. Also false. I can cookie you with a unique identifier, and log your linkhit against that cookie ID, and when you return, tell you which link you clicked.
Let's summarize: If this bug is fixed, but you leave cookies, status-bar-text-changing, and javascript on, I can do the same thing. If anyone doesn't believe me, you don't know much about scripting and I am willing to make a page proving this - you're welcome to come and test it with your "patched" Mozilla browser.
So this is a security threat, how? Creating the user.js file is as simple as turning off cookies, or editing the various other script settings to combat the deceptive tactics used by webadmins to track you.
If I was on the BugZilla team I'd be demoting this defect to "anomaly, minor" or whatever lowest possible rating it has.
Slashdot Mirror
True but that's not the point.
The point is that once it's changed, anyone I want to email me will have to contact me and will be on my list, and I will be absolutely certain that everything else is spam (without having to glance at it before deleting it.)
If it escapes into the wild, who cares - that's the whole point.
One caveat is that I must inform my friends not to give my address to my OTHER friends - otherwise I'll never know about them and they don't end up on my list.
Granted, you have to be a bit of an isolationist but most people who I chat with about this as they're asking me for authorization are fascinated when I tell them that it removes 100% of spam, and want to learn more.
Anyway, I'm open minded. I try filters to further reduce my spam base but they just don't work. Give me an alternative that is 100% guaranteed and I'll switch. This is the only option right now.
I disagree with you. I have a more thorough thread on this below you might want to check out.
My position is that there is already an authorization step for virtually all senders of email - you need to get the recipients address.
Most people are careful not to publish their address for obvious reasons. To get someones address, you have to ask them in person somehow.
I use this system, and I haven't had any problems when I ask someone "by the way, what address will you be sending from? I need to add you to my list." Most don't ask why since most people don't ask for someone's address and refuse to give their own - it's stupid anyway, since pretty soon you'll see their from address in their message.
Anyone who doesn't want you to know their address before sending a message is probably malacious and you don't need their email anyway. Anyone who doesn't mind will gladly give it to you when they ask you for your email address.
I agree, and I have a more detailed discussion of this going on somewhere below, perhaps you can come and jump on my side, since I'm getting flamed down there. :)
Another quick thought:
:)
When integrating it into the SMTP server, this is better than using an auto-reply to inform senders of how to get authorized.
When the connection is dropped, the 'reason' line reported by the mail server could be 'he doesn't know you! call him.' Thus, relying on existing SMTP technology to send this communique back to the sender without using any kind of auto-reply function that just consumes bandwidth and has other drawbacks.
I fully plan to write this system into my mail server and see no other reason that it will not work. Unfortuantely I'm on Exchange and don't know much about programming it, so I'll be doing this when I can switch to a Linux based email server. I'm just waiting for Mandrake 9...
It makes a huge difference.
I recieve approximately 50 legitimate emails per day and 100-200 spams. If these were all intermixed in my inbox, deleting the spams by hand is a major chore.
Glancing at a container filled with almost 100% spam to spot an out-of-place legitimate message takes only a second or two instead of 15 minutes.
After your contact list truly evolves to contain everyone you email, it gets to the point where you don't even have to look as hard in that container, since everything tends to be spam. Most days, I just nuke it without looking and if I miss one or two non-spams, no big deal.
Spam filters are just as likely to junk just as many legitimate messages as my system does. So you still have to look through it. How is a filter any better? Only a perfect filter would allow you to automatically delete the junk, but there is no such thing. Baiesian(sp) or whatever, it just won't ever happen. The spammers will always find a way around it.
But there is a more important point to all this that I think is being missed. My method only requires me to look into the trash box because I'm trying to be accomodating to those senders who I haven't emailed in a while and maybe don't have on my contact list. But, if this were a more standard and accepted method (just the general idea of authorization-based email) people would make an effort to be sure the recipient "knows" them before sending, because they would know that their message will otherwise be dropped.
Given any spam solution, if we all used it, it doesn't increase it's effectiveness. With this solution, if we all used it, it would be perfect.
Additionally, it could be integrated more tightly with the mail server to check the contact lists of everyone on the server, and not even deliver the message at all if it's unrecognized. As I heard recently, the SMTP connection could be dropped before the entire message is even transmitted. In other words, pause recieving after the FROM line until it's sure that it's authorized, and otherwise, drop the connection.
If I changed my email address tomorrow (which I'm considering), I could implement auto-delete and never see them. Why? Because anyone emailing me is going to have to ask me for my email, thus getting on my contact list. Nobody is going to find me otherwise, and the system becomes perfect. If you happen to be in a position where you're email address is changing anyway, you're in a unique position to implement this with perfect results.
Thanks for the comments and I'd like to discuss this more.
I realized one day that filtering spam out by content is a futile exercise. I use a simple method that has worked perfectly: If the FROM address of an incoming message is not in my contact list, the message is Trashed. Before emptying the trash, I'll glance through it to be sure that I didn't recieve a legitimate message from someone not in my list. Since I've used this, not one spam has ever appeared in my Inbox. This is important since I use mobile devices and other strange ways to access my email that would be very sensitive to spam overload. Fact is, 99.999% of email I receive is either 1.) From people already on my contact list, or 2.) People who inform me they're going to send an email. Before I give out my address, I inform them that I need to know their address first, and add it to my contact list. If someone gets my email from someone other than me, or otherwise didn't talk to me first, I probably don't want their email anyway. And if it's important, they'll get in touch with me. I'm using Outlook for this solution and use a rule that moves all the messages out of the Inbox that don't meet this criteria. I plan to switch to Evolution soon under Mandrake and I'm sure I can program a similar function. It's much easier to spot 1 message from a legitimate sender out of 100 spams (takes only a few seconds in fact) than it takes to manually delete spams or constantly fiddle with filters. Each day, I'll glance at the list of 100-200 spams that have collected in my trash box, and within a few seconds, I can spot if someone I know has sent me something who isn't in my list. From that point forward, they're in my contact list, and it never happens again. At some point I plan to set up an auto-reply system that gives people a URL that they can visit to "ask for permission" to send me email. Spammers won't use it. I haven't bothered yet because I'll need to carefully design this to prevent my address from being "confirmed" by spammers as a result of this message, but I have ideas for that (send from a null account, use a picture of my email address in the message, with instructions on how to ask permission.) At that point, I can safely instant-trash all unrecognized recipients. I'd love some feedback on this method. It's worked great for me, though admittedly it won't work for those who recieve many emails from new contacts, such as someone who publishes (eek!) their address on a site for inviting new messages.
Hover your mouse over links such as those at fark.com. You'll notice they run them all through a GO script to track where you go, then forward you there. It's almost invisible, it is invisible to new users. If a webadmin wants to track this, this is the best way - not to rely on a transient browser anomaly. "Anomaly" is a better term for this.
The above could be obfuscated further by altering the status bar text to the "destination" link rather than the actual, tracker-link.
I do not consider this a security flaw since web admins have the ability to track where you're going WITHOUT this anomaly using server-side.
There are several other ways: Remember that the link is on the page that they control. An OnClick event that runs a function that talks to a server CGI to log which link you clicked, your IP, date time, is easily done.
Some might think the resources used for such an implementation are more intensive: They need to run you through a CGI. But a CGI needs to read your cookie, and also relies on you coming back (what if you don't? The data is lost.) Anyone exploiting this isn't thinking through their implementation, and their solution will not work for most browsers, and will soon quit working altogether.
Another argument: The difference with server side tracking is that, when you return, they don't know "who" clicked "which" link. Also false. I can cookie you with a unique identifier, and log your linkhit against that cookie ID, and when you return, tell you which link you clicked.
Let's summarize: If this bug is fixed, but you leave cookies, status-bar-text-changing, and javascript on, I can do the same thing. If anyone doesn't believe me, you don't know much about scripting and I am willing to make a page proving this - you're welcome to come and test it with your "patched" Mozilla browser.
So this is a security threat, how? Creating the user.js file is as simple as turning off cookies, or editing the various other script settings to combat the deceptive tactics used by webadmins to track you.
If I was on the BugZilla team I'd be demoting this defect to "anomaly, minor" or whatever lowest possible rating it has.
Erik.LA