Show HN: IMAP-based message broker client written in Go
github.com
github.com
I can totally see this project being combined with a "smart" encryption system (one that can tell when to encrypt emails to people that support it) to sit right on top of our current SMTP setup to provide "progressive enhancement" for apps that want to add these things to email.
People have been hoping for encrypted email for decades. If it doesn't happen now, when "email server compromise" is a theme of the presidential contest, it's not going to happen. The key management is just too inconvenient.
> email is only "free" because it's given away
Email is a free network because anyone can join the network and run an email server without paying "fees" or getting anyone's permission. Same as HTTP servers. (Apart from domain names which are "owned" by ICANN).
I'd call it open, but the point is clear enough.
Webhosting : http :: Email : imap
Yes, you can get it for free, but it's a service provided by someone. Unless you setup your own server, which still costs money, it's technically paid. Gmail doesn't charge you for it because they're crawling your data and using it to serve you ads, so they make money through advertising instead of charging you.
Email is generally encrypted with TLS today. The Google Safer Email initiative's transparency page shows that 86% of emails sent from Gmail to other providers are encrypted, and 78% of messages coming into them are encrypted. https://www.google.com/transparencyreport/saferemail/
Google has done a lot of good work driving encryption support in the industry through their efforts on Gmail with the Safer Email initiative.
If you are communicating with a party that you can coordinate with, then you can arrange for encryption by ensuring that both of your servers support it. Communication from mail servers to mail user agents is also commonly encrypted. The percentages above should be understood to reflect a random sample of which senders/receivers already support encryption out-of-the-box, i.e. most of them.
> Email is missing anonymity.
This is generally undesirable in the email space because it cannot be reconciled with the need to prevent abuse (spam, malware, phishing). Having a strong sender identity is desirable so that there is accountability.
2. Anonymity hasn't been reconciled, but that doesn't mean it cannot be.
S/MIME and PGP are things that exist.
Arguably the part that needs "fixing" is:
a) improving S/MIME certificate issuance process and multi-device setup.
b) supporting (or enabling by default) S/MIME in Email clients.
PGP is more popular with technical users, but for most people I think S/MIME is a more appropriate model - we already trust CA's for HTTPS, and for the majority of people that is a better solution, as clients can then simply verify the message against an X500 certificate chain rather than needing to know how to fetch PGP keys and where to fetch them from.
I can't quite imagine taking the step to IMAP, though.
A useful next step would be to have an IMAP server with no queuing delay. When a message comes in via SMTP, and there's a connected client authorized to receive it, the message gets delivered to the client before the SMTP connection is closed. If no client is available to receive the message, queue the message and return "250 Queued" vs "250 Delivered". No mail bounces; all rejections are made during the active SMTP connection.
Similarly, a pure mail forwarder (SMTP in, SMTP out, no local mailboxes) would be useful. Again, it should open the outgoing SMTP connection while the incoming connection is still open, and return statuses immediately.
This no-queuing approach to SMTP gives us chat over email. It will interoperate with existing queuing-type servers, but if the whole chain is no-queuing, you get immediate delivery with a status telling you it reached the client.
(All this would apply only to messages with only one "To" address. Everything else gets dumped into a database for later bulk delivery as normal.)
Then, of course, you could have a client which can display quick email conversations in chat bubbles. No more need for centralized chat services, and it interoperates with existing email systems.
It's like that whole "email and/or password wrong" error when you try to login to a website. They don't want to give away who is registered on the site.
This is however such a great idea to send some commands to your pet projects. At the very least, don't know of a (dirty or non-dirty) solution which is this quick.
I would say, why not (maybe not, because some naive soul uses this on anything high-volume and hilarity ensues).
Unfortunately message delivery latency has gone up a lot these days. It might be saner to ask, "can we deliver mail over MQTT?" instead.
This is how Matrix works, but using SRV records:
https://github.com/matrix-org/synapse#setting-up-federation
I've tried Matrix, and I feel it has potential, but right now the standard homeserver is slow and a bit of a memory hog. There are some on-going projects to develop other implementations, but they are far from complete, and not usable. I'm also a bit miffed why they didn't just choose the standard "user@domain" format for user identifiers.