Slashdot Mirror
Replacing SMTP?
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!"
I'd like to simply see SMTP updated to require work. On establishing a connection, a recipient should be able to give the sender a task to complete that takes a second or two. The recipient will only accept the mail once the work unit has been done.
This would make it too slow to send spam, by making it simply too processor intensive. Legitimate users would be unaffected.
To me a big problem with SMTP is that is never authenticated. There's no way you can verify anyone actually sent you an email, short of PGP keys.
At least if some one had to authenticate to send as joe@bar.com, some spammer would have to hack your password before they used your email address as the "From:" in a mailing...which just happened to me.
> I wish people would stop inviting rate increases or new charges as an answer to spam. It's not the answer.
:)
:)
And the perfect example is regular junk snail mail. It costs them to send it, yet even in the Internet Age(tm), I still get a ton of it. Obviously that's NOT the answer, so "Don't Go There"(tm).
I think locking down SMTP servers and requiring verified & correct return addresses would go a long way toward curbing spam. Then when you disallow someone to send you mail, it could really work.
A combination of white lists/black lists, and Baysian filtering stops so close to 100% of spam that it's really silly for anyone to be bitching about spam these days. I don't GET any spam anymore - 0. Not 0.001%, 0 - the integer 0, as in none. If I ever get another piece of spam, then I'll change my email address (I can do that more easily than most as I have my own domain.), though this isn't the answer for everyone - lots of people have e-mail addresses printed up on lots of expensive cards & letterhead, etc. For them, the white list / black list / Baysian filtering solution should suffice way more than anyone should practically need.
Stop yer bitchin', people, and implement the technologies that are already out there and work great. Plus use yer freakin' brains for a change, and don't spew out your real e-mail address to everybody who asks for it. Use your friend's!
C'mon now; the IPv6 upgrade will be spread out over at least several decades. And both Microsoft systems and many US Government installations will still be using it a century from now, because it's "standard".
After all, it's now past the death of typewriters, and we're still using the typewriter keyboard from nearly two centuries ago. And we use a ridiculous rail gauge, because the standard was set centuries ago.
And here in the US, we're still using inches and feet, measurements based on the lengths of the thumb and foot of a long-dead king. And we call them "standard".
We will be stuck with IPv4 for long past the final download of anyone reading this.
SMTP will probably be around even longer. But that's OK; it's fun to impress friends by a "telnet 25", followed by typing in a message directly to the server. I like to use "MAIL From: dubya@whitehouse.gov", and ask them if they'd be interested in a nice job in the TIA program. Then I challenge them to prove from the message they get who actually sent it.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Because the cost becomes built in to their business model. it won't stop, it will only hurt regular users to charge for email/services. Sure, their profits may be cut a little bit, but that's not going to stop them. if anything, they'll do it more, because if their profit margin is smaller, they'll have to spam harder... right?
Non-email messaging systems have been thinking about virtually the same problem quite a bit, and have come up with a set of solutions that try to solve what are fundamentally the same issues: message integrity, message non-repudiation, and message authentication. And the surprising part of this is that nobody really focused on the protocol, because it doesn't provide the path to a meaningful solution to the problem.
Case in point: web services. While initially the people who were playing iwth web services started out doing security at the transport level (i.e. with SSL and various derivatives thereof), but realized that something like WS-Security (where the security of a message is a part of the message itself) is the more optimal approach.
Why not just force the issue into the realm of S/MIME (and similar extensions to rfc822) and handle it at MUA space? You can cover virtually all the problems with SPAM by following the example of the reliable messaging systems and doing more with the contents of the message itself, rather than trying to say that messages have to transmit over a particular protocol. For example, depending on your trust environment, S/MIME signatures solve the authentication, non-repudiation, and integrity problems perfectly. What more do you need/want?
SMTP is not the problem. Open Mail Relays are the problem. As long as you can drop an SMTP box on the net and have it spew Spam to other mail servers you will have Spam. Any new Mail Transport Protocol will have to be backwards compatible. i.e., receive mail from old SMTP servers. You can't switch all machines over at one time, you need to roll out one box at a time and keep it all working all the time.
:-)
In the country where I live there is a general rule for farm animals, the farmer is not responsible for fencing them in, it is your job to fence them out. Mail is the same, its not my job to stop spam being sent, but to stop it being delivered (to my users) There are many ways to do this, a combination of a few can be very effective.
As for the home user, well stop buying into the "submit your e-mail and we will send you porn" forms on the sites you wife does not want you to look at.
I come to this discussion as an expert, albeit a bit dated, as I spent a number of years as the lone software developer supporting ALL email software at Apollo Computer (before it was bought by HP).
There once was a very interesting competing standard from OSI, the X.400 standard. Most people now think of X.400 as an interconnect standard for bridging the various email systems out there. Yet, it actually is a specification for a very robust email system in and of itself. It is based on a self-describing data representation... no, not XML since XML wasn't even a twinkle in someone's eye at that time, but ASN.1. That standard has been somewhat successful as used in X.500, which has become somewhat popular through its exposure via LDAP.
SMTP has never been a particularly strong standard. First, it is not the specification for a complete email system. It mearly describes a protocol for exchanging messages between two processes via the network. This is not sufficient to build an email system. Thus we also get POP and IMAP, and any number of supplimental bits that are not necessarily standards. Even sticking to exchanging email between two processes, SMTP has always been rather loosely specified. Sendmail has served as the reference implementation. Supporting sendmail was more a matter of figuring out what it was doing than reading the SMTP specification since sendmail used a far richer protocol for exchanging email than described in the specification. Thus, the question of what comprised a compliant implementation was more like (does it interoperate fully with sendmail) than going through a specification and checking off each element it described.
Apollo started a project to produce a native X.400 email system. It had a very rich set of features that go far beyond what we see today in Unix and Windows email systems. The project was put on hold when I was reassigned to a higher priority task, I was a member of a strategic technology team given the task of determining what "everyone" meant by the term "CASE Integration" with the goal of producing a corporate strategy and piloting and/or prototyping some initial products. Given the state of the CASE community, it sure seems like pursuing the email strategy would have had better long term success. Of course the CASE Integration project died a painful and horrible death when HP bought the company. Surely "SoftBench" did everything and more...
> They either can't figure out the tools or don't think they should have to.
:-)
And this is the thing - they really _shouldn't_ have to. Bad UI really ticks me off.
> I agree, however, that people are generally naive/dumb when it comes to common sense issues like sending out email addresses at will or even worse...
The thing is - I intended that for this particular audience. _SLASHDOT_ users, of all people, should know by now how to avoid getting spam. I mean _really_.
> clicking on the "Remove" links from spam! VERY DUMB!
Actually, I've proven to myself this is a myth.
Here's my story:
Last year, around, say, September or October, I was getting, on average, about 200-250 pieces of spam PER DAY. This, I realized, just Would Not Do(tm).
So, since it was obvious I was going to have to shut down all my existing e-mail addresses, generate new ones, and be ultra-selective about giving them out in the future, I realized it was time to test that "Don't click on the remove me links" piece of advice. I'd given it out myself many times, even in an article I once wrote. Time to put it to the test! So, for the period of one month, I followed all the instructions on each piece of spam, every day, to see what would happen to my flow of spam. I kept track of who was sending me spam (the company/product/service, not the 'return address'). I found out that you WILL get LESS spam if you actually follow the advice in the spam, in general. My spam reception went from the 200-250 per day to around 20 per day, in the span of about a month. Obviously, this was still way too much frigging spam, but let me say this: the spam I kept getting was almost entirely from the sources that didn't have a (working) removal method, not from the ones that did. Many of the ones that did have an (apparently) working method DO indeed take a few weeks to start working. But, surprise of surprises, it CAN indeed lessen your spam, when it's offered and is working. Bizarre, I know, but I swear it's true.
I'd still rather make spam technically impossible than rely on that, though.
I propose TMTP - the Trusted Mail Transfer Protocol.