I assigned @erik-wramner for review as he knows better than me what could go wrong here when adjusting the Dockerfile.

PS: @erik-wramner 260 checking setup.sh: setup.sh email add and login went wrong here, so nothing to worry about.

@aendeavor I was wondering, if you could confirm such log entrys? I just checked mine and couldn't find them.

@aendeavor I was wondering, if you could confirm such log entrys? I just checked mine and couldn't find them.

I will check this later.

@casperklein I can't find them either. @erik-wramner do you see these logs?

As both me and @casperklein do not see these logs, I'd now be more reserved with merging this, as the root cause is still unclear!? I've marked it as conflict until this is resolved.

EDIT: Corrections.

@aendeavor @casperklein I'm pretty sure this bug is configuration-dependent. I get lines like this every 70 minutes in my container output:

mail postfix/qmgr[1003]: 7100AFD4B3: from=<amavis@mail.{REDACTED}>, size=766, nrcpt=1 (queue active)
mail postfix/local[3040]: warning: specify "strict_mailbox_ownership = no" to ignore mailbox ownership mismatch

This is the system trying to deliver the mail that got generated off the cron job I silenced in the PR. The mail in question is /var/mail/amavis and it has this in it:

From amavis@mail.{REDACTED} Fri Oct 16 03:55:38 2020
Return-Path: <amavis@mail.{REDACTED}>
X-Original-To: amavis
Delivered-To: amavis@mail.{REDACTED}
Received: by mail.{REDACTED} (Postfix, from userid 112)
id 56F48FC388; Fri, 16 Oct 2020 00:18:07 +0000 (UTC)
From: root@mail.{REDACTED} (Cron Daemon)
To: amavis@mail.{REDACTED}
Subject: Cron amavis@mail test -e /usr/sbin/amavisd-new-cronjob && /usr/sbin/amavisd-new-cronjob sa-sync
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/lib/amavis>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=amavis>
Message-Id: <20201016001807.56F48FC388@mail.{REDACTED}>
Date: Fri, 16 Oct 2020 00:18:07 +0000 (UTC)

config: created user preferences file: /var/lib/amavis/.spamassassin/user_prefs

(EDIT: the body is clearly from line 2051 in the file I linked in the original comment)
Also, I get similar garbage in my mail.warn log inside the container. The other people in the issue thread have the same stuff in their logs and it appears to be coming from the same series of events as I am encountering. I'm sorry if you guys don't have this problem, but I do, and this fix stops it. If I make the change to the job I submitted in the PR, and delete the amavis mail, it doesn't get regenerated and I don't get that garbage in my logs, its very reliable.

Off topic: I'm trying to use this container in production and it has some quirks, I had clamv go into a restart loop last night because it couldn't verify its database for some reason. I set ENABLE_CLAMAV=0 in my environment file and restarted and it did nothing. To fix this, I had to hack the container to remove the clamv lines in supervisor-app.conf so it wouldn't get started. Can you guys tell me what ENABLE_CLAMAV=0 does in the conf? It does not appear to actually disable anything.

Also, I get similar garbage in my mail.warn log inside the container. The other people in the issue thread have the same stuff in their logs and it appears to be coming from the same series of events as I am encountering.

I'm confident this is correct - therefore this issue can and will be fixed. It's just that @casperklein and me cannot confirm this at the moment, which is not to say this does not exist. I figured six eyes would be better than four looking at this. I myself approve this PR, but maybe there is something I overlooked. @erik-wramner will have a look at this and then we will decide. I'm confident we can merge this or figure out another way to solve this, if problems arise.

Off topic: I'm trying to use this container in production and it has some quirks, I had clamv go into a restart loop last night because it couldn't verify its database for some reason. I set ENABLE_CLAMAV=0 in my environment file and restarted and it did nothing. To fix this, I had to hack the container to remove the clamv lines in supervisor-app.conf so it wouldn't get started. Can you guys tell me what ENABLE_CLAMAV=0 does in the conf? It does not appear to actually disable anything.

Please open an issue for this, as this is unrelated to this PR. There was a similar issue with Dovecot (#1647). We will investigate as fast as we can to get this up and running again.

@erik-wramner what do you think about this? If you think this is fine, by all accounts, merge it yourself, or mark it as ready to merge and remove the conflict badge. I will then take care of it.

I don't get the warnings either. I fully agree that it should be fixed, but I don't think throwing away the logs is the right solution. It can hide other more serious issues and it will of course hide this one. Who knows, perhaps this has some other negative effect apart from the noise in the logs?

I have one suggestion. Please add a mail account or an alias for amavis and see if that helps. Personally I have added this to postfix-virtual.cf:
[email protected] [email protected]
That helps the mail server to deliver mail to amavis cleanly. Does that solve your problem?

@erdos4d can you try what @erik-wramner suggested and report back?

I've just realised #1528 is one of the problems which could accidentally be covered by this PR.

@aendeavor, @erik-wramner, @casperklein I put the change in place that @erik-wramner suggested and it does produce a steady stream of mail in my postmaster inbox as the job continues to emit useless warnings. I get that this is a solid hack for getting the logs clean, but I am not sure it is the best way to go about it. With that said, I 100% understand the reluctance to just dump the job output since something important might go to null and we won't know about it. I changed the pull request to send it to a log file instead. Please let me know if this is a good or what I should do here. Thanks:)

@erdos4d thanks for your reply.

@erik-wramner The logfile solution seems better than the original solution, but I'm worried about (not having) logrotate on this file (so I keeps getting bigger and bigger). Is that correct?

@aendeavor yes, the log will simply grow, however at present I get one line per job run, so about 8 lines a day, per the job schedule, should be the growth rate.

I'm still not convinced. The log file is better than /dev/null, but people won't read it.

Having a virtual account for amavis is probably something we should document, because it is needed from time to time and if it is not there we get strange errors. This is not the only case when mail is sent to amavis, so it remains a good thing to have.

Second, I map the amavis account to my own personal account via postmaster and I don't get these mail notifications. That means they are not sent for a server that works correctly, so @erdos4d must have some problem we have not yet detected. I would rather fix the problem than hide the alarm.

To get rid of the warnings I would suggest something like https://www.serverwatch.com/guides/forwarding-a-postfix-virtual-alias-to-dev-null (not for all, just for amavis for @erdos4d) or a sieave rule. Or a real virtual account that can simply be ignored (messages will add up similar to the entries in the log file). However, it would be better to solve them for real.

@aendeavor you don't get them either, do you?

I'm with you on this @erik-wramner. For me, this seems to cover up another error which was not found yet, and I don't like that either. And yes, I do not see these warnings.

@erdos4d could you Open another issue on this? From what I can see, this is not going to be merged soon. We would rather like to fix the underlying problem:)