ClamAV reporting?

[GAS85]

Hey, just by incident I saw this entry in my logs:

2026-04-13T19:09:11.163427+02:00 mail postfix/qmgr[1216]: 5F6513C0968: from=<clamav@mail.sitnikov.eu>, size=854, nrcpt=1 (queue active)
2026-04-13T19:09:11.179619+02:00 mail postfix/local[626727]: 5F6513C0968: to=<clamav@mail.sitnikov.eu>, orig_to=<clamav>, relay=local, delay=176916, delays=176916/0.01/0/0.01, dsn=4.2.0, status=deferred (cannot update mailbox /var/mail/clamav for user clamav. destination /var/mail/clamav is not owned by recipient)

have anybody seen this? I clamAV docs I could not find any.

How to test if Clamav is working at all? I do send test EICAR virus mail, but it passed trough.

[polarathene]

This is for postfix/local, it is trying to send to internal account mail.sitnikov.eu (hostname / DMS FQDN), which is used for internal mail sent from services running in DMS.

• The domain-part is appended by Postfix when it receives mail only for a local-part address (the domain-part will be appended as the DMS FQDN through the Postfix setting myorigin which defaults to myhostname), so in your case the mail probably was sent to clamav (no @<domain-part>).
• If mail was received with the domain-part, it matches the Postfix setting mydestination configured in DMS (unless you've opt-ed out of our mydestination, then delivery would likely fail instead), which looks at the local-part (clamav) and checks that a system account exists (if there was a local-part only alias it would have been matched prior to this logic for mydestination / local delivery agent.

Postfix will store these in /var/mail directly, instead of sending them to Dovecot if you have not configured an alias (postfix-aliases.cf, no equivalent support in setup CLI) to map a system account to an account (postfix-accounts.cf, setup email add) or virtual alias (postfix-virtual.cf, setup alias add).

postfix-aliases.cf / "local aliases" are covered in the "Technical Details" section of our aliases docs.

You should be able to use postfix-virtual.cf/postfix-regexp.cf for virtual aliases that Postfix would give precedence to when matching, that would be before it even reaches the postfix/local delivery agent. Here's an example for aliasing any domain for postmaster local-part of an address to route mail to a specific email address (like your admin user).

---

System accounts

I know that amavis is another user account (spam related), while other internal mail is usually sent to the root user IIRC.

Postmaster alias

By default during container init DMS will also setup a local alias for root that forwards mail to a postmaster address/alias (the default value is inferred from your DMS FQDN and drops the first component so that an FQDN of mail.example.com results in postmaster@example.com. The linked script gets DOMAINNAME from the DMS script helpers/dns.sh, it is not a public ENV setting)

• It can be explicitly configured via the ENV POSTMASTER_ADDRESS.
• That ENV is also used to configure Dovecot with it's own postmaster_address setting.

That postmaster address if you're not familiar, is generally for other services or MTAs to contact the DMS admin about any issues with mail. It would likewise deliver mail to /var/mail/root due to the local alias added by DMS at container setup.

In our docs "Usage" guide, we have explicit advice to setup a postmaster virtual alias (setup alias add postmaster@example.com user@example.com), such that mail sent internally to the root user with our default POSTMASTER_ADDRESS value and that explicitly added alias would result in root => postmaster@example.com => user@example.com.

We also have a FAQ entry that similarly suggests adding a postmaster alias via setup alias add

---

Advised solution

You generally don't need to mess with postfix-aliases.cf, so our docs for the topic are lacking. With your report (thanks by the way), I am aware that you should probably include local aliases for amavis + clamav, these could likewise go to the postmaster address, or if you prefer an address that helps better separate/organize such mail (perhaps an alias with subaddressing?).

/etc/aliases will have our default root: ${POSTMASTER_ADDRESS} / root: postmaster@example.com entry, and anything you provide via postfix-aliases.cf will be appended to that, so you could do:

amavis: root
clamav: root

This will alias amavis + clamav users to the root user/alias, and as we've already configured a root alias for you to the postmaster@example.com address, all mail should go through that (assuming it's valid to resolve).

Then ensure you also have the virtual alias for postmaster@example.com to your preferred admin address to receive that mail.

[GAS85]

Cool! I do create postfix-aliases.cf as you advise and checked container aliases afterwards, it was updated.

docker exec mailserver cat /etc/aliases
root: postmaster@sitnikov.eu
amavis: root
clamav: root

Seems good for now. I also double check what was an email to clamav and it seems that was simply DB update error from long time ago:

docker exec mailserver cat /var/mail/clamav 
From clamav@mail.sitnikov.eu  Thu Sep 11 00:44:55 2025
Return-Path: <clamav@mail.sitnikov.eu>
X-Original-To: clamav
Delivered-To: clamav@mail.sitnikov.eu
Received: by mail.sitnikov.eu (Postfix, from userid 200)
        id 2250C60AE1; Thu, 11 Sep 2025 00:44:55 +0200 (CEST)
From: root@mail.sitnikov.eu (Cron Daemon)
To: clamav@mail.sitnikov.eu
Subject: Cron <clamav@mail> /usr/bin/freshclam --quiet
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/lib/clamav>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=clamav>
Message-Id: <20250910224455.2250C60AE1@mail.sitnikov.eu>
Date: Thu, 11 Sep 2025 00:44:55 +0200 (CEST)

ERROR: Thu Sep 11 00:44:44 2025 -> check_for_new_database_version: Failed to find daily database using server https://database.clamav.net.

[polarathene]

Yeah that cron job as I showed in my other answer was calling freshclam --quiet so it should only be outputting errors.

This command is just to update the database on a regular basis via cron AFAIK, I'm not sure how useful any mail from it will be beyond that, but I suppose in some cases it might at least raise awareness of recurring problem that might otherwise not be visible.

[polarathene]

This reply addresses the specific error you encountered and reproduces the problem identified. DMS could introduce a breaking change (unlikely to be part of DMS v16) to better resolve that, but configuring an alias such that mail is sent to your POSTMASTER_ADDRESS seems like the appropriate solution to go with.

---

cannot update mailbox /var/mail/clamav for user clamav. destination /var/mail/clamav is not owned by recipient

Regarding this part of the error specifically, it sounds like /var/mail is owned by root or docker (5000 UID/GID), and it's trying to write for clamav? If that's the issue then it might just require the clamav user to also belong to the docker group. Failing that it could be due to the /var/mail mount vs without one as I recall some specific settings were applied to /var/mail and that may have been lost when adding your own volume to that path, I think SGID may have been relevant there.

Typically all mail is handled by Dovecot usually as the only writer to /var/mail, but as explained in my answer post, there is the scenario of system accounts being delivered to /var/mail through Postfix alone via it's local delivery agent instead of virtual delivery agent (which Postfix then delegates to Dovecot via LMTP).

---

Cron task + mail sending behaviour

AFAIK this mail would be from the cron task configured to run freshclam --quiet as the clamav user:

# The DMS `Dockerfile` creates the scheduled task like so:
echo '0 */6 * * * clamav /usr/bin/freshclam --quiet' >/etc/cron.d/clamav-freshclam

cron varies in implementations across distros, this Debian cron article notes that "Vixie cron" is used as their cron package, but there are plans to migrate to cronie (used by RHEL and Fedora). The linked article details plans for the migration were targeted for Debian Bullseye (Debian 11, released Aug 2021), but AFAIK the switch to cronie hasn't occurred.

Additional Resources:

• https://manpages.debian.org/trixie/cron/cron.8.en.html
• https://manpages.debian.org/trixie/cron/crontab.5.en.html
• https://manpages.debian.org/trixie/cron/crontab.1.en.html

So we're still using Vixie cron, and as the manpages linked note:

• /etc/cron.d/ files are treated similarly to /etc/crontab, in that a user to run the task as must be included (as the example above showed with clamav)
• If there's any stdout/stderr output that will then be mailed to that configured user (as both from and to addresses, unless MAILFROM/MAILTO are configured to override).

Vixie cron also is compiled to use /usr/sbin/sendmail for the actual mail delivery command in Debian (where sendmail is a shim provided from Postfix).

Reproduction

$ docker run --rm -itd --name dms-test --hostname mail.example.test -v ./mail:/var/mail mailserver/docker-mailserver:15.1
# Shell into the container and add an account to complete setup:
$ docker exec -it dms-test bash
$ setup email add hello@example.test secret

# Wait a bit for setup to complete (5-10s), then test sendmail (from `root` to `clamav`)
$ echo "Testing delivery" | sendmail clamav

$ ls -la /var/mail
total 20
drwxrwsr-x 1 docker docker 4096 Apr 23 02:01 .
drwxr-xr-x 1 root   root   4096 Aug 12  2025 ..
-rw------- 1 clamav docker  420 Apr 23 02:01 clamav
drwxr-sr-x 3 docker docker 4096 Apr 23 01:56 example.test

NOTE: If the /var/mail volume wasn't mounted, instead you'd get the following (note the clamav group ownership, this is due to lack of SGID aka the s that has become x on the first line. SGID would ensure the original /var/mail group is preserved).

$ ls -la /var/mail
total 20
drwxr-xr-x 3 docker docker 4096 Apr 23 02:03 .
drwxr-xr-x 1 root   root   4096 Aug 12  2025 ..
-rw------- 1 clamav clamav  420 Apr 23 02:03 clamav
drwxr-xr-x 3 docker docker 4096 Apr 23 02:03 example.test

Error caused by ownership change

When the container is recreated (to run the container setup scripts again, which in this example will require adding the account again due to no persistence), ownership of both UID and GID for that /var/mail/clamav file gets set to docker:

$ ls -l /var/mail
total 8
-rw------- 1 docker docker  420 Apr 23 02:11 clamav
drwxr-xr-x 3 docker docker 4096 Apr 23 02:03 example.test

That is due to this logic (which is being revised for DMS v16):

docker-mailserver/target/scripts/helpers/utils.sh

Lines 75 to 81 in e532b37

	function _chown_var_mail_if_necessary() {
	# fix permissions, but skip this if 3 levels deep the user id is already set
	if find /var/mail -maxdepth 3 -a \( \! -user "${DMS_VMAIL_UID}" -o \! -group "${DMS_VMAIL_GID}" \) | read -r; then
	_log 'trace' 'Fixing /var/mail permissions'
	chown -R "${DMS_VMAIL_UID}:${DMS_VMAIL_GID}" /var/mail || return 1
	fi
	}

It is this specific change in ownership that causes the error log you've shared. You can attempt the sendmail command again at this point to see your log appear again.

This isn't something we've accounted for as /var/mail is only really intended in DMS for Dovecot. Despite the group ownership of docker, the permissions assigned to /var/mail/clamav that Postfix created is much more strict, only granting access to read/write for the owner of the file. We don't have the ability to change that AFAIK, it's tied to the system user UID/GID in /etc/passwd.

Technically we could use /etc/aliases and alias each account to docker (the generic vmail user that we have Dovecot manage, a future DMS release will rename docker user/group to something more appropriate), or alias to root (which has the DMS added alias to resolve to the POSTMASTER_ADDRESS ENV).

Another potential option is better integration with Dovecot, which has it's own UserDB that I think can be associated with /etc/passwd, but I'd need to look into that for mail storage... however that has a similar issue of mail getting delivered to mail boxes that aren't associated with real user accounts 😓 (makes it less obvious that you have the mail, and not as pleasant to access it)

I'm tempted to enforce configuration of POSTMASTER_ADDRESS during container startup. If the admin hasn't configured that as an account or changed it to point to a valid address that routes to a real mailbox for storage, then mail will fail to deliver (this is presently what happens for anything destined to root, or the POSTMASTER_ADDRESS ENV when it's used directly, like in the Dovecot config or our image update notification script).

[GAS85]

You right, it is owned by docker:

docker exec mailserver ls -la /var/mail
total 28
drwxr-xr-x+ 5 docker docker 4096 Apr 21 18:32 .
drwxr-xr-x  1 root   root   4096 Apr 22 09:47 ..
-rw-------+ 1 docker docker  849 Sep 11  2025 clamav

We can add +s to permit all users in a docker group to write in underlying folders and files.