Mail-in-a-box Core

[matidau]

But taking over a year to get this merged seems a bit excessive, I was thinking perhaps it is time to have a mail-in-a-box core which is really just DNS + SMTP + IMAP and everything in /admin, with PHP and everything else as an add on

This way we can take core and add on what we need ourselves, easily.

Originally posted by @bilogic in #2309 (comment)

[bilogic]

Thanks, for core, that would be the retain section, but I now believe the delays are due to the lack of unit tests, i.e. having a core would have limited impact

List of releases that had to be patched

• 71a
• 69b
• 69a
• 60.1
• 57a

Retain

• SMTP (postfix), IMAP (Dovecot)
• Spam filtering (spamassassin) and greylisting (postgrey)
• DNS (nsd4) with SPF, DKIM (OpenDKIM), DMARC, DNSSEC, DANE TLSA, MTA-STS, and SSHFP policy records automatically set
• TLS certificates are automatically provisioned using Let's Encrypt for protecting https and all of the other services on the box
• Backups (duplicity), firewall (ufw), intrusion protection (fail2ban), and basic system monitoring (munin)

Remove

• CardDAV/CalDAV (Nextcloud), and Exchange ActiveSync (z-push) servers
• Webmail (Roundcube), mail filter rules (thanks to Roundcube and Dovecot), and email client autoconfig settings (served by nginx)

[matidau]

We already discussed this a while ago on Slack, btw. Did you follow the discussion there?

1. I cannot join slack and I think the button was broken since 2018 https://discourse.mailinabox.email/t/how-to-connect-to-slack/3908/7
2. Briefly, I believe the slowness is due to several regressions faced
   • 71a
   • 69b
   • 69a
   • 60.1
   • 57a
3. Which means my earlier suggestion of a core (mailinabox without PHP and others) is unlikely to make a difference
4. It is a very dreadful feeling wondering if making a release today is going to incur wrath for the next few days/weeks
5. The only solution I'm aware of is unit testing, but there is a mixture of bash and python
6. If there is interest, I suggest we start an issue (since there is no discussion on this repo) titled Improving release/deployment speed
7. This will be my last post here as I really don't wish to pollute this conversation any further

@bilogic there are links that are posted every now and then in the discussion forum that let you join slack.

Example:
https://discourse.mailinabox.email/t/slack-is-down-padding-title-to-15-characters/12482/2

Try this one:
https://join.slack.com/t/mailinabox/shared_invite/zt-2zlpde2wn-PWU5Jvw3CDGF6una3Q1YFw

As for the other points I'll leave them as a discussion starter 😊

[matidau]

From the readme.md

It is a one-click email appliance. There are no user-configurable setup options. It "just works."

I think a webmail client and to a lesser degree carddav and caldav fall into the just works aim. I'm biased towards keeping Z-Push so won't make arguments to include activesync.😊

There are a few threads that cover removing various parts or alternatives for, the ones I find relevant are:

#1745 Only use MIAB for Mail, disable owncloud
#1646 Make Nextcloud optional
#2164 Cal/CardDav Alternatives
#883 Replace Roundcube with Rainloop

And this thread from the last major upgrade:
#2083 (comment)

6. If there is interest, I suggest we start an issue (since there is no discussion on this repo) titled Improving release/deployment speed

Happy to rename the title for this and update the description, or for another one to be raised.

[bilogic]

Hmm I think retain/remove is less important because it is not the fundamental problem.

After looking at the release records, I would point to the DORA metrics https://dora.dev/guides/dora-metrics-four-keys/

1. Change lead time - basically end to end on when PRs are opened until feature is released, we have some well over 2 years now
2. Deployment frequency - 6 mths on average, imagine where MIAB can be if it was released multiple times per day
3. Change fail percentage - as low as possible, but I listed quite a number in my earlier post
4. Failed deployment recovery time - 71a was 1 day, 69b was 9 days

Of course, I understand this is unpaid open source work, that's why I'm proposing a change in process to lighten the burden.
I'm looking at this https://github.com/bats-core/bats-core

Right now, I believe the most impactful move is to add tests.

[xxfogs]

Just to be clear, I am unsure how is "remove" to be interpreted within this issue. How would this "Core" version of MIAB even look like: would it be an official fork, an installation script option?

[bilogic]

When I suggested core, it meant this:

1. This repo is still /mailinabox but will pull/build on top of /mailinabox-core
2. The thing is, PHP has transitioned to a much faster deployment pace I believe thanks largely to Laravel
3. And with /mailinabox-core, it makes it easier for us to build alternatives to /mailinabox without being held back by its slow pace
4. I'm well aware that this /mailinabox is Not make something customizable by power users, and we are sticking to it
5. But the same will not be said for /mailinabox-core

[matidau]

Of course, I understand this is unpaid open source work, that's why I'm proposing a change in process to lighten the burden.
I'm looking at this https://github.com/bats-core/bats-core

This came up on slack recently

kiekerjan

I get that you take the end responsibility for the reviews. What I mean is, perhaps it's possible to lighten the load for you by giving other people the ability to close/resolve issues (if that's possible on github) https://mailinabox.slack.com/archives/C09E3L9KM/p1739362691827939

JoshData

I'm not opposed to giving more access, but access isn't really required to help. I can click buttons easily if someone starts to do those things.
https://mailinabox.slack.com/archives/C09E3L9KM/p1739372078623569

I took this to mean

1. Anyone can help review PRs and this would help.
2. The same with recommending issues and PRs to be closed, to clean these up.
3. Following on from 1 it might be a good idea when opening a PR to tag someone that isn't Josh that has previously reviewed or tested similar PRs, they may not do it but at least it is a bit proactive.

Right now, I believe the most impactful move is to add tests.

There is a PR #1455 for GitHub Actions CI with recent changes

And an older PR #777 starting a test suite that could build on the Github Actions

[mxts]

1. BIND9 (named), NSD
2. Python, Nginx /admin, duplicity, ufw, munin, 7 records (SPF, DKIM, DMARC, DNSSEC, DANE TLSA, MTA-STS, SSHFP)
3. Postfix, Dovecot, LE SSL
4. spamassassin, postgrey, fail2ban
5. PHP, Nextcloud, z-push, Roundcube

This is how I will probably cut it up, 1-3 or 4 being at the core
With 2 and onwards being dockerable