Docker-mailserver: amavis uid does not match ownership of /var/mail/amavis

[MakerMatrix]

I'm enjoying my shiny new mail server. Thank you, it's terrific. I almost went with mailu but quite by accident landed here.
In hindsight that was a great thing.

I was perusing the logs this evening and ran across this:

(cannot update mailbox /var/mail/amavis for user amavis. destination /var/mail/amavis is not owned by recipient)

And, indeed:

root@mail:/var/mail# id amavis
uid=112(amavis) gid=114(amavis) groups=114(amavis),110(clamav)

root@mail:/var/mail# ls -la /var/mail/amavis
-rw------- 1 docker docker 871 Dec 3 03:18 /var/mail/amavis

And from the host side:
-rw------- 1 5000 5000 871 2020-12-02 21:18 amavis

So I chowned it to 112. Not sure what if anything of interest will show up here, but I thought I should report it.

Related: Is there a lightweight curses-based mail client somewhere in the image? I'm thinking along the lines of pine, so I can manage that mailbox locally, and maybe even remote in for shell-based or scripted email.

[erik-wramner]

I think you can remove /var/mail/amavis and instead create an alias for the amavis account (using setup.sh), so that you get messages sent to amavis to your postmaster account or personal account. The system sometimes sends e-mail to amavis, primarily with warnings from cronjobs owned by the amavis user. Search the issues and you will find many similar cases.

As for pine, no. Most of us probably use webmail through Dovecot. If you want pine you can always mount the mail directory in another docker image that has pine, or by all means install it from user-patches.sh at startup.

EDIT: we should document the amavis alias in a more visible location.

[aendeavor]

@erik-wramner How come that this alias-amavis thing appears for some and not for others. For me, this seems like a bug, but reading through this, is seems like it isn't?

Nevertheless, I'm all with you when it comes to putting this in a more visible location. How about the _Miscellaneous_ section in the README?

[erik-wramner]

It appears only when the system needs to send a message to amavis. That only happens when something is wrong, but it does not have to be a serious problem. What happens is that Postfix (or Dovecot) creates a mailbox for the missing user, but it is created with wrong credentials and doesn't work. Probably a mismatch between local accounts and virtual. I'll see if I can add a note somewhere.

[MakerMatrix]

It looks like the system was sending a message about creating a spamassassin cron job?

Subject: Cron test -e /usr/sbin/amavisd-new-cronjob && /usr/sbin/amavisd-new-cronjob sa-sync

The main receive/smart relay functions are working for me now but there are still many things about the features that are unclear. For example, it seems from the above comment that we need to create the postmaster account (or alias) manually? Are there post-install setup docs somewhere that I missed? I will look harder. I'm used to defalt mail setups in full Linux distros that do the basics for you out of the box, need to learn about what to do "from scratch."

[aendeavor]

Actually, I was thinking the same @MakerMatrix. This step should be automatic, it possible. That's why I was surprised at first.

[MakerMatrix]

Maybe I will change this to a feature request.

Following the principle of least surprise, I believe there should be built-in aliases that map amavis, dovecot (I think I see the system trying to send mail to her also), and postmaster to root.

Then, bsd-mailx should be installed. It's only 200KB and a strong argument can be made that it should be installed by default on any appliance that claims to manage mail. This project attracts keyboard warriors and it is completely surprising when /bin/mail and/or /usr/bin/mail does not exist.

Every UNIX mail setup I've ever used was configured out of the box similarly to what I've described. I've made my argument. Tear it down ;-)

[aendeavor]

No need to tear anything down, you'd just need to provide a PR :D

I really like your idea and the changes, and I think you're right with what you're saying. A well reviewed PR can and will improve the current situation. I will make sure to review the changes when you're ready:)

[MakerMatrix]

Challenge accepted. I have a lot to learn about docker and github though, will you please try answer my inevitable dumb questions?

[aendeavor]

Of course, as good as I can.

[MakerMatrix]

Does building the project require an apt-based system? I am having issues on CentOS7.

[casperklein]

Any Linux host with docker installed should be fine.

[MakerMatrix]

The "make clean all" command dies with many dozens of "Cannot remove....:Directory not empty" lines and then:

The command '/bin/bash -o pipefail -c apt-get update -q --fix-missing && apt-get -y upgrade && apt-get -y install postfix && apt-get -y install --no-install-recommends altermime amavisd-new apt-transport-https arj binutils bzip2 ca-certificates cabextract clamav clamav-daemon cpio curl ed fail2ban fetchmail file gamin gzip gnupg iproute2 iptables locales logwatch lhasa libdate-manip-perl liblz4-tool libmail-spf-perl libnet-dns-perl libsasl2-modules lrzip lzop netcat-openbsd nomarch opendkim opendkim-tools opendmarc pax pflogsumm p7zip-full postfix-ldap postfix-pcre postfix-policyd-spf-python postsrsd pyzor razor rpm2cpio rsyslog sasl2-bin spamassassin supervisor postgrey unrar-free unzip whois xz-utils dovecot-core dovecot-imapd dovecot-ldap dovecot-lmtpd dovecot-managesieved dovecot-pop3d dovecot-sieve dovecot-solr && apt-get autoclean && rm -rf /var/lib/apt/lists/* && rm -rf /usr/share/locale/* && rm -rf /usr/share/man/* && rm -rf /usr/share/doc/* && touch /var/log/auth.log && update-locale && rm /etc/postsrsd.secret && rm /etc/cron.daily/00logwatch' returned a non-zero code: 1
make: * [build] Error 1

I'm stumped. CentOS 7 with the latest docker, docker-compose, etc. from the offical docker-ce repo.

EDIT: rm -rf is failing on /usr/share/doc/* and /var/log/clamav commands. It's a kernel bug with the overlay filesystem. I'll tackle that tomorrow.

[aendeavor]

Make is telling you two things here:

1. A command failed and make is unhappy, aborting early
2. The command that is failing is most likely not make

The /bin/bash -o pipefail apt ... is from the Docker Build process. I don't know why, but the build process for the Dockerfile fails. I would advise to go through the Makefile targets one by one, i.e. clean, build, ... and then see where things are getting rough.

To me, it also seems like the clean target has some issues, maybe just related to CentOS. What version of Bash have you installed? Maybe

clean:
    -@ [[ -d config.bak ]] && { ... ; } || : 

is not well-defined for Bash versions < 5. Or the sudo rm is posting the not empty errors. Hard to say.

[MakerMatrix]

Edit: I sorted out my docker on XFS without d_type support issue (had to switch to the devicemapper FS driver).

https://www.pimwiddershoven.nl/entry/docker-on-centos-7-machine-with-xfs-filesystem-can-cause-trouble-when-d-type-is-not-supported

Also got the submodules activated. So I can build it now but I do still get this error when the dovecot key gets generated though. Is that a concern?

---

Generating a RSA private key
.....................+++++
..................................................................................................+++++
writing new private key to '/etc/dovecot/ssl/dovecot.key'
-----
Cannot write random bytes:
140325556176000:error:2407007A:random number generator:RAND_write_file:Not a regular file:../crypto/rand/randfile.c:183:Filename=/dev/urandom

[aendeavor]

Most likely due to missing initialisation of all submodules. You will need to initialise all four with

EDIT: Didn't read the current version of your post. I will check how Dovecot behaves on my system shortly.

ANSWER: This should not be an issue, I'm seeing it as well but never had problems with it. Probably an error in a default setup routine for Docker images.

[MakerMatrix]

PR is #1709