Replacing SMTP? 539
dousette asks: "In reading over one of the RFC's governing the SMTP protocol, and other RFC's as well, it's interesting to note that you see some big names and big companies from time to time. With all the loopholes in the current SMTP specification, is it possible for the Slashdot collective to come up with another one? Would it stand a chance in making it into a standard, or do they just listen to Cisco, AT&T, etc? I realize that a lot of people have a lot of ideas how things should be done (and they haven't been shy about posting them to Slashdot), but has anyone tried to write the RFC for a replacement protocol? As a side note (where I won't be shy about posting how things should be done), if there were a replacement trusted protocol, one could have mail received via that protocol bypass spam filtering, id checking, or whatever checks might be in place (saving processor cycles, etc). The regular checks could still be done on other mail received via the 'older' SMTP protocol. If more and more ISP's make use of this, SMTP could be gradually phased out... or if you are one for a sudden cut-over, just cut to the new one at the same time as the IPv6 upgrade!"
Check out Internet Mail 2000 (Score:5, Informative)
http://cr.yp.to/im2000.html [cr.yp.to]
The basic premise is this:
"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."
It's an interesting concept and worth a read.
Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.
Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email
Re:Interesting idea (Score:3, Informative)
QWERTY speeds typing. QWERTY 4ever! (Score:4, Informative)
Anyone can help to create an RFC! (Score:1, Informative)
Re:QWERTY speeds typing. QWERTY 4ever! (Score:3, Informative)
Re:What loopholes in SMTP? (Score:1, Informative)
Basically the 'loopholes' in SMTP are that any field the metatags can be spoofed and no authentication is done. So the only real solution to SPAM is to add an authentication layer on top of it (like PGP-signatures letters). A application-based tool will never happen, because most users don't care enough to sign their letters. A server-based layer on top of SMTP would be no different in terms of compatibility as creating a new protocal that backed down to SMTP if the peer server didn't have the new protocal.
Re:Check out Internet Mail 2000 (Score:5, Informative)
John Dvorak suggested a scheme along these lines, and in theory, it's a good one, though I'd suggest a tenth of a cent, which would still make sending a million emails prohibitively expensive.
In practice, though, it's not workable. Spammers aren't using the SMTP server their ISP provides; they're using their own, just like most desktop Linux users are. As far as the ISP is concerned, Spammer X is making a bunch of outbound connections, but they're streaming out through the ISP's switches and routers, not through their SMTP server.
To impose a tax on certain kinds of TCP connections would require detailed inspection of outbound packets. This is because a single SMTP connection can involve the transfer of many messages. To be reliable, the ISP would have to parse every outbound packet bound for port 25 on a remote system in order to count the number of emails sent. I don't think most people want that level of attention paid to their private emails.
Moreover, this presumes that all ISPs participate honestly and thoroughly in such a system. All it would take is a few spam-friendly ISPs (and they exist, are legion, and jump around IP ranges like ferrets on a hot skillet) to render such a system useless.
The alternative would be to implement email billing at the recipient side. Maybe AOL and Earthlink can pull that kind of blockade off, but small companies and J. Random Luser cannot.
Bernstein's IM2000 proposal at least keeps the bandwidth consumption down, but that's primarily a cost issue for ISPs. (Don't try to convince me that if the amount of spam declined, ISPs would lower their prices.) The main hassle of spam for the user is that it takes time and energy to delete spam, and having to inspect the stuff with ambiguous could-be-from-someone-I-know subject lines would not be alleviated by IM2000; you'd still have to pick and choose what pending inbound email to read or delete.
The fundamental problem with email as a mail system is that it's open to anyone who wants to send mail -- which is part of the point of mail in the first place -- but there is no economic limiting factor for the sender as there is with paper mail. Since we can't eliminate the openness without destroying the utility of the system, the only possible strategy is to artificially impose a cost on the sender. Unfortunately, owing to the nature of public networking, the only remotely reliable way to do that would be to route all mail through a centralized clearing house. No one company will be able to establish such a monopoly, and I don't think anyone wants the alternative -- which is to have the government do it.
This may or may not be a soluble problem, but it is, as of today, still an unsolved problem. Personally, I think it's going to take national legislation and international agreements to stop it, and that will no doubt take a long time. Paper (actually clay tablet) mail existed for several millennia before the International Postal Union was finally established. Let's hope email is brought into line a little faster than that.
SMTP is not the problem (Score:3, Informative)
SMTP already has authentication, and anyone who operates an SMTP server is free to accept or not accept mail from whomever he wants. You don't need a new protocol to require mail to be authenticated. If you can solve the trust problem, you can implement a trusted mail solution more quickly and easily with SMTP than by requiring deployment of an entirely new protocol.
SMTP AUTH (Score:5, Informative)
Pragmatism required (Score:3, Informative)
Re:not the answer - you got that right! (Score:4, Informative)
2) A way of verifying what e-mail addresses & domains are allowed on outgoing e-mails from said mail sever. That would be new, but should be easy to develop.
There is a proposal for this [ietf.org], which was covered here [slashdot.org] a while back. I like the idea, although it's going to mean more ISPs will have to offer authenticated SMTP relays for roaming users (not exactly a bad thing, in any case).
Also, to those people saying Bayesian filtering is so great, this doesn't solve my problems. To filter a message on content means I have to accept the damned thing first, and I don't know about anyone else but my inbound traffic costs me money. If I accepted every piece of mail destined for my server, the costs would have me off the net in no time - I have a pretty low-budget operation. Blacklisting servers and not accepting connections from them (and accepting the collateral damage) is the only practical option I have.
Re:Costs (Score:5, Informative)
Check out RF2821.
Re:... at the same time as the IPv6 upgrade! ??? (Score:5, Informative)
Don't laugh. The following might be apocryphal, but it's still interesting .... I don't know where it comes from, though:
Currently being discussed (Score:3, Informative)
This is currently being discussed on NANOG [merit.edu] (where it's an offtopic favorite). I highly recommend this list for peeks and views into the people who keep this Internet thing working.
In the discussions yesterday and today, there's been a lot of talk about how to "bootstrap" this new protocol. There are interesting discussions of the business ramifications of being an early adopter of something like this -- very sililar to those for IPv6.
It's been said by far wiser people than me: spam is a social problem, and it must have a social cure. Any solution which does not respect these two facts is doomed to failure.
Been there, done that. (Score:4, Informative)
If you want to fire up your own X400 server to play with, grab isode and try to get it to compile on your machine without gagging if you can. Its one nasty bit of bad code.
SMTP isn't that broken. It works for about a billion people. Any attempt to "fix" it will break it for way too many of them.
After looking through the posts here (most of the +5 should be -5 Stupid), its clear that most of the experts don't understand email in the real world.
Encryption:
The 1st tings is email must be interceptable. Many governments won't allow high level encryption that isn't full of holes that allow them to play pack recorded streams. Most large email servers can't deal with the CPU load of full encryption anyway so 100% solid encryption is out.
Authentication:
Authenticating the server is very importaint to many sites. Once you start doing some level of encryption, you need to make sure you know who your connecting to.
Authenticating the client is the where spam issue comes from. There are many ways to do this but none of them are being done and none of them work 100% (which is why none of them work)
There is no way of knowing of a new business is a spamer or not. Therefore there is no way to filter out spamers that have enough cash to hook up to new ISPs all the time. (there are some stupid ideas like charging--my isp is rich enough, forcing all email out--my isp's mail server is up 100% doesn't understand MX,I can run my own server and it works so why chnage?)
reverse MX record checks only work if you can trust the ISP to get reverse dns working correctly and they won't deligate it to a spam house. The other choice is a verisgn like company to whitelist everyone or some sort of distributed whitelist (which the spamers will try to hack into)
As far as fixes:
The solution is patch sendmail, qmail, postfix, exim to understand email on port 26 (pointed to by a srv record) and if mail comes in on the new port, then it must be checked with a reverse MX record or its dropped. Get the clients to stop handing off email on port 25 (sendmail allows port 587 for that) Use something like the SSH transport layer to encrypt (i.e. set up the encrypted channel 1st and then figure out whos talking). Add a new smtp verify_message command so I can ask another server "did you send me messages Xcxczxczqweczx?". Patches for all 4 systems must come out at the same time but be tested aginst each other. The when an ISP figures enough of its mail comes in on something other than 25, kill port 25 forever. That will kill all the proxies and all the old email gateways that haven't been updated in years.
Or save up your money and buy your self an X.400 gateway license adn tell all your friends about your cool new email address with all thouse nice slashes and no @.
Re:Jabber (Score:3, Informative)
They are instead backing the (IMO) inferior SIP/SIMPLE technology for IM.
Read The IM Standards Race [jabber.com] for more information.
Re:... at the same time as the IPv6 upgrade! ??? (Score:5, Informative)
http://www.snopes.com/history/american/gauge.ht
Their best comment on it is probably:
Marvelling that the width of modern roadways is similar to the width of ancient roadways is sort of like getting excited over a notion such as "modern clothes sizes are based upon standards developed by medieval tailors." Well, duh.
Then they go into a rather detailed explanation of why it's basically an uninteresting historical semi-truth for exactly this sort of reason.
Still, the modern "standard" railway gauge does go back at least a few centuries. And the early railroad equipment was derived from the sort of horse-drawn vehicles (carriages and carts), so of course it was about the same size.
But in the "standards" sense, the current American rail gauge doesn't really trace back to anything Roman, or much before around 1800. Before that, it's just vague copying, with sizes coming out nearly the same because the job (carrying people and their luggage) was about the same.
The Space Shuttle tie-in is completely bogus.
Separate domains for everybody (Score:2, Informative)
When I discover a piece of spam, I check the sent-to field, and set a rule in my mail program to color it a certain color using the sent-to field as criteria (or transfer to trash), since I know that this single address has been compromised somehow. Since you can clearly know WHICH e-mail addresses are compromised, it makes it very easy to filter these out.
Re:not the answer - you got that right! (Score:3, Informative)
If the fear is people faking mail, you simply need to require it went through the mail smtp server for that domain. Then the smtp server needs to authenticate all the clients. This would mean that the client IP is irrelavent, it just had to authenticate to a listed address/server.
You still have a problem with open/insecure releys, but that will always be a problem, an insecure system will always be crackable, and people who intentionally set stuff up to allow spamming will always be able to act trusted long enough to spam.