4 ms·
Sounds great but it's really hard to get adoption of a new protocol. If I want to get a secure message to someone all I need is: me --(TLS)--> my SMTP --(TLS)
by rythie 12y ago
Sounds great but it's really hard to get adoption of a new protocol.
If I want to get a secure message to someone all I need is:
me --(TLS)--> my SMTP --(TLS)--> receiving SMTP server
All any third party will know is that I'm sending email to gmail/yahoo/ms or whereever.
If I can't trust my ISP's outbound SMTP server, then I could have one on my own machine or even built in the mail client. The problem of course is that many ISPs put client IP addresses on RBL lists.
- calpaterson 12y agoI think he's trying to address more than just people intercepting emails in transit but there are a lot of things a government body could do to compromise your suggestion, for example: MITM the connection at a network level (mail daemons normally don't check certificates came from CAs), take control of the receiving SMTP server or maybe even just use an unpatched OpenSSL bug (heartbleed is still unpatched on quite a lot machines, including mail servers). Securing email will require a lot more than just turning encryption on, IMO.
- rythie 12y agoI'm taking it as read that users would use message encryption - which already exists. Would creating a new protocol force daemons to check certificates came from CA? stop third parties controlling servers? or using unpatched OpenSSL though? anymore than a properly setup SMTP server though?
- peteretep 12y agoI would have thought it's pretty easy to allow both ingress and egress nodes across traditional SMTP, allowing you to send a DIME email to dropbox@secure via SMTP, which then routes appropriately, or to send a DIME email to a friendly DIME server which then relays it in to SMTP land. The purpose appears to be to hide meta-data - as long as you are tumbling through a friendly DIME relay, you'll lose at least half of the meta-data, which is probably enough.