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 https://github.com/mail-in-a-box/mailinabox/pull/2309#issuecomment-2799408314

[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: https://github.com/mail-in-a-box/mailinabox/issues/2083#issuecomment-1118477445

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

[JoshData]

Folks,

I apologize that I haven't been able to put more time into this and I realize I am a bottleneck.

Removing features isn't a great solution because existing users actually use those features. I think Roundcube is extensively used. Stranding them without a future is similar to ending the project entirely, from their perspective.

I would be fine with removing DNSSEC and DANE, for example. I don't think those benefit anyone (unfortunately). But they also have not contributed to significant maintenance time.

I don't have any issues with a fork, by the way. As long as there's no confusion that it's a separate project. But because of the security implications of email, this project could not recommend a fork to users. So removing features here and adding features in a fork won't really solve the problem that the features would be removed for existing users.

I would like to get this project over the hurdle of migrating to Ubuntu 26.04. That's probably the only major change that we'll be able to manage in the next year. After that, I will probably start to think about how to wind down the project, unless I somehow find myself with more free time, which seems unlikely unless U.S. politics turns around.

[mxts]

1. My aim was to separate the email security from others, so I would ask does 4 and 5 contain any email security concerns?
2. Could we also define "email security"? I would think there is only spoofing which can stem from bad DNS config, open relay etc
3. Also, what is not considered as "email security": receiving lots spam, PHP security issues due to not upgrading

Once that is clear, this package can focus on maintaining email security (smaller group of trusted members), while the separate project (which is not a fork, let's call it part 2), takes on the end user side of things, i.e. which email client, spam filters etc

In fact, anyone is free to start their own part 2, and we let market decide the winner (which then gets mentioned, not recommended) by this repo, the mail-in-a-box core.

[myfirstnameispaul]

With 2 and onwards being dockerable

How does Docker impact memory usage of MiaB?

[mxts]

it's quite neligible, the keyword here is isolation rather than virtualization

[JoshData]

2. Could we also define "email security"?

The main issue I'm talking about is that access to someone's incoming email can be used to gain access to online accounts through password resets. Spoofing of user's outgoing messages is another concern.

[JoshData]

... The reason I bring this up is that people have put a lot of trust into this project to manage their email. Ultimately, that trust falls on me. And so I take the security implications very seriously. If we mess up, not only does their email become vulnerable but also potentially large parts of their online identities (via password resets on other websites). When we're talking about forks and parallel projects, I cannot --- ethically --- hand over that trust to other people. That's why I say this project can't endorse other projects. I can't tell people to install something that doesn't have at least as much trust as I do. Even though at the same time I would love to see forks and parallel projects exist.

[mxts]

The main issue I'm talking about is that access to someone's incoming email can be used to gain access to online accounts through password resets. Spoofing of user's outgoing messages is another concern.

Ok, I don't recall ever reading this, but it is very valid and involves 5 (PHP, Nextcloud, z-push, Roundcube)