Ask HN: Non-SMTP single server internal mail system?
42 comments
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?
At this small scale it could probably be implemented in an afternoon. No need to pull in an external dependency for something so easy.
This is most likely your best option. You can also get pretty fancy with this implementation with very little extra work.
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.
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.
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.
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.
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.
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.
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.
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.
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 "[email protected]". 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".
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 "[email protected]". 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".
Sounds like a usecase for
https://github.com/centrifugal/centrifugo
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.
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.”
That aside, there's something Linus once said that I love:
“If you think your users are idiots, only idiots will use it.”
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".
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.
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).
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).
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 ?
This is why I use Django :)
Not one option, but at least 14: https://djangopackages.org/grids/g/messaging/
Not one option, but at least 14: https://djangopackages.org/grids/g/messaging/
Thanks!
Looks like django-messages might be what I need (although they don't say if they support attachments).
Looks like django-messages might be what I need (although they don't say if they support attachments).
This is a bit old (2013), but may be of interest for you:
http://dangoldin.com/2013/05/17/adding-attachments-to-django...
Good luck!
edit: also, modern and maintained: https://github.com/bartTC/django-attachments
http://dangoldin.com/2013/05/17/adding-attachments-to-django...
Good luck!
edit: also, modern and maintained: https://github.com/bartTC/django-attachments
Something like this?
http://deadsimplechat.com/
Code here:
https://github.com/mlakkadshaw/SImple-Chat-Server
http://deadsimplechat.com/
Code here:
https://github.com/mlakkadshaw/SImple-Chat-Server
As per my comment here:
https://news.ycombinator.com/item?id=17798834
Chat would not really be an appropriate solution.
https://news.ycombinator.com/item?id=17798834
Chat would not really be an appropriate solution.
I don't think this helps you with your 'web' requirement, but IIRC Pegasus Mail[1] doesn't use SMTP internally ...
[1]: http://www.pmail.com/index.htm
[1]: http://www.pmail.com/index.htm
These two might be worth looking into:
https://sendbird.com/ https://pusher.com/chatkit
https://sendbird.com/ https://pusher.com/chatkit
Sendbird looks very "app" centered and Chatkit has the problems with chat that I outline here:
https://news.ycombinator.com/item?id=17798834
https://news.ycombinator.com/item?id=17798834
How about xmpp?
Could you clarify if those users interact with the same server or backend database, or if they need to communicate through distinct servers ?
Is it for a web application ?
Is it for a web application ?
You might want to consider tinode/chat (https://github.com/tinode/chat)
I've outlined more detail here:
https://news.ycombinator.com/item?id=17798756
https://news.ycombinator.com/item?id=17798756
If you're already considering setting up a separate system for this, you probably don't need to send in-app messages. Why not use Slack?
Reasons for not using chat here:
https://news.ycombinator.com/item?id=17798834
https://news.ycombinator.com/item?id=17798834
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).
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).
Mattermost, and disable public/group channels.
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.
You are looking for the word "database" and use that with an api.
I look into IRC or jabber. There is plenty of clients out there for them.
It sounds like you need something like rocket.chat
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?