Send proper messages FROM: server
Closed this issue · 4 comments
When I get a message from some random person that claims to be sent from nodeatlas, I have no way to verify the message authenticity as well as it exposes the recipients email.
Proposed solutions:
a) Internal Messaging - messages are stored in the database and only notifications are emailed.
b) Email Notifications - think Kijiji or Github, how they deliver a message notification and allow you to reply directly to the conversation.
I'm not sure what you mean by verifying message authenticity of things sent through NodeAtlas. Forged From addresses are a problem inherent in email, and it would take a divine intervention to fix them. It's possible that the SMTP server NodeAtlas uses could implement DKIM, but even so, ensuring that is neither within NodeAtlas's scope nor ability.
Next, the recipient address is not exposed. That was built in from the very start; messaging in NodeAtlas is designed specifically to prevent node owners' email addresses from being exposed. If we wanted to go the simple route and didn't care about that, we'd just display the email addresses on the webui. We don't, however, because we don't want to expose them to every person who comes along and wants to contact someone on the map.
That was the purpose of the message system in the first place: allow node owners to choose not to respond to a message without having their address distributed to anyone but NodeAtlas. If they should choose to respond, then they do so out of band with NodeAtlas, just through email with the sender.
It is impossible to overstate the importance of communication being out of band. This is for three reasons: convenience, simplicity, and security.
Convenience
Handling messages through a webapp, such as NodeAtlas, is inconvenient at best for users. The person initiating contact must do so through the application, then the other person must somehow be able to receive a notification, probably via email, and then respond to it. Who do they respond to? If they respond through the webui, they would have to be able to identify themselves, and respond to a particular message. The original sender must also be able to receive a notification, again, probably via email, and respond back and forth.
The obvious solution to this is to just have NodeAtlas act as a proxy between them, receiving emails on a particular address, like GitHub does, and relaying them to the other party. This has the sole benefit of preventing either party from learning the other's email address, and comes with the severe downsides of requiring an email server capable of receiving messages configured for use with NodeAtlas and for messages to be stored for at the very least a short period of time.
Simplicity
The largest problem with the above "solution" is the requirement of every NodeAtlas instance to be able to receive email. This is a huge requirement, and sets the bar of technical skills needed to configure NodeAtlas properly much higher. It's trivial to configure postfix for sending email, or to use an account on an external mail server, but it is not trivial to configure receiving of email, particularly when some use-cases might require multi-network support, (e.g. the Internet and Hyperboria).
Furthermore, there is a lot of programming overhead for receiving messages. Does that trigger an event? How? Do we just poll for new messages in... mbox format? What about maildir? What if it's configured to use a remote mail server, like gmail? Do we retrieve mail ourselves via... POP3? What about IMAP? Email is a kludgey affair, and we cannot expect every poor bastard who is trying to configure NodeAtlas to also know how to set up maildrop, fetchmail, and the whole assorted suite of individually documented tools.
Security
Anyone who assumes that just because they themselves are trustworthy, their services should be trusted, is incredibly naive. Building a secure system is not only about ensuring parties are trustworthy, it's about ensuring that the system requires as little trust as possible.
If I sent you a message through the webui on NodeAtlas, as it currently is, my message would be delivered immediately via NodeAtlas's configured outgoing mailserver, a footer would be attached notifying the recipient that it was sent through NodeAtlas and who to contact if the message was spammy, and the message itself would not be stored.
However, I could easily assume that the message would be stored, or even modified, but you could reply to the email address I attached, without stepping outside your normal email workflow, whatever that might be, and be reasonably certain that your message would not be modified in transit. You could even sign it, and encrypt to the PGP key ID that I might attach.
The point is that it is out of band from NodeAtlas, and nefarious behaviors of that instance can no longer affect the channel, except for at the initial establishment of communication. So long as verification can be done outside NodeAtlas's scope, NodeAtlas cannot intercept further communication. This minimizes the amount of trust that users need to place in NodeAtlas, the particular instance's admin, and the host of the instance.
In short, this is what I think of in-band messaging, for several reasons:
Forged From addresses are a problem inherent in email, and it would take a divine intervention to fix them.
You are sending mail FROM the recipients address, not from NodeAtlas itself. This is textbook spoofing. Internal/external system or not, that should still be addressed.
That was fixed in 84961e2.
This has been left untouched for three weeks, and email messaging has been working reasonably smoothly for a while. If, for whatever reason, someone feels this shouldn't be closed, then comment and I'll reopen it.