4 ms·

> The lack of E2E encryption and sender authentication makes it completely useless these days. Both SPF and DMARC provide sender authentication.

GekkePrutser 6y ago
Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters. Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge. If we'd require emails to be signed by default this issue wouldn't be present. What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
- dane-pgp 6y ago
  > Well one issue with them is that they're totally optional. So is every proposed replacement for SMTP.
  - GekkePrutser 6y ago
    True, but at least it would have those things incorporated in it. So you don't have different versions with and without. I would imagine it would gather uptake pretty quickly. Just like other protocols which have advanced. Like SSH v2, nobody uses v1 anymore.
nobody9999 6y ago
> > The lack of E2E encryption and sender authentication makes it completely useless these days. >Both SPF and DMARC provide sender authentication. And TLS encryption via required encryption via STARTTLS[0][1] plus s/mime or gpg can provide E2EE. Not sure if mnm/tmtp supports endpoint data encryption though. [0] https://en.wikipedia.org/wiki/Email_encryption https://en.wikipedia.org/wiki/Email_encryption [1] https://tools.ietf.org/html/rfc8314 https://tools.ietf.org/html/rfc8314
- GekkePrutser 6y ago
  The problem is that s/mime and gpg are too complex for end users. Especially the key management, the encryption itself is not the issue. s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!) Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
  - nobody9999 6y ago
    You make very good points. Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments. GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche. That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment. It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
zimpenfish 6y ago
I thought SPF was more "this email is allowed to come from these hosts" authentication which tells you nothing about the sender (to me, at least) other than "they used an approved host"?

GekkePrutser 6y ago

Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters. Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge. If we'd require emails to be signed by default this issue wouldn't be present. What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.

dane-pgp 6y ago
> Well one issue with them is that they're totally optional. So is every proposed replacement for SMTP.
- GekkePrutser 6y ago
  True, but at least it would have those things incorporated in it. So you don't have different versions with and without. I would imagine it would gather uptake pretty quickly. Just like other protocols which have advanced. Like SSH v2, nobody uses v1 anymore.

nobody9999 6y ago

> > The lack of E2E encryption and sender authentication makes it completely useless these days. >Both SPF and DMARC provide sender authentication. And TLS encryption via required encryption via STARTTLS[0][1] plus s/mime or gpg can provide E2EE. Not sure if mnm/tmtp supports endpoint data encryption though. [0] https://en.wikipedia.org/wiki/Email_encryption https://en.wikipedia.org/wiki/Email_encryption [1] https://tools.ietf.org/html/rfc8314 https://tools.ietf.org/html/rfc8314

GekkePrutser 6y ago
The problem is that s/mime and gpg are too complex for end users. Especially the key management, the encryption itself is not the issue. s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!) Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
- nobody9999 6y ago
  You make very good points. Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments. GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche. That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment. It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.

zimpenfish 6y ago

I thought SPF was more "this email is allowed to come from these hosts" authentication which tells you nothing about the sender (to me, at least) other than "they used an approved host"?