Slashdot Mirror
IETF to Look at Spam
m00nun1t writes "CNET has an article about the Internet Engineering Task Force (IETF) looking at what they can do about spam. According to the article, many of the proposals seems to "require changes in basic e-mail technology", which presumably means SMTP (and about time!). Maybe they are looking beyond just SMTP - anyone have any insights here?"
If an alternative to SMTP were developed, the protocol would not be likely to disappear immediately subsequent to the creation of its successor. The transition would be gradual, as reverse-compatibility could remain necessary for several years afterward. As suggested by the release of Apache 2.0, for instance, not every server administrator adopts a "technological improvement" until it becomes an adequately proven and stable product.
Do you like German cars?
The article notes that one of the major problems is the filtering of genuine mail due to agressive spam filters necessitated by cleverer spammers. Consider this analogous to dropping some packets at the network layer. Just as the transport layer handles this problem, we can build a higher level protocol to handle filtered mail.
Note that having a mechanism to handle dropped mail allows us to employ agressive filtering: one that is sure to stop 100% of spam.
What I have in mind is as follows: when Bob receives a mail from Alice (i.e, it has passed through Bob's filter) the client software sends a confirmation mail back to the Alice. This is not a regular mail that the Alice will see in her inbox; it has a special header flag that marks it as a confirmation. Alice's client software keeps track of the confirmation messages; by looking at her "sent-mail" folder she can see which of her messages have not been confirmed (and are hence likely to have been mistaken for spam).
Finding that Bob has filtered her mail, Alice can either re-word it and send it again or do something like (assuming that Bob knows Alice): "Hi Bob, this is me, Alice. Your filter blocked this so I've rot13'd it to get past the filter. rot13 what follows to read my mail." Another option is to encrypt the mail with Bob's public key (assuming that spammers' scripts won't be clever enough to get your public key from your web page). Note that 99% of the time the mail is going to get through. You have to make that little effort to prove you are a human only once in a long while.
There is minor problem with requiring the receiver to send a confirmation message: Bob might check his mail only after a couple of days, during which time Alice may assume that her mail was blocked. There are 2 solutions: either Bob runs a script to filter his mail regularly, or else has his ISP implement his filter for him.
Note that this won't work if you have the receiver send a reply whenever the message did get blocked: the reply could itself get blocked etc. (This is called the red army - blue army problem in networking).
World of Ends, recently discussed on Slashdot, discusses why the simplicity (or stupidity) of the Internet is so useful. "The Internet isn't a thing. It's an agreement," they say.
That same argument applies to e-mail. Following their logic, it is best to leave SMTP alone. Simpler protocols are better. Leave the "value-added" pieces to the edge, and let the simple message transfer protocol alone.
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
email is by far the most widely used of all Internet services. I belong to an organization many of whose members are retirees are on fixed incomes, and it is only within the last two years that the number of people with email has grown to a critical mass (about 2/3 of the membership).
Of members of the lay public who regularly use email as a means of communication do not have the level of technical comfort that most Slashdot readers take for granted.
Of people who use email, the percentage who know how to use a web browser is much less than 100%. The percentage who can google for information is much less than 100%. The percentage who can successful extract and decode an email attachment is much less than 100%. The percentage who can view a government form or a corporate brochure in PDF format and read it with Acrobat is much less than 100%.
And the average age of their computers and operating systems is much more than three years--and they're not likely to update their email programs.
Whatever is done needs to be 100% backward compatible with existing email clients, not requiring even simple upgrades, or an astonishing proportion of real-world Net users will be disenfranchised.
(And please, let's not have any facile expressions of contempt for AOL users or webtv clients or people who bought email appliances (that includes one of the retirees I mentioned).
"How to Do Nothing," kids activities, back in print!
The only problem with this is scalability. Sure SMTP has had its problems, but the nice thing about SMTP is you control the server. You control how fast mail comes in, from who it comes in, how fast people can give you e-mail, and how fast you give it out to subscribers/recipients. All of these schemes seem to remove that control from your machine.
Instead of adding a band-aid solution to spam, let's sit down and list what we need for an a-mail server. Scalability, reliability, fault tolerance, expandability and distributed servers top my list. I'm sure that there are other better ones out there too. If you're going to revamp the protocol, try to get everything in the first time, and let's try to get it right.
You think that I'm crazy, you should see this guy!
This sounds perfect, And here is how it can be implement with backwards compatibility
It's implementation could also be made rather interesting. Rather than a completely new protocol that is totally impractical (since it would require everyone upgrading simultaneously) this kind of scheme could be implemented in a completely backwardly compatible manner. Allow me to describe what I mean.
Your email server has been upgraded to the new system and you send an email. Your outgoing server store the email and forwards a very simple email message onto the recipients email server, this small email contains the appropriate subject line and an extra chunk (with appropriate mime type) containing the information necessary to retrieve the full email message (ie: Server details, email id and probably an authentication token of some sort). Your client software supports the new standard it receives the stub email and retrieves the full message appropriately. This stub email is not an extra compatibility thing; we are simply using the existing smtp infrastructure to tell the recipient that they have a piece of email.
But what if the recipient has not yet upgraded, here comes the clever bit. Html email works as an extra mime chunk that enabled clients automatically decode and show the reader, non enabled clients see the standard plain text version of the message that is also present in the message, this mechanic can be used to our advantage here, the normal text or html portion of the stub email contains a hyper link back to the sending server which a url designed to bring up a basic web mail page with the recipients message.
Using this implementation scheme it would be possible for the sender who upgraded from day one to send an email to anyone with the complete confidence that they would be able to read the full text of the message. The only proviso here is that the recipient had access to a web browser.
In addition I can see one other advantage to your proposed scheme that has not been mentioned, the email system becomes inherently more secure. Since the sending server must actively hand over the email it can record that this has been done and tell the recipient if the message had been read before. Although as with anything else strong cryptography would be required to ensure to ensure that nobody could get hold the authentication token (and thereby read the email) it would be possible for the sending server (providing you trust it) to tell you authoritatively that nobody else had retrieved the message contents.
...allow binary transfers. I can't tell you how much CPU time has been wasted by base64 encoding binaries, sending them over an inefficient protocol, and decoding them on the other end. yEnc does a good job but the whole encoding shenanigan is a major pain for anyone trying to send family photos or the latest AFI album. Please, IETF, make a better 8-bit clean push protocol, because SMTP is the only one we have.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare