
Show HN: IMAP-based message broker client written in Go - ms123
https://github.com/mikaa123/imapmq
======
Xeoncross
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.

~~~
jcrites
> Email is missing encryption.

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/](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.

~~~
Xeoncross
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.

------
StavrosK
I can't decide whether this is amazing or horrible, and I like it.

~~~
vidarh
Once upon a time we had a message broker based around Qmail.

I can't quite imagine taking the step to IMAP, though.

------
Animats
Nice.

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.)

~~~
Ded7xSEoPKYNsDd
SMTP without queuing is called LMTP. It's not completely compatible because
messages delivery success needs to be communicated for each destination
address.

[https://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol](https://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol)

~~~
Animats
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.

------
positivecomment
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).

~~~
bsg75
> It panics sometimes instead of returning the errors and there's no way to
> catch that in a clean way in go.

[https://golang.org/ref/spec#Run_time_panics](https://golang.org/ref/spec#Run_time_panics)

------
robryk
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.

------
sametmax
Actually this gets me thinking: what about making a signaling server for
webrtc chats using IMAP ? This way we got a truely decentralised chat system.

~~~
pjc50
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.

~~~
thatcry
As someone who is fascinated by decentralized social networks, I always come
back to email as the ultimate solution to that problem.

------
mxuribe
Very clever...not sure its something that I would use in production...but
definitely fun.

------
crest
A nice PoC to trash your IMAP service.

~~~
sametmax
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.

------
turowicz
Where is this world going to

