Allow user to overwrite config using $STORAGE_ROOT/mailinabox.conf

[bilogic]

Based on comments from #2349 (comment), this PR attempts to provide a convention on how mailinbox determines its configuration

1. mailinbox comes with defaults stored in /etc/mailinabox.conf
2. Everything in 1 can be overwritten by defining it again in $STORAGE_ROOT/mailinabox.conf
3. Backwards compatible If $STORAGE_ROOT/mailinabox.conf does not exists

To make it easier for the reviewer(s),

• All code changes are found in a7beb72, which tries to read from $STORAGE_ROOT/mailinabox.conf into DEFAULT_xxx

I hope this can be accepted so that I can further proceed with introducing a configurable TTL and DKIM_SELECTOR

#2352
#2383

[jvolkenant]

What is the purpose of having multiple files?

additionally, there are dozens of uses of /etc/mailinabox.conf in the codebase that would not use changes in $STORAGE_ROOT/mailinabox.conf.

Syntax changes to code only masks git blame's and are likely not needed in a change to $STORAGE_ROOT/mailinabox.conf

[bilogic]

What is the purpose of having multiple files?

For a lack of better word, I will call it layering (or inheritance), the algo goes like this:

• read /etc/mailinabox.conf as default, out-of-box (OOB) settings
• customize OOB settings by overwriting with whatever is inside $STORAGE_ROOT/mailinabox.conf

VSCode loads its settings this way, and I found to be very flexible for all kinds of use cases
And it is easy to tell what are the defaults, and what the user has changed

additionally, there are dozens of uses of /etc/mailinabox.conf in the codebase that would not use changes in $STORAGE_ROOT/mailinabox.conf.

Thanks for pointing this out, I missed it.. downside is, this PR not going to work

Syntax changes to code only masks git blame's and are likely not needed in a change to $STORAGE_ROOT/mailinabox.conf

Ok, I will omit them in future, but ideally we can pick a code formatter, this will allow folks like me to PR more easily and does not affect those who don't use a code formatter

[bilogic]

@jvolkenant

I had a quick look, only utils.py needs to have a slight change in logic and all *.sh references are

source setup/functions.sh # load our functions
source /etc/mailinabox.conf # load global vars

I believe this can be solved by combining load global vars into load our functions (and global vars)

Before I proceed, are there any other concerns about this approach?

[dms00]

There are a lot of changes here that appear to be formatting changes and have nothing to do with the subject of the PR. I'm not saying any of these formatting changes are bad, just suggesting that they belong in a separate PR. The more changes there are, the harder it is to review the PR, and especially after the recent XZ incident, I think reviewers have to be extra diligent about every character change in a PR. So, I'd like to see this PR with just the changes necessary to accomplish its goals.

[bilogic]

@dms00

Yes I agree that it breaks the blame part, a discussion here https://github.com/orgs/community/discussions/5033 led to GitHub's solution here https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view, so I will be taking out the formatting commits into another PR.

Apart from the formatting changes, are there other concerns? I appreciate an explicit No further concerns as the time I spend on each PR is fairly high, don't want to keep redoing it.