Ask HN: Non-SMTP single server internal mail system?

35 points by eggsome ↗ HN
Hi HN, I'm building a project that needs to have an "internal" mail system for users to communicate between each other on a website. It will never route to the outside world (think "messages" that you would send on a dating site).

The scale is very small (less than 500 users).

I'm sure that there must be a number of projects floating around on GitHub that fulfill this purpose.

The best option at this point seems to be using something like phpBB and disabling all forums. Surely that is overkill for such a simple requirement?

42 comments

[ 2.7 ms ] story [ 112 ms ] thread
I've written a couple of websites that have user-to-user messaging, once even a dating site. I didn't use SMTP at all, and I'm surprised why you would consider it.

Assume for the moment you created mailboxes for each user, assume you have two users "Alice" and "Bob". If Alice wanted to send a message to Bob you certainly could send an email to a local SMTP-server via an address like "Bob@mail.local". Then when Bob logged into your site you could poll that mailbox via IMAP/POP3 and retrieve the message.

But really it would be far simpler to just query a database, avoiding the overhead of needing to speak IMAP(S)/POP3(S). Especially if your site is dynamic already and needs to use a database.

Sure use outgoing SMTP to send an email to the real-address of a member "You've got a message from Alice".

He specified "non-smtp" in the title
I don't think you read his comment completely.
mail is not real-time messaging
he is not looking for a mail system, he is looking for a "system for users to communicate between each other on a website". it does not need to be real time, but its not be a problem if it is. centrifugo features include "History information for channels (last messages sent into channels)" what should work as a "mailbox".
I've explained the project in more detail here:

https://news.ycombinator.com/item?id=17798756

But the main problem with this is that the users will be non-technical and I think chat would be a bit of a confusing medium for the kind of communication we're trying to achieve.

While I certainly understand what you're saying: I disagree. Non-technical users can still learn how to use chat. It's very intuitive and it's a small jump from WhatsApp and SMS to chat.

That aside, there's something Linus once said that I love:

“If you think your users are idiots, only idiots will use it.”

Almost any NoSQL would fit your usecase.

For example, a mailbox matches the MongoDb Collection model well.. it's a file on a disk (so there is no outer index on username needed - filesystem will do it) and you can specify which inner index(es) you would like, probably time. Storing auto-assigns internal 128bit uuids that you can use to refer to a specific message.

If you're allergic to mongo you can do this in pretty much any document store. Hell you can do it in a simple SQL table but you will have to deal with outer index (which may or may not be a problem for you).

So what's in the requirements that prevents you from using a trivial implementation? Where trivial is: db table (from_id, to_id, time, read_flag, deleted_flag, body) with one page that lists them and another that allows you to write them?
This is most likely your best option. You can also get pretty fancy with this implementation with very little extra work.
At this small scale it could probably be implemented in an afternoon. No need to pull in an external dependency for something so easy.
I like the low overhead of this, but I'm a sysadmin - not a developer. I've described the purpose of this system over here:

https://news.ycombinator.com/item?id=17798756

I'm really hoping that there is some "off the shelf" open source package that I can install.

Keep it on disk in MBOX format. Many languages have libraries for it.
Won't the UI will be a PITA if those 500 users have to message each other ?
I probably misunderstand but why not just install an SMTP+IMAP server and add RoundCube/SquirreMail or similar? This should take like 15 minutes to do.

Since you talk about phpBB it sounds like you just want something users can log on to and do it, not necessarily tightly integrated in something else.

I feel like I'm missing something.

I worry that running a mail server will confuse users. The use case is a website for connecting qualified "sensitivity readers" to authors. A good example of a similar service is here:

http://writeinthemargins.org/sensitivity-readers/

(although we will be funded through a government program and not charge either party). Note that they have deleted the google docs spreadsheet that they referred to as a "database". I suspect that having the real name and direct email address for their professional readers publicly available did not end well for them :)

If we have a setup such as you describe, it would accept sending to email addresses outside the "local" domain and then users would get bounce messages (silently failing would be just as bad). I need users to immediately see on login that this is not "normal" email. They should only be able to send messages to the users that they have been "connected" to as part of the application process.

It sounds like you need something like rocket.chat
All you would need is user accounts and a database. It should take about a day to build it. I can help you if you need.
Mattermost, and disable public/group channels.
I look into IRC or jabber. There is plenty of clients out there for them.
Is it mail that you're building (with attachments to messages), or a messaging platform? Not necessarily instant messaging, but say, the type of inter-user messaging on phpBB forums.

You may have some luck with looking for a messaging library of some kind, instead of a mail platform. Not too email based, not too IM based, and not too social.

Instead of paring down phpBB, something like discourse may be easier to pare down, or fit outright. https://www.discourse.org/

Still, if I was looking for a github project that was very clean and simple.. it might be a one table message queue solution for this, where it has date-time/from/to/content/status columns, I'd almost wonder if it wouldn't be quicker just to implement than to find something and integrate.

If there's any chance the messaging functionality had to grow, I'd try to find an xmpp based messaging library that had a message store in it instead of IM - this would give me a migration/upgrade path to other features, and standardize if needed.

Thanks for the detailed reply. I've outlined the purpose of the system briefly here:

https://news.ycombinator.com/item?id=17798756

I think attachments would be almost a requirement, given that users would need to pass manuscripts backwards and forwards (although I suppose encouraging people to use google drive instead is not out of the question).

I had a look at Discourse, but it seems heavily geared towards forums rather than 1 to 1 email.

Your other suggestions require a bit too much development for my skill levels (I'm a sysadmin, not a dev).

You are looking for the word "database" and use that with an api.
Please just use an off the shelf system even if you disable a large part of it like with phpBB.

It sounds simple to reimplement, but you don't consider all the inevitable extras like user management, formatting, drafts, image uploads, notifications, backup/restore, etc, etc.

Don't get stuck on an inferior solution because you didn't want 3MB of unused code on your disk.

I'd recommend the opposite. Start with small system even if it doesn't implement what you need; complex system with unnecessary bells and whistles will at least take efforts to learn to configure (disable) properly.
Why though? Reduced attack surface?

Few care that Excel/GSheets/OCalc are huge beasts with tons of functionality that the typical user won't need. It's easier just to give people a powerful and well known product than to try to find something that doesn't do more than strictly required.

hmailserver is what you want. Sadly, it's Windows only, but you can easily spin up a windows vm under VirtualBox.