I will be happy to pay less for the most recent O'Reilly of the most recent fashionable programming language with the condition that my license to read it will expire in 4 years.
I suppose you have a better idea --- one that doesn't increase traffic at all? and--using the current SMTP protocol?
Pervasive SMTP authentication and sending server verification won't stop spam, but they reduce spoofing dramatically without requiring fundamental changes to SMTP. Reducing (or eliminating) spoofing help to identify spamming and spam-friendly servers, which can help in either fixing them or removing their operators from the Internet by way of blacklists (technical and social) or prosecution.
Then [spam] suddenly drops because the [spammers] know it doesn't work anymore.
That's never worked for any other spam "solution", ever. Never. Not once. Not ever. It won't going to work for yours. If your idea has any effect, and it will make the problem worse. It ignores the realities of backscatter, it is susceptible to joe jobs, it relies on everyone modifying their clients to have any effect, it increases traffic, it increases server-side storage requirements, it's susceptible to spoofing client-side responses, and it has the possibility of harassing innocent people.
You're actually encouraging me to go implement this in a real email client.
If you really must do this, run your idea past nanog or asr. If they jump up and down for joy at your idea (instead of saying exactly what I said in more colorful terms that question your parentage), I'll withdraw my objections.
People say a language is "dynamic" as if it were a selling point, but what they really mean is that it is interpreted, they were too lazy to write a compiler for it, and that type checking is always deferred to runtime, even when you don't want it to be.
People who say that have never programmed in a dynamic language, and wouldn't recognize one if they made small talk with one at a party.
The reason languages like Python, Perl, and Ruby are written, the reason that aren't mentioned when evangelizing these languages, is that writing an interpreter is *easier* than writing a compiler (note I said easier and not easy). There's no need to write assembly for lots of platforms, or deal with things like register allocation, so some of the harder problems are taken off your plate.
That's funny; I seem to recall patching the register allocator of a virtual machine for dynamic languages just last week.
Yes, it might inconvenience you a little to reply to me, if it's your first ever email. But I hardly call it invasive.
That's probably because you have never run a mail server.
Suppose your mail server gets 10,000 messages a day, and 9,500 of them are spam. (That percentage may be a little low.) Do you really think it's a good idea to double the amount of mail traffic by sending 10,000 challenge messages in response, especially when you know, statistically speaking, that 95% of them will, at best, be undeliverable and, at worse, will annoy innocent people if not tripping their challenge/response systems?
That's not even thinking about mailing lists, or single messages sent to multiple people at an organization and expanded for local delivery to clients only at their server. (What then, does each client send a separate challenge and response?)
Heck, most of the time I'm lucky to even get any message at all. Open it and it's just blank. Let alone a valid email address. Let alone a valid email address WITH a valid IP.
Setting aside the question of how you know the address is valid, your system is going to have a very difficult time sending a challenge in response if you can't get a valid address from envelope headers or message headers.
Honestly, there are systems out there already that do at least that much to fight [spam].
Indeed they are. That's how people who run mail servers know that this technique is not just fundamentally broken, it's stupid, antisocial, and psychopathic.
It actually has syntax instead of a syntax tree. (Oh, and half the code you complain about is a regular expression, and for the syntax there blame Unix.)
Python/Perl/Ruby are limited to Unix/Linux people so still they are more expensive.
I've never tried Ruby on Windows (and I've heard that there aren't a lot of Ruby porters who compile and test on Windows, but I don't know that), but Perl and Python run just fine on Windows.
This is all possible in Perl, but it's rather difficult to manipulate the syntax tree directly as you would in a Lisp or a Scheme. Unambiguous parser overloading is definitely Deep Magic in Perl 5. (Perl 6 makes this much easier.)
If a spammer forges an envelope, how the hell is he going to guess the right IP address?
Spammers can't forget all envelope headers, but they can forge some envelope headers. Besides that, the spammer can tell if an IP address looks reasonably valid the same way you would -- checking for an MX record.
I *never* - not even once - got a [spam] message from a valid email address of someone I knew....
Now you're redefining what "invalid" means. It's nice, I suppose, that your work and business and hobbies and personal life are such that you can make a whitelist of everyone from whom you expect to receive mail and label every other address in the world as invalid, but that's really not practical for everyone else.
My method works even if YOU do nothing to upgrade your email client or mail system.
... except for the part where your method relies on everyone else's client to receive your client or server's challenge and respond to it appropriately.
We still reply even though it's a valid address that was forged. But we also look at the IP addresses. If the original IP address isn't in the same range as the reply, then there's no possible way it could be valid.
Which IP address? Did you know that spammers can (and do) forge some of the envelope headers as well? If you're suggesting what I think you're suggesting, now you've reinvented SPF badly.
Usually SPAM is from a completely invalid address (easily 99.99%).
You're going to have to prove that. How do you know it's an invalid address until you attempt to deliver to it?
Frankly [SMTP] needs an overhaul. No authentication/verification for who the sender is?
Sure there is; authenticated SMTP, with something like DomainKeys or SPF to verify that the sending server has the authority to (and really did) send a message from the specified address.
Our original received email (on the receiver's end) could easily just be thrown into a temporary [spam] folder (so the user could peruse it if they want to). Then when the reply is received from the original sender, it's taken out of the [smtp] folder and displayed (or left there if no reply).
Okay, so your solution is vulnerable to backscatter, depends on an easy way to tell if a given e-mail address is valid as a sender and a recipient, reinvents SMTP authentication in a new and possibly incompatible way such that people have to upgrade to a new protocol, breaks store-and-forward, and requires everyone to upgrade their mail clients.
Gmail mostly solves it for me anyway.
... and you've obviously never run a mail server if you think that server side filtering somehow "solves" the problem.
Plenty of people have proposed this solution before. It doesn't work, and it won't work. That's why we don't use it. I'm sorry.
On one side, you a loose collection of individual developers who distribute their software freely, with the restriction that if you also distribute it or a derived version, you must distribute it under the same terms.
On the other side, you have a company who knowingly infringes the copyright of the first group.
What else would you call the first group but "good guys"?
For starters, spammers routinely forge from addresses. I get the occasional spam and virus message ostensibly (if you believe from addresses, which I don't) from other subscribers to the Perl 5 Porters mailing list and other CPAN authors.
Responding to those addresses (belonging to people who occasionally send me real mail) is a waste of time. A spammer or a virus has forged their addresses. In fact, I have a better chance of responding to the actual sender of the message by sending the challenge and response to a completely random e-mail address, as I know that the purported sender is wrong.
As for store-and-forward, there's no requirement that a sending client has to be online or available while an intermediary server delivers the mail even one hop closer to its final destination. In fact, the SMTP design goes in the opposite direction.
Re:Referencing? I smell a rat
on
Advanced Rails
·
· Score: 1
That's Slashdot's own referrer link, and Slashdot's put them on book reviews for years.
Yes, because asking home users to configure their ISP's postfix server is really going to work.
Would you really trust any ISP that cannot or will not configure authenticated SMTP to do anything more intellectually challenging than babysitting a picture of a dog torn from a magazine?
Slashdot Mirror
... only if your "refactoring" doesn't include a comprehensive, fully-passing, and regularly run test suite.
This might be a poor example; O'Reilly uses the Founders' Copyright system.
I'm not making money off of the copyrights I hold to free software I've written. Does that mean I don't get to keep the copyright?
You're thinking of physicists, who can prove this hypothesis for all prime numbers which are perfectly spherical and exist in a perfect vacuum.
Pervasive SMTP authentication and sending server verification won't stop spam, but they reduce spoofing dramatically without requiring fundamental changes to SMTP. Reducing (or eliminating) spoofing help to identify spamming and spam-friendly servers, which can help in either fixing them or removing their operators from the Internet by way of blacklists (technical and social) or prosecution.
That's never worked for any other spam "solution", ever. Never. Not once. Not ever. It won't going to work for yours. If your idea has any effect, and it will make the problem worse. It ignores the realities of backscatter, it is susceptible to joe jobs, it relies on everyone modifying their clients to have any effect, it increases traffic, it increases server-side storage requirements, it's susceptible to spoofing client-side responses, and it has the possibility of harassing innocent people.
If you really must do this, run your idea past nanog or asr. If they jump up and down for joy at your idea (instead of saying exactly what I said in more colorful terms that question your parentage), I'll withdraw my objections.
Microkernels have to follow processor ABIs too.
Function calls are a band-aid solution to the problems that a well-written program would not have in the first place.
People who say that have never programmed in a dynamic language, and wouldn't recognize one if they made small talk with one at a party.
That's funny; I seem to recall patching the register allocator of a virtual machine for dynamic languages just last week.
That's probably because you have never run a mail server.
Suppose your mail server gets 10,000 messages a day, and 9,500 of them are spam. (That percentage may be a little low.) Do you really think it's a good idea to double the amount of mail traffic by sending 10,000 challenge messages in response, especially when you know, statistically speaking, that 95% of them will, at best, be undeliverable and, at worse, will annoy innocent people if not tripping their challenge/response systems?
That's not even thinking about mailing lists, or single messages sent to multiple people at an organization and expanded for local delivery to clients only at their server. (What then, does each client send a separate challenge and response?)
Setting aside the question of how you know the address is valid, your system is going to have a very difficult time sending a challenge in response if you can't get a valid address from envelope headers or message headers.
Indeed they are. That's how people who run mail servers know that this technique is not just fundamentally broken, it's stupid, antisocial, and psychopathic.
It actually has syntax instead of a syntax tree. (Oh, and half the code you complain about is a regular expression, and for the syntax there blame Unix.)
I've never tried Ruby on Windows (and I've heard that there aren't a lot of Ruby porters who compile and test on Windows, but I don't know that), but Perl and Python run just fine on Windows.
This is all possible in Perl, but it's rather difficult to manipulate the syntax tree directly as you would in a Lisp or a Scheme. Unambiguous parser overloading is definitely Deep Magic in Perl 5. (Perl 6 makes this much easier.)
Perl threads have their flaws (lots of memory copying), but they're native threads (unlike Ruby 1.8) and there's no GIL (unlike Python 2.x).
Spammers can't forget all envelope headers, but they can forge some envelope headers. Besides that, the spammer can tell if an IP address looks reasonably valid the same way you would -- checking for an MX record.
Now you're redefining what "invalid" means. It's nice, I suppose, that your work and business and hobbies and personal life are such that you can make a whitelist of everyone from whom you expect to receive mail and label every other address in the world as invalid, but that's really not practical for everyone else.
... except for the part where your method relies on everyone else's client to receive your client or server's challenge and respond to it appropriately.
Which IP address? Did you know that spammers can (and do) forge some of the envelope headers as well? If you're suggesting what I think you're suggesting, now you've reinvented SPF badly.
You're going to have to prove that. How do you know it's an invalid address until you attempt to deliver to it?
Sure there is; authenticated SMTP, with something like DomainKeys or SPF to verify that the sending server has the authority to (and really did) send a message from the specified address.
Okay, so your solution is vulnerable to backscatter, depends on an easy way to tell if a given e-mail address is valid as a sender and a recipient, reinvents SMTP authentication in a new and possibly incompatible way such that people have to upgrade to a new protocol, breaks store-and-forward, and requires everyone to upgrade their mail clients.
... and you've obviously never run a mail server if you think that server side filtering somehow "solves" the problem.
Plenty of people have proposed this solution before. It doesn't work, and it won't work. That's why we don't use it. I'm sorry.
Gemstone, for one example, was 14 years old at that point.
BitTorrent clients?
On one side, you a loose collection of individual developers who distribute their software freely, with the restriction that if you also distribute it or a derived version, you must distribute it under the same terms.
On the other side, you have a company who knowingly infringes the copyright of the first group.
What else would you call the first group but "good guys"?
For starters, spammers routinely forge from addresses. I get the occasional spam and virus message ostensibly (if you believe from addresses, which I don't) from other subscribers to the Perl 5 Porters mailing list and other CPAN authors.
Responding to those addresses (belonging to people who occasionally send me real mail) is a waste of time. A spammer or a virus has forged their addresses. In fact, I have a better chance of responding to the actual sender of the message by sending the challenge and response to a completely random e-mail address, as I know that the purported sender is wrong.
As for store-and-forward, there's no requirement that a sending client has to be online or available while an intermediary server delivers the mail even one hop closer to its final destination. In fact, the SMTP design goes in the opposite direction.
That's Slashdot's own referrer link, and Slashdot's put them on book reviews for years.
Not really -- backscatter makes the idea very bad. (It also breaks the store-and-forward model, which is sort of a feature of SMTP.)
Would you really trust any ISP that cannot or will not configure authenticated SMTP to do anything more intellectually challenging than babysitting a picture of a dog torn from a magazine?
This may be a wild guess, but you've never run a mail server, have you?
If there's a single dominating opinion, it's that there's a single dominating opinion.