Well I guess if you ensure you only use a specific directory to store the emails, and given IMAPS servers know how to deals without millions of messages every hours, I'd say we should be ok.
It panics sometimes instead of returning the errors and there's no way to catch that in a clean way in go.
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).
Long ago I knew someone who effectively used email as a chat system: the delivery latency was low enough for local email that you could just put the message in the Subject and reply immediately. This did indeed rely on IMAP IDLE.
Unfortunately message delivery latency has gone up a lot these days. It might be saner to ask, "can we deliver mail over MQTT?" instead.
You missunderstand, the goal is not to use email for the messages, the goal would be to use IMAP to signals users to each others, THEN switch to webrtc to chat.
Email can be decentralized because of DNS as its underlying routing "protocol". To reach somebodies emailserver, you need to know the MX record of its domainname (which is part of the emailaddress). Maybe we can build a decentralized chat system based on this same principle, by using TXT records for example.
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.
Email is missing chat. Email is missing encryption. Email is missing anonymity. Yet email is the last free, public, globally distributed network we have. Phones, radio, even snail mail all have fees and oversight from a central source.
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.
Well, apart from the whole rest of the internet which is also free, public, and global. And email is only "free" because it's given away by ISPs and advertising companies.
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.
The internet isn't a decentralized message system as much as it is a decentralized network for a variety of content types.
> 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).
Well technically anyone can come up with some new protocol for messages and if everyone started using it, that would be free as well. "Email" isn't free, the protocols used are.
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.
1. When I say encrypted, I mean Email is missing end-to-end encryption. In other words, the two (or more) parties participating in the discussion. That a carrier encrypts messages in transit is a nice start. PGP is not a solution for the masses yet.
2. Anonymity hasn't been reconciled, but that doesn't mean it cannot be.
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.
The interface is slightly weird. If I call Sub() twice (e.g. in two different goroutines) for the same queue, each message will be received by one of these two subscribers (because the channel is shared). I'd expect exact opposite: all of them to receive each message.
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.)
SMTP without queuing is called LMTP. It's not completely compatible because messages delivery success needs to be communicated for each destination address.
I'm suggesting doing this in SMTP only for single-address messages. So the extensions for multi-address status info aren't necessary for two-person chat.
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.
"250 Delivered" is always given so that you can't sniff email addresses even if no such user exists on the server.
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.
33 comments
[ 2.6 ms ] story [ 69.8 ms ] threadI can't quite imagine taking the step to IMAP, though.
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).
https://golang.org/ref/spec#Run_time_panics
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.
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.
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.)
https://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol
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.