Exim configure file - shall we maintain it?

[runout-at]

I split this discussion out from #282.

What we have so far:

@rimas-kudelis

I'm also tempted to drop the configure file, since it was written who knows how long ago, we update it to account for changes in Exim only every so often, and it can only be seen as a template anyway, but that's a point for a different discussion.

@kaluang

But I'm strongly for keeping and maintaining the configure file. Exim4 routers and transports are complicated and long. It is not trivial to install Vexim, for every new instance I still use an old step-by-step guide from a website that is only still available via archive.org in addition to my plentyful notes about changes and updates. If we want any new people to be able to use Vexim we should definitely keep the configure file and keep it updated.
I think the current version does still work as intended, besides the small changes to the Mailman router I mentioned #233 (comment). The vexim-acl-check-*.conf-files are outdated though, they need some rework.
I'm also strongly for keeping and maintaining the Mailman2 routers and transport. If you don't want it in the configure file maybe we can put them into a seperate file or just as a readme. Same goes for MLMMJ and Mailman3. We should make it as easy as possible to start with Vexim if we want it to have some future.

@runout-at

For Exim configuration I prefere the Debian split config as it is much easier for me to handle it and it won't break easily on Exim upgrades. However, Debian will build the full configure file anyways so it should be easy to provide that too.
I'd be happy if we will provide at least some Vexim related files for the split config. It should be easy to merge those into a monolithic config file.

[rimas-kudelis]

I personally would prefer to keep a set of patches to the stock config file, and/or a patcher script, instead of a copy of said stock config file with our patches already applied.

Exim may introduce new and useful features over time, and may deprecate or change some existing functionality (like already happened in #232, for example). When that happens, we're kinda being thrown in a limbo, because for a while, that means that the Exim versions we can work with have different features and may need to be configured differently. And I think this especially becomes more burdensome than useful when these things aren't directly related to virtual hosting.

Furthermore, a lot of these things are not directly related to virtual mail hosting per se, but are things that can be useful in general.

For Vexim, I think it would make sense to ship only the snippets that are directly related to multi-domain virtual hosting. For example:

Feature	Should provide?
domain-specific mailboxes	yes
domain-specific TLS certificates	yes
automatic rejection of potentially harmful content (configurable per domain)	yes
automatic rejection of potentially harmful content (regardless of the domain)	no
mailing list software integration (assuming we have means to toggle this functionality per domain)	yes
mailing list software integration (where we have no means to toggle this functionality per domain)	no

The last four rows in this table should say everything about my vision. :)

@runout-at

For Exim configuration I prefere the Debian split config as it is much easier for me to handle it and it won't break easily on Exim upgrades. However, Debian will build the full configure file anyways so it should be easy to provide that too.
I'd be happy if we will provide at least some Vexim related files for the split config. It should be easy to merge those into a monolithic config file.

I think a Debian-like split config would be awesome. And it's much easier to build a monolitic file from split config than it is the other way around. We could provide a simple shell script for that. I mean, all you have to do is concatenate these files in order, what could be easier, right?

But this doesn't solve the problem that our config could become outdated (or too "updated" for some) at any point in time. Furthermore, even by default it's already huge enough. If we start adding hooks specific to various mailing list software, virus scanners, spam checkers etc, it will only become bigger and more difficult to maintain. Which is why I think a fully configured out-of-the-box experience, or a friendly configuration wizard should be a goal of a different project/repo than this one. Like I mentioned elsewhere, there's the Exim4u project which strived to do something like that, but still it seems like their main means of installation was following a README guide, not a "turnkey solution".

I see a few strategies we could employ to provide such "turnkey solution":

1. create a mailserver-oriented "Debian flavour" (some may complain that it's not SuSE or FreeBSD or whatever else they prefer to Debian).
2. or a deploy-ready monolitic Docker image with all services preinstalled in it (not really the "Docker way", I think)
3. or a set of Docker images grouped via Docker Compose or Swarm or Kubernetes or whatever (I love Docker Compose, but I've mostly used it for local development and have no proper experience with running it in production)
4. an installer script (which would either be very distribution-specific, or quite complicated due to the specifics in each distro; per-distro scripts also an option, but then we get to duplicate a lot of stuff in them, or just generate them from that same complicated if-distro-elseif-distro-else-endif mess).

But again, I think these strategies could be explored in a separate repository (or multiple repositories).

BTW, I just tested out a fresh Debian installation in a VM and it looks like Debian actually defaults to non-split config now (when it asks if you want it split, No is the button that is selected by default). Their debconf wizard also explains pros and cons of both approaches in short. They say the monolitic config is better for big changes, and split config is better for small ones. Not sure if I agree with such assessment though. 😄

[runout-at]

I agree with

• split config because of easier maintainance
• separate repos for frontend and other functionality. maybe even for the Vexim database as we have at least 2 frontends by now.
• only caring about virtual domain/user stuff.
• additional repos/subrepos for things like installer, Exim-Distro,...

I don't like docker, so I'm not happy with that. If somebody creates an container image this is no problem for me - but only additionally to the non-container-version which should have priority.

[runout-at]

Maybe we should remove the Mailman section from the README as most of this might not work for MM3.

Should this be moved to the Wiki and be linked in the README? Some people might still use the old MM2.

[rimas-kudelis]

I agree with

• split config because of easier maintainance
• separate repos for frontend and other functionality. maybe even for the Vexim database as we have at least 2 frontends by now.
• only caring about virtual domain/user stuff.
• additional repos/subrepos for things like installer, Exim-Distro,...

Would you be willing to work on splitting the config, or extracting only its relevant bits?

I don't like docker, so I'm not happy with that. If somebody creates an container image this is no problem for me - but only additionally to the non-container-version which should have priority.

I believe Docker is amazing for local development. It doesn't have to be the only supported way to run Vexim though.

Maybe we should remove the Mailman section from the README as most of this might not work for MM3.

Should this be moved to the Wiki and be linked in the README? Some people might still use the old MM2.

Agreed, Mailman 2 stuff could be moved to the Wiki.