KimmoA.se presents...

Why e-mail sucks

E-mail is ugly. And old. And insecure. Very ugly and old and insecure. In many ways, it's unbearable. Yet, this ancient, stupid protocol (SMTP) never seems to be replaced by something better. Several attempts have been proposed/attempted, but nothing seems to change. Just like the crappy protocols IRC or FTP, it was born at a time when the Internet wasn't full of cancer and got so popular that it just won't go away.

I'm very well aware of the fact that all of the following points were just as possible using traditional "snail" mail. However, a different spirit (mostly), coupled with the expenses in time, effort and money required to send a physical letter, and naturally the days or weeks of lag compared to the seconds it takes to send e-mail, made this much less of a problem. Or at least I imagine so. There is no reason to be content with electronic mail being simply much faster and virtually free when there are such serious issues with the current standard.

Anyone can send e-mail that appears to be coming from anyone

I can easily send e-mail from bgates@microsoft.com or anything else. Do I do so? No. But some do. And it doesn't take any skills whatsoever. It's a "feature", built into the protocol, to be able to specify any sender for the letter.

Nearly every single user of e-mail has no idea about this and assumes that whatever comes in "from" a given address is a real letter. Including IT companies which ought to be especially trained for this kind of thing. I don't want to know how often a faked attempt such as "Please reset the root password on my server!" is successful. You know, since the "Reply-to" address can be different from the "From" header, which is rarely observed.

The current ways around this is to either come up with some kind of "minimal security code" which you agree on beforehand and then always provide when sending letters to a specific entity (ugh!), or you have to send a manual e-mail back every time (watch out for a possible Reply-to header) asking whether or not this was a real letter and then wait for the response (ugh!).

Or you just build this right into the protocol (good idea). Basically, whenever somebody sends an e-mail to somebody, the receiving mail server checks with the machine responsible for the account (in the "From" header), which in turn asks the user. Exactly how this should show up for the user I don't know, but it might not even be necessary to involve the user's attention. It could just send some kind of unique-for-each-letter "key" through the protocol. If matching, the receiver gets an "OK" back, and this way, they don't have to worry about faked "From" headers.

There is no way to know whether the receiver got the e-mail

Okay, I get that this is also a privacy issue. There are many situations in which you don't want the sender of an e-mail to know you received it. However, I propose some kind of middle road.

Make it possible to easily press a button to send a "receipt" to the person who sent you the letter. This would naturally not be a normal e-mail, but some kind of "verification flag" which the sender would see as a little flag or something (naturally entirely dependent on the implementation), completely removing any doubt about whether the receiver got the e-mail or not. The need for repeated/duplicate letters would decrease a lot.

There are no barriers

Depending on your provider and setup, you can set up filters to block any e-mail coming from *@abusive-host.biz. However, there are huge e-mail services which most people use for e-mail which you simply cannot block if you want to communicate with most people. Since it's effortless to create a new account with such a service, this can be done repeatedly to harass somebody.

The protocol and the mail servers should support a special request where the receiving server may ask the sending one whether or not the account is older than X days. Based on the answer, it may choose to delete the letter silently or send back a message saying something like: "Sorry. Your account is too fresh. This user only wants e-mail from established accounts." All of this would of course have to be activated by the account holder, and requires that all the big providers have such an API set up.

It's free.

I'm hardly the first to suggest this, but the extreme abuse in the form of spam, malicious "e-mail bombs" and just plain junk that's only sent because it's free to do so suggest that a "virtual stamp" would be a good idea to implement somehow.

Some obvious questions should immediately pop up: Who gets to charge you, how much, how, and wouldn't this allow for abuse in the other direction (provoking a service to send e-mails to cost them money)?

The answers are: I don't know, I don't know, I don't know and yes. It's a terrible idea. Forget about it. I see no practical solution for this.

(Still, I'm more than open to at least the theoretical concept of being able to optionally send "premium" letters which truly are important/critical, perhaps even in multiple tiers, but the practical problems seem too overwhelming for this to work.)

Few newsletters require verification

This might not sound like a technical problem with the e-mail protocol, but hear me out. Most sites just assume that whoever enters an e-mail address into some form field is the owner of the account who is subscribing to their letters. This is false. I've had to block countless of them manually.

There needs to be a regulation of some kind which states that for any company to send any letter or do anything related to any e-mail address, the minimum requirement must be to send a request to the address with a unique code (as a Web address) which, IF followed, marks the requested action (such as subscribing to their newsletter) as "OK". This is trivial to accomplish technically and the only reason not to do it is the want to spam uninterested people with crap they have no interest in.

Ideally, this "request" should not even be an e-mail message, but a standardized request of some kind, built into the protocol. The client could then be presented with a nice, separate list of senders who wish to be granted your permission to send you e-mail, and would simply select "yes" or "no".

Anyone can modify an e-mail message and publish it somewhere

Anyone can send an e-mail to somebody with contents that is likely to be responded to, then just copy the entire headers from the reply and change the body text, and publish it as "proof". There isn't any kind of "checksum" which you can use to verify whether the full contents of an e-mail (body + address + relevant headers + timestamp) was actually sent or not.

The sending server would not need to keep all of this data, but only store the hash, the e-mail address that sent it and the timestamp, and respond to such a request with a simple "yes" or "no", or, optionally, refuse to answer such requests entirely for privacy. Any major e-mail service/company would be likely to have this turned on by default, perhaps allowing individual customers to turn it off.

E-mail messages cannot be assumed to be delivered securely

By default, the letters are sent in plain text, just like traditional post cards. The only problem is that e-mail is used for far more important things than just static newsletters or sharing video links of cute cats with family members. Important password, authorization codes, unique verification links and classified/personal information is sent over this protocol even though it is very unlikely that it's encrypted. I say "very unlikely" because few users even have an idea on how to set up encryption or actually do this (nor should they have to think about it), which is possible but a huge hassle and yet another ugly extension.

Due to the way the protocol was designed, nobody can ever assume that their message is securely transferred, or even that it's encrypted at all. Weak encryption would have been (marginally) better than plain text, even if it might have given people a false sense of security. But then again, they probably wouldn't know about this anyway, thus not get any ideas.

So how do we get this fictional protocol into use?

I don't know. It's extremely unlikely that any of these things will be fixed. I consider not just e-mail in its current state but the entire Internet to be more or less fundamentally flawed, and most of the humans who are using it just make it even worse. I primarily put this together in order to inform people in general.

My solution would be to entirely replace the current protocol without trying to preserve backwards compatibility, since it's the only way to get rid of these problems once and for all. That goes for a lot of things. However, again, I realize that this is just a pipe dream.