7 ms·

The way I see it, SMTP protocol and email formats are root of the problem. Yes, they are great in connecting all kinds of devices and making communication easy.

The way I see it, SMTP protocol and email formats are root of the problem. Yes, they are great in connecting all kinds of devices and making communication easy. But they belong to times when one could write a postcard (text on the outside) and expect it to arrive to destination without being read loudly in every local pub from here to there. In times when we need proper enveloped email, calling postcards emails is inadequate. Another issue is number of tools and skills we need to implement email server locally, which I suspect is a result of same specifications, protocols and formats. I am no expert on this (not a real one anyway) but there has to be a point when effort to support a system outweighs convenience?

bitJericho 12y ago
Most any decent email client allows for GPG encryption so your the source and destination provider can't read your emails. Further, most email is sent straight A to B encrypted (if both providers support it), along the unsecured internet, making anybody between A and B unable to review the email.
zAy0LfpBZLC8mAC 12y ago
As bitJericho already noted, nothing in the protocol or the format prevents encryption--and as a matter of fact, you can use end-to-end encryption with email now, even though it was not originally explicitly designed for that. That is one of the really great strengths of email: It can be adapted and extended in many ways as technology develops. Other than that, I still don't see what your criticism actually is. All of that is not to say that the email protocol stack is somehow particularly elegant (it most certainly is not), but most often when you hear people say that we need to reinvent email, they don't actually understand what the problems with email are and just seem to think it's bad because it's old--all while being completely oblivious of the lessons that have been learned with email. Despite its lack of elegance, it does actually incorporate a lot of wisdom, as well as its fair share of stupidity. But what tends to be overlooked in particular is that for quite a few of the most obvious problems with the usability of email (namely, authentication of senders and spam), those problems are not problems that the people who invented and extended the protocols and formats failed to consider, but that despite a lot of effort and intelligence applied to them, they failed to come up with a solution for. And the reason for that tends to be that those problems are fundamental social problems that just crop up in email just as they do elsewhere, which can not be solved by simply inventing "modern email". As for how difficult it is to set up your own mail server, I don't really have a clue. I mean, I do it all manually, but that's probably just because I learned how to do it quite a while ago, and now that I know how to do it all manually and I have a working setup anyhow, I don't know what easier ways might be available. But in principle, I don't see why it shouldn't be possible to put together a package of a pre-configured mail setup for standard cases which shouldn't be all that difficult to deploy. I mean, if you look at how many magnitudes more awful the web stack is, and ordinary people still manage to install and use a web browser, completely oblivious to the hilarious complexity of that piece of software.
- A_COMPUTER 12y ago
  Email security is a bolt-on and can't be relied on in any way. You cannot run a mail server that forces STARTSSL or TLS because you inevitably have important mail that comes from or goes to a server that can't or won't send it to you encrypted. And PGP only encrypts the body of the message, and not the metadata, the concealment of which in transit is crucial for privacy. I believe there is an RFC for encrypting headers, but it has no traction. I think the reason some people talk about starting over is because of this. The minimum level of security of email must be allowed to fall back to is "no security."
  - zAy0LfpBZLC8mAC 12y ago
    Well, I would agree that the non-encryption of end-to-end headers with PGP is somewhat of a bug. Other than that, I think those are all examples of problems that are not actually email problems. Whether you can force TLS/STARTTLS doesn't really matter. First, you cannot ever force anyone to keep something secret, they can always publish a secret that they know somehow and thus make it not be a secret anymore. You can always offer STARTTLS though, so if the other side wants to keep a secret secret from eavesdroppers, they then can do so. That does not help against People in the Middle, of course, as they can strip out the STARTTLS offer. But being able to "force" STARTTLS doesn't help you either, as that would only force the middleperson to speak TLS to you. If you wanted to force authenticated communication that protects you from MitM, you would first have to set up some authentication mechanism. On a server-by-server basis, you can already do that. If you wanted to do it globally, we would need a reliable global PKI. Such a thing does not exist and is extremely hard to build--and in particular, it's not an "email problem". Reliable authentication is mostly a hard social problem. As for metadata encryption: Well, that pretty much is impossible by definition, except maybe through mix networks. You cannot simply encrypt the information that needs to be readable in order to route the message to the destination. Even if you deliver a message via TLS to my MX, the mere fact that your mail server looks up my domain MX and then connects to it already tells an eavesdropper all the meta information there is. And if you solve that by instead doing all the routing inside gmail or some other big provider, you obviously haven't solved anything, as now google can see, sell, and be subpoenaed for this information. Also, "security" is a word without any meaning. You can only be secure against particular attacks/risks, and securing a system against a particular risk often is in conflict with securing it against another risk, so you can only ever achieve one or the other, and it's often a difficult decision which risk to take. In the case of email, you could very easily secure the system against spam, for example: Just have a government agency that licences email server operators and shuts down any that engage in spamming. The side effect: Email is not the slightest bit secure against government censorship anymore. And yet again, there is a social problem at the core, not a technical one. There are reasons why email is so "insecure". And as I wrote above: It's not that people didn't think about it. It's more likely that those who suggest that starting over could help solving the problems haven't really thought through it. In particular the "security" problems of email are extremely hard problems, and they are hard for social and political reasons, not for technical reasons.

bitJericho 12y ago

Most any decent email client allows for GPG encryption so your the source and destination provider can't read your emails. Further, most email is sent straight A to B encrypted (if both providers support it), along the unsecured internet, making anybody between A and B unable to review the email.

zAy0LfpBZLC8mAC 12y ago

As bitJericho already noted, nothing in the protocol or the format prevents encryption--and as a matter of fact, you can use end-to-end encryption with email now, even though it was not originally explicitly designed for that. That is one of the really great strengths of email: It can be adapted and extended in many ways as technology develops. Other than that, I still don't see what your criticism actually is. All of that is not to say that the email protocol stack is somehow particularly elegant (it most certainly is not), but most often when you hear people say that we need to reinvent email, they don't actually understand what the problems with email are and just seem to think it's bad because it's old--all while being completely oblivious of the lessons that have been learned with email. Despite its lack of elegance, it does actually incorporate a lot of wisdom, as well as its fair share of stupidity. But what tends to be overlooked in particular is that for quite a few of the most obvious problems with the usability of email (namely, authentication of senders and spam), those problems are not problems that the people who invented and extended the protocols and formats failed to consider, but that despite a lot of effort and intelligence applied to them, they failed to come up with a solution for. And the reason for that tends to be that those problems are fundamental social problems that just crop up in email just as they do elsewhere, which can not be solved by simply inventing "modern email". As for how difficult it is to set up your own mail server, I don't really have a clue. I mean, I do it all manually, but that's probably just because I learned how to do it quite a while ago, and now that I know how to do it all manually and I have a working setup anyhow, I don't know what easier ways might be available. But in principle, I don't see why it shouldn't be possible to put together a package of a pre-configured mail setup for standard cases which shouldn't be all that difficult to deploy. I mean, if you look at how many magnitudes more awful the web stack is, and ordinary people still manage to install and use a web browser, completely oblivious to the hilarious complexity of that piece of software.

A_COMPUTER 12y ago
Email security is a bolt-on and can't be relied on in any way. You cannot run a mail server that forces STARTSSL or TLS because you inevitably have important mail that comes from or goes to a server that can't or won't send it to you encrypted. And PGP only encrypts the body of the message, and not the metadata, the concealment of which in transit is crucial for privacy. I believe there is an RFC for encrypting headers, but it has no traction. I think the reason some people talk about starting over is because of this. The minimum level of security of email must be allowed to fall back to is "no security."
- zAy0LfpBZLC8mAC 12y ago
  Well, I would agree that the non-encryption of end-to-end headers with PGP is somewhat of a bug. Other than that, I think those are all examples of problems that are not actually email problems. Whether you can force TLS/STARTTLS doesn't really matter. First, you cannot ever force anyone to keep something secret, they can always publish a secret that they know somehow and thus make it not be a secret anymore. You can always offer STARTTLS though, so if the other side wants to keep a secret secret from eavesdroppers, they then can do so. That does not help against People in the Middle, of course, as they can strip out the STARTTLS offer. But being able to "force" STARTTLS doesn't help you either, as that would only force the middleperson to speak TLS to you. If you wanted to force authenticated communication that protects you from MitM, you would first have to set up some authentication mechanism. On a server-by-server basis, you can already do that. If you wanted to do it globally, we would need a reliable global PKI. Such a thing does not exist and is extremely hard to build--and in particular, it's not an "email problem". Reliable authentication is mostly a hard social problem. As for metadata encryption: Well, that pretty much is impossible by definition, except maybe through mix networks. You cannot simply encrypt the information that needs to be readable in order to route the message to the destination. Even if you deliver a message via TLS to my MX, the mere fact that your mail server looks up my domain MX and then connects to it already tells an eavesdropper all the meta information there is. And if you solve that by instead doing all the routing inside gmail or some other big provider, you obviously haven't solved anything, as now google can see, sell, and be subpoenaed for this information. Also, "security" is a word without any meaning. You can only be secure against particular attacks/risks, and securing a system against a particular risk often is in conflict with securing it against another risk, so you can only ever achieve one or the other, and it's often a difficult decision which risk to take. In the case of email, you could very easily secure the system against spam, for example: Just have a government agency that licences email server operators and shuts down any that engage in spamming. The side effect: Email is not the slightest bit secure against government censorship anymore. And yet again, there is a social problem at the core, not a technical one. There are reasons why email is so "insecure". And as I wrote above: It's not that people didn't think about it. It's more likely that those who suggest that starting over could help solving the problems haven't really thought through it. In particular the "security" problems of email are extremely hard problems, and they are hard for social and political reasons, not for technical reasons.