See suggestion in #1396. Can we amend it that way? Also I don't want a warning when SPAMASSASSIN_SPAM_TO_INBOX=0, it is a perfectly legitimate setting. You can show the warning when SPAMASSASSIN_SPAM_TO_INBOX has not been set (which should default to 0 for backwards compatibility) though. Then people who have not made up their minds will see it and make an informed selection.

You can show the warning when SPAMASSASSIN_SPAM_TO_INBOX has not been set (which should default to 0 for backwards compatibility) though.

I agree with you.

Current default value is 0.

DEFAULT_VARS["SPAMASSASSIN_SPAM_TO_INBOX"]="${SPAMASSASSIN_SPAM_TO_INBOX:="0"}"

Any idea for getting the original env value without (proper way) default assignment? :=0

If SPAMASSASSIN_SPAM_TO_INBOX=1 is the default configuration, this is right, there is no need for a warning, because the user made the change himself after reading it. If not the default value, you can keep warning message.
However, I think you should have kept the original configuration and PR #1484 in the start-mailserver.sh file, as it allows you to keep the modification of the 20-debian_defaults file in case the 49-docker-mailserver file is not present (Update from previous version by keeping its configuration files, which is my case for example).
This allows to keep the banned_destiny configuration, and to display an error if a configuration in 50-user makes SPAMASSASSIN_SPAM_TO_INBOX unusable, in this case, it is better to disable this value if other functions use this value to modify the operation.

@youtous No modification in this file, only in env-mailserver.dist. Previous users will keep their configurations. #1488

Your forget to also create Junk directory if not exist on file target/dovecot/sieve/before.spam.sieve

As the tests show, no need to create a directory.

modification of the 20-debian_defaults

20-debian_defaults should be left untouched.

in case the 49-docker-mailserver file is not present

User updates must be done using 50-user (https://github.com/tomav/docker-mailserver/blob/master/target/amavis/conf.d/49-docker-mailserver#L3), there is no reason for 49-docker-mailserver to be missing in a normal usage (correct me if I'm wrong).

display an error if a configuration in 50-user makes SPAMASSASSIN_SPAM_TO_INBOX unusable

Isn't 50-user made for overwriting changes made in previous configurations?

If SPAMASSASSIN_SPAM_TO_INBOX=1 is the default configuration, this is right, there is no need for

SPAMASSASSIN_SPAM_TO_INBOX is set to 0 by default. A warning will be raised if SPAMASSASSIN_SPAM_TO_INBOX is not explicitly defined.

See suggestion in #1396. Can we amend it that way?

Implemented behavior regarding SPAMASSASSIN_SPAM_TO_INBOX:

• SPAMASSASSIN_SPAM_TO_INBOX=0 (default), spam messages are bounced (current behavior)
• SPAMASSASSIN_SPAM_TO_INBOX=1, spam messages are delivered and eventually marked as spam (according SA config)
• SPAMASSASSIN_SPAM_TO_INBOX not set:(value =0) raise a warning asking user to explicitly confirm the desired behavior, spam messages are bounced (current behavior).

Are you ok with this @erik-wramner?

This looks fine. Unfortunately I merged the other PR first and I'm not allowed to resolve the merge conflict. Can you rebase and just keep your changes, please? Then I'll merge.

Rebase completed, tests are running.
#1484 can be closed.