E-mail is old. And ugly. Very old and ugly. In many ways, it's unbearable. And yet, this ancient, grossly insufficient standard (SMTP) never seems to be replaced by something better. Many 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 (if you don't count the poorly designed protocols themselves) and got so established that it just won't go away. Just like the perversely badly designed Unix operating system. Just like so many awful things we are stuck with today.

Yes, some of the following problems also exist with traditional "snail" mail. However, a different spirit (for the most part), coupled with the expenses in time, effort and money required to send a physical letter, and of course the days or weeks of lag compared to the seconds it takes to send e-mail, made these much less serious. At least I imagine so. Anyhow, there is no good reason to be content with electronic mail being simply much faster and virtually free, when there are such serious issues.

One can easily send e-mail "from" [email protected] or any other existing or made-up address. And many do, for malicious purposes. It doesn't take any special skills or "hacking". It's a "feature", built into the protocol, to be able to specify any sender.

Most people have no idea about this and assume that whatever comes in "from" a given address is a real letter. Including IT companies, which really ought to be specifically trained to be aware of and work around this kind of abuse. I don't want to know how often fraudulent e-mails with messages such as "Please reset the password on my server!" are successful. Since the "Reply-to" address can be different from the "From" one, not only is it possible to fake-send e-mail, but also to receive a reply without the real owner knowing and without ever breaking into any account.

The awful workarounds include coming up with some kind of "security code" which you agree on beforehand and then always provide when sending letters to a specific person/entity, or manually send e-mails back and forth every time asking whether or not this was a real letter and then wait for the response before doing anything else. I personally use a system where anyone who wishes to reach me has to fill in a form on a Web page, receive an automated letter with a code and visit an address to verify that they really sent it. That's somewhat common for support tickets and whatnot with businesses. At least the ones who aren't criminally incompetent, which way too many are.

Or you could just have built this right into the protocol. Basically, whenever somebody sends an e-mail to somebody, the receiving mail server should check with the machine responsible for the account (based on the "From" address), which either responds with "yes, I really did send this", in which case the letter is delivered to the user account, or "no, this must be a fake", where it's just deleted and forgotten about. Simple, logical and obvious. Fool-proof. Would have saved so much trouble. But we can't have that, can we? Of course not!

I fully understand that this is 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 "I have seen it!" signal to the person who sent you the letter. This would not be another e-mail message, of course, but some kind of "flag" which the sender would see as a little notification next to the sent letter or something (depending on the implementation), completely removing any doubt about whether the receiver saw the e-mail or not. The need for repeated/duplicate letters would decrease a lot, as would the confusion and annoyance.

(The SMTP claim that the letter "was delivered" doesn't tell anything about the user actually seeing it, or when.)

Depending on your provider and environment, 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 huge portions of the human population. Since it's relatively easy to create a new account with such a service, this can be done repeatedly to harass somebody.

Therefore, 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 time unit. Based on the answer, it may choose to do anything from deleting the letter silently to sending back a message saying something like: "Sorry. Your account is too fresh. This user only wants e-mail from established accounts." (which could also be standardized as a signal).

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 suggests 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? 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.

Maybe the cost shouldn't be monetary at all (not even using something like Bitcoin), but instead based on solving computer-expensive crypto math problems. This would make sending an e-mail message a big deal for the computer/server, without dealing with money or being too annoying to the human being.

This might not sound like a technical problem with the e-mail protocol, but it is. 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 (or they don't care). Nothing could be further from the truth, as evident from the countless trash "subscriptions" I've blocked manually over the years.

For any company to send any further letters or do anything related to any e-mail address, the minimum requirement should be to send a standardized 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 even today, and the only reason not to do it is the urge to spam people with stupid crap they have no interest in for commercial reasons.

Once again, this "request" should not even be an e-mail message, but a standardized request signal, built into the protocol. The user could then be presented by his client to a nice list of senders who wish to be granted your permission to send you e-mail, and would simply select "yes" or "no" for each. (If they change their mind later, it would obviously allow you to send a secure "unsubscribe" signal just as easily, and preferably allow to optionally add a local block just in case this is ignored.)

Now I'm really getting into "oh, come on!" territory, I suspect, but 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". As an outsider, there isn't any kind of "checksum" which you can use to verify whether the full contents of an e-mail (perhaps 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 if they so wish.

By default, the letters are sent in plain text, just like traditional post cards can be read by any postal worker on the way. The problem is obviously 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 passwords, 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 very few users even have an idea on how to set up encryption, not to mention actually do this (they shouldn't have to know/think about it), which is possible but such a huge hassle that it becomes practically useless unless dealing exclusively with hardcore geeks.

Due to the way the protocol was designed, and the state of things, it is to be assumed that your message was sent in an entirely unencrypted, unsafe manner. A somewhat reasonable exception might be sending between two accounts of the same provider, but that still won't stop the NSA and whatnot from reading it — just others.

I don't know. It's extremely unlikely that any of these things will be fixed at this point. IMO, they are really part of the absolute basics for a protocol of this kind to work outside a small group of academics, as was the case long ago when this garbage was invented. I consider not just e-mail in its current state but the entire Internet to be fundamentally flawed, designed by either very naive or very sadistic people.

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 many other things as well. However, I realize that this isn't realistic and likely won't happen. (Or if it does happen, they will find ways to screw it up.)

You can send me some feedback, tip me or link people here.