Then you should go for it.
Yes, I would greatly appreciate help with my attempt to add external authentication to MIAB. [hint hint]
Hi all.
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.
Hey John,
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.