I played with an idea of an off-site delivery the GMail-destined emails.
Basically instead of an actual email the recipient would get a link to an https'd page on my mail server and a brief note explaining that due to delivery policy the message is available only at the link.
The reason why I started looking at this was that I was buying a house and the broker person was using gmail to handle the transaction. From negotiation to all the forms with all juicy details. I switched him back to the fax mode, but it got me thinking that it'd be nice to have a system in place that would try and offset such negligence, automatically.
I never got past a rough prototype though, but perhaps I should've.
E-mail between secure servers is perfectly secure (and end-to-end encryption only adds content encryption but keeps the amount of metadata generated the same). The problem is that Google’s email servers are not secure; nor are those of any other email provider. Strictly speaking, not even hosting your own dedicated server somewhere will protect you from these issues.
Uh no it's not perfectly secure because if you don't use e2e encryption you only get opportunistic TLS and you can't control whether your mail will be transported over unencrypted connections. Furthermore, the contents of the email arrives unencrypted at every mail server. So you're basically agreeing with exactly what I said ...
A mail server that only talks TLS is not following the SMTP protocol and is not a part of the global system commonly understood with the term e-mail. Maybe it would be a great idea to migrate the whole world to such a configuration, but in practice it wouldn't give me much confidence. If my server A hands something off to B for it to be delivered to C, then I have no control over whether the link between B and C is secured, so e2e is the only way to be sure.
No, it's not about rejecting email as a secure medium. It's about denying Google access to the contents of emails I sent to people with mailboxes on their system.
Reminds me of a time I had to call a company about an order of hardware parts and they wanted my credit card details over the phone. Having worked in telecoms in the past (on carrier server software), this isn't something I like doing, so instead I gave them a URL to a https page containing the details they needed. It also self destructed so you could only view it once.
A general purpose email version of this (both with and without self destruct (which should have options such as timer, N views etc)) would be awesome, especially if it automatically intercepted emails and moved them there. Would have to be something I can host myself, of course.
If you're sending a link to Gmail, Gmail could simply crawl that link, so I don't see how that would solve anything (except awareness, possibly? At the cost of convenience).
You can block IPs belonging to Google, Micorsoft, ...
And make the link expire after a while (you can keep the content, just make it inaccessible).
Not foolproof or without problems (there are not only crawlers and bots at these companies, there are also people who receive email), it would solve the problem in most cases.
The problem I see is that you could edit all your "mails" to me at any time, even after I've read them. If that could be fixed somehow I think it would be fine.
Basically instead of an actual email the recipient would get a link to an https'd page on my mail server and a brief note explaining that due to delivery policy the message is available only at the link.
The reason why I started looking at this was that I was buying a house and the broker person was using gmail to handle the transaction. From negotiation to all the forms with all juicy details. I switched him back to the fax mode, but it got me thinking that it'd be nice to have a system in place that would try and offset such negligence, automatically.
I never got past a rough prototype though, but perhaps I should've.