3 ms·
> > The lack of E2E encryption and sender authentication makes it completely useless these days. >Both SPF and DMARC provide sender authentication. And TLS en
by 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 agoThe 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 agoYou 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.