3 ms·

Russell from Mailgun here. From our perspective, most people start (or at least should start) with the premise that email is not secure. There are things that

Russell from Mailgun here. From our perspective, most people start (or at least should start) with the premise that email is not secure. There are things that we can do to make email more secure, but as an email service provider, we have to balance delivery with security. Most customers would rather have their email delivered to an inbox than us only deliver to an inbox where we can validate the TLS certificate presented by the server. In-fact, delivery is the entire reason companies like Mailgun exist. That doesn't mean we don't care about security. We've rolled out opportunistic TLS about a year ago, we're working on rolling out mandatory TLS soon (with strict certificate verification), and have a slew of security feature coming down the pipeline that I think (some) customers will be really excited about. However, when it comes to delivery, the truth is that features like mandatory TLS are not really requested or demanded by customers. In the email world, delivery trumps security which is not surprising when you work from the premise that it is not secure to begin with.

IgorPartola 12y ago
So it's sort of a chicken-and-egg situation then, huh? "It's not secure" => "Can't make security mandatory" => "It's not secure". Off topic: Another thing I don't get is how do the relays validate each others' certs? You can get a postfix box up and running with a single command, no CA's involved. How does Mailgun know that it's talking to my mail server at mail.example.com? Or is that what DKIM doing? If so, then aren't we just relying on DNS to distribute public key info, which is not secure? Also, what if I don't publish DKIM?
billyhoffman 12y ago
Russell, Please don't take my comments as a knock on Mailgun. You guys rock. It was more the frustration with the idea that 1) encryption is optional for certain network protocols, and that 2) you upgrade a plaintext connection to a secure connection. This simply fails in practice, and we have seen this time and again with HTTP/HTTPS. 1) is changing, which is good. 2) is something people keep pushing for because it should work. Afterall you can configure your server to require a STARTTLS, and have all your client's configured to always use STARTTLS and abort out if it doesn't become secure. Stop that. You are already making this to complicated. Crypto is hard enough as is. (See lower comment re: Comcast and STARTTLS). Ignoring the fact that you are mixing Layer 5/6 concepts into your Layer 7 application prototol, you are creating an insecure-by-default system. Its plaintext, unless you do these things. Stop that. You are doing it backwards. Make it a separate port, and SSL/TLS happens before the application protocol is even accessed. "Is this connection secure" and tracking state and transition into/out of that is not the job of an application protocol. Make this simple and boolean.

IgorPartola 12y ago

So it's sort of a chicken-and-egg situation then, huh? "It's not secure" => "Can't make security mandatory" => "It's not secure". Off topic: Another thing I don't get is how do the relays validate each others' certs? You can get a postfix box up and running with a single command, no CA's involved. How does Mailgun know that it's talking to my mail server at mail.example.com? Or is that what DKIM doing? If so, then aren't we just relying on DNS to distribute public key info, which is not secure? Also, what if I don't publish DKIM?

billyhoffman 12y ago

Russell, Please don't take my comments as a knock on Mailgun. You guys rock. It was more the frustration with the idea that 1) encryption is optional for certain network protocols, and that 2) you upgrade a plaintext connection to a secure connection. This simply fails in practice, and we have seen this time and again with HTTP/HTTPS. 1) is changing, which is good. 2) is something people keep pushing for because it should work. Afterall you can configure your server to require a STARTTLS, and have all your client's configured to always use STARTTLS and abort out if it doesn't become secure. Stop that. You are already making this to complicated. Crypto is hard enough as is. (See lower comment re: Comcast and STARTTLS). Ignoring the fact that you are mixing Layer 5/6 concepts into your Layer 7 application prototol, you are creating an insecure-by-default system. Its plaintext, unless you do these things. Stop that. You are doing it backwards. Make it a separate port, and SSL/TLS happens before the application protocol is even accessed. "Is this connection secure" and tracking state and transition into/out of that is not the job of an application protocol. Make this simple and boolean.