Then you should go for it.
Yes, I would greatly appreciate help with my attempt to add external authentication to MIAB. [hint hint]
There’s no reason Mail-in-a-Box shouldn’t be used for business purposes — there’s nothing specific about Mai-in-a-Box that precludes its use in a serious or commercial way.
But it is not an enterprise product for a large organization, and we’re not trying to make it one.
I think quotas are useful because in any environment disk usage should be monitored. But LDAP integration is not something that would occur outside of an enterprise environment, so I don’t think I would accept any changes along those lines.
The only reason I suggest LDAP is that it is the most supported standard for authentication, and that would allow for plug-n-play between mail-in-a-box and other applications. The other thing is that Mail-in-a-box has a very simple (yet can be disappointing) system for handling users.
It would be nice to have username, password, then optional fields under it: firstname, lastname, personal email, and any other attributes that might be desired, to be associated with the user to be created. Oh yes, groups! Groups, groups, groups with permissions!
But projects like this start simple, then they build up. Rome was not built in a day. I want to get around to doing external authentication, first.
Not always true, using openldap instead of sqlite for authentication has many benefits I think. For example: SSO for the different applications that MIAB offers would be nice. Also the ability to move away from SQLite since it has issues with a lot of users (unless the large user base issue was resolved or was caused by something else?)
If SQLite has performance issues, then it needs indices. There is no way LDAP is faster than SQLite properly configured.
I will also add that LDAP is rather difficult to manage. Years ago, I worked with OpenLDAP within a small business. It was a pain to get up and running along with keeping up with the management. I tried something similar to MiaB a while back that did include LDAP out of the box. I was trying it out and as soon as I made some changes to the domain, it stopped working and recovery was more complicated than it was worth. Finding MiaB was a huge relief since it kept the user model simple.
Sometimes configuring an application that consumes it isn’t too bad but applications sometimes use different schemas so it’s not a foregone conclusion that you’ll get what you want from it. If you don’t, you’ll need to learn the LDAP query language to do so.
For friends and family or a small company, MiaB’s model is perfect. There are some tools that aren’t too hard to integrate. For example, there is a script that will allow ejabberd to authenticate against nextcloud.
Of course, that doesn’t get to the core of what Eliter really wants. It’s not a shared log-in as much as it is Single Sign On. That’s possible with Kerberos, but that comes with a whole other level of difficulty.
If external authentication and/or user sync are possible, that’s the direction I personally prefer.
I love the quota’s included in your fork, thank you.
But, I have to ask … what if someone wants to revert BACK to the original MiaB? Can that easily be done? What would be the procedure?
Thanks again for this modification.
If I had to guess (pure speculation) running the installer for official MIAB would revert the changes.
This topic was automatically closed after 61 days. New replies are no longer allowed.