It’s true, some people want additional features on their mails-in-a-box. I’ve seen two threads here, no doubt there are more:
enable clamav
allow php hosting
The forum has instructions for these, but they’re a little obscure and tend to require some hand-tweaking each time you run mailinabox. And, if you go there, you’re on your own.
What about allowing mail-in-a-box plugins? That way everyone using the plugin could share the same codebase and support channels.
Plugins wouldn’t exactly be desirable… I see them more as a necessary evil. At least they’d be easy to enable, disable, and configure, and they’d have their own issue trackers.
I’m definitely not volunteering @JoshData to write this, just gauging whether it’s a decent idea, and whether support would ever be merged.
Personally, I’d be inclined to write a plugin for Nylas N1 to try it out…
I like the idea of plugins… there are a number of things I’d like to change in MIAB that I know wouldn’t be accepted into the mainstream - like switching it to mysql and enabling user-specified blacklists, aliases, whitelists, etc.
But since it is an enitre distro I’m thinking the only sane way to do it would be some type of drop-in actions for the installer to run at the end to make your changes. And then maybe a separate system for the admin web interface.
I want everyone to run the exact same thing. I just don’t have time for a project where everyone’s got a different setup — I barely have enough time to manage this project as it is.
I hear that. I think it’s one of MIAB’s biggest benefits over things like Sovereign.
It seems like a few miab users are hand-tweaking things they might not fully understand (under guidance of forum posts even), then coming here and asking questions implying that they didn’t do anything. : )
If they were using a plugin, they could just disable it before asking for support.
Therefore, plugins seem like the lesser of two evils to me… But, if you disagree, then I certainly defer to your judgement.
@phareous, why do you want to switch miab to mysql? That sounds like a fair bit of testing and effort for zero functional benefit.
Doesn’t mean you have to support people with plugins. Just say if they want support, they must run vanilla and not use plugins. But for those who want to run them, it gives a way to let people make customizations without having to fork and losing future updates. Not everyone has the same needs… I think its a bit impossible to have a one size fits all approach
@bronson, with a database you can have user-specified whitelisting for spamassassin, user-specified blacklist on postfix, and user-specified mail aliases (that can be set to expire after a certain amount of time). You could do some of this with text files but have major issues with file permissions from different users. Also its not just having a database, its having the ability to make customizations.
I used to have all of this on my own mail server and wrote all of that code myself. I also had code that would clean out spamboxes after a certain amount of time, code that would train spamassassin when you dragged emails into a folder, etc. But I can’t do that now without basically forkling it and being stuck with the version I am on today (or manually merging my changes in everytime a new version of MIAB is released).
Oh sure, I understand wanting a database. That seems like the sort of thing that’s worth integrating into MIAB proper, no?
Last week I played around with converting to LDAP. Turns out it was not bad at all, surprisingly easy. The setup scripts are pretty declarative and literate – easy to read and modify. I only stopped because I forgot how much I loathe LDAP and its baggage… I’ll integrate gitlab using something – anything – else.
I would guess that, if you demonstrated a compelling use case for a database, solidly integrated into MIAB’s admin console, you’d see some traction. I don’t think you’d have any trouble keeping your own fork, continually merging MIAB’s changes in. It isn’t like it’s seeing 15 commits/day. : )
So I say go for it, but do it as a fork with the intent of stabilizing it and merging it upstream one day. I’d use it.
I can’t really imagine a circumstance where I’d want to drop sqlite. So, the thing is, I’m just not trying to build something powerful. It’s not something I care about (and, again, truly lack the time to get myself into). I also think it’s unwise for the future of the project to make things more complicated than they are now — the project has plenty of issues now that aren’t being solved and adding more makes little sense to me.
If you want to make a heavyweight version of Mail-in-a-Box, go for it. I love to see my stuff used as infrastructure that others can build on. That’s part of the explicit purpose of this project. But as things are here, I just don’t see databases and more advanced web hosting in the future of this project. (Antivirus scanning yes - that’s plausible.)
Curious, what are the immediate issues you’re seeing that are going unaddressed?
Agreed, more complexity is wrong. Database for the sake of database will never happen.
But if some clean and well-tested features show up that require a database…? Well, I guess we’ll see when the time comes. I’d like to be a part of that discussion.
Even if it never gets merged, maintaining your own fork of MIAB is pretty easy for anyone who is familiar with git merging and remotes. I say write it and see what happens!