Plan to maintain this repo?

[pierreozoux]

Hi,

I'm actually doing the same (maiking mailinabox docker compose frinedly). I have several questions:

• do you use it yourself in production?
• what is your plan to maintain it in sync with the original repo?

Thanks!

Pierre

[djmaze]

Hi @pierreozoux, sorry for my late answer. Would have answered much earlier, but got my GH notifications messed up ;/

In general, no, I was only testing this on a subdomain for some time. I was planning to maintain this and update it with every release of mailinabox. That said, I was in the middle of an update to 0.11 before I got distracted. I would really like to get this going again, as I really have a need for this for my own use.

The major pain point is keeping up with all the changes in the management interface. I was struggling on doing this without going through every commit.

As some time has gone since your post: do you have anything done already? Would probably make sense to join forces in this!

[pierreozoux]

Yeah, I did my own at the end: https://github.com/indiehosters/email

I'd be really happy to collaborate :) I use it in production, and it is fine so far :)

I plan to add a webmail also, soon in the future (something like roundcube).

What do you think?

[djmaze]

Great! I see you are avoiding the update mess by using ViMbAdmin. That's probably a good idea, as it should be much easier to maintain in the long run. I guess it has most of the features MIAB's admin interface offers?

You made a different design decision concerning container granularity, by using supervisord in the Postfix image. This is a reasonable choice, as those services are connected very closely. From a security standpoint, I like the multiple-container approach more. (I am a proponent of the "one service per container" principle.)

Also, I couldn't find spamassassin. Is there no spam filtering yet?

That said, I will have a closer look at your project. Will probably make sense to join instead of maintaining my own one ;)

[pierreozoux]

I choosed ViMbAdmin because I thought MIAB is not really made for multidomain/multiadmin management.

About the granularity, I want to use one service per container :) (Look at the todo list) So it is work in progress ;)

I didn't have time yet to put spam assasin, but it is just a matter to add it.

Yes, let's join forces, I'd be happy to work on that with you. Tell me if there is anything I can do to bring this project closer to you :) I'm available on freenode #indiehosters if you need.

My main problem is to mainaint this up to date with MIAB codebase. Do you have any idea to make it better?

[djmaze]

I think the only sane way to keep up with the changes is to do a diff on a release-to-release basis. And then try to incorporate those patches which make sense.

That said, it will probably always be tedious work, as the Docker setup is quite different.

[pierreozoux]

We could also lobby miab to make the script better to use in Docker. One thing would be great is to separe:

• main configuration (Dockerfile)
• runtime configuration (entrypoint.sh) And make some stuff options, like firewall(they already did it for the all in one Dockerfile).

One thing for us also could be to make a base image, where we install all miab. And then we have various Dockerfile based on this one with an entrypoint.sh that would replace example.org in conf, and start the right service.

What do you think?

[djmaze]

We could also lobby miab to make the script better to use in Docker. One thing would be great is to separe:

main configuration (Dockerfile) runtime configuration (entrypoint.sh) And make some stuff options, like firewall(they already did it for the all in one Dockerfile).

Getting MIAB to split configuration into a main and runtime part would be a helpful first step, I agree. We should probably do some PRs so they can see the benefit right from the beginning.

One thing for us also could be to make a base image, where we install all miab. And then we have various Dockerfile based on this one with an entrypoint.sh that would replace example.org in conf, and start the right service.

So, build just one big image with all services installed? That would probably work. Rebuilding the image when something has been updated will be take much time though.

Also, I like the idea of having reusable images (like postfix) which can be used by other projects (or in simpler configurations) as well.

[adrian-moisa]

Years later I visit this repo. Sad to see it never took off. Could have been something...

[djmaze]

Yeah, maintaining a complete mail server stack as a side project is just too much work.

I can warmly recommend mailcow: dockerized though! (Which is what I am using nowadays.)