Mail-receiver log errors after letsencrypt update

Support

AI-generated summary

Mail-receiver Log Errors After Let’s Encrypt Update

A discussion on issues with mail-receiver logs after a Let’s Encrypt update. md-misko initially reported errors in the logs, which were later found to be warnings, but the logs were not showing any email events.

RGJ mentioned that the warnings did not affect Postfix’s functionality, but md-misko had issues with custom postfix settings rejecting all incoming emails.

The issue was found to be with the log rendering, which was garbled and only showed a single line of log entries md-misko.

A temporary fix was found by adding POSTCONF_maillog_file: '/dev/stdout' to mail-receiver.yml and rebuilding md-misko. A pull request was submitted to fix the issue in the Docker image md-misko.

The fix was merged by david, who provided instructions on how to update the mail receiver version. pfaffman asked about testing the current running image version, and david provided a solution to check if the running image is up to date.

1

Continuing the discussion from Self-hosted mail-receiver update following Let's Encrypt root certificate change:

After updating mail-receiver to latest ./launcher logs mail-receiver errors out after

postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out
<20>Oct  1 06:10:33 postfix/postfix-script[86]: warning: symlink leaves directory: /etc/postfix/./makedefs.outStarting Postfix

and doesn’t show any other events (incoming emails, rejected emails, …).

I’ve encountered some issues with custom postfix settings (which worked flawlessly prior to recent update) and need to debug, which is difficult without logs.

2

have you tried these steps

3

I do see the same errors warnings but Postfix is happily running and accepting mails after that.

Sometimes the logs don’t seem to flush immediately so you might need to wait for a while before you get some output. But that’s unrelated to the warnings.

So is it actually crashing for you?

4

Ditto, with vanilla settings. But I had to temporarily disable additional postfix rule

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

which worked perfectly before the upgrade (uses regex rules to reject spammers). The real issue is that with this setting enabled, postfix starts rejecting all incoming email, but I can’t see why from the logs!

A while maybe, but it’s been hours and still nothing in logs (neither accepted nor rejected emails are shown, and there is inbound traffic).

5

You were right, there are other log entries in the output, but the output itself is garbled:

./launcher logs mail-receiver output begins with a <HEAD>:

/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Operating environment:
HOSTNAME=discourse-mail-receiver
LANGUAGE=en_US.UTF-8
MAIL_DOMAIN=...
...
...
Setting smtpd_tls_security_level to 'may'
postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out

followed by a single line of log entries, and ending with the <HEAD> repeated six more times:

<HEAD>
Single line of log entries without line breaks..............................................................................................................................................................................................
<HEAD>
<HEAD>
<HEAD>
<HEAD>
<HEAD>
<HEAD>

I was only looking at the end of the output, and there was always seemingly just the <HEAD> without any other entries.

Definitely something wrong with the rendering of the log via ./launcher logs mail-receiver.

6

I believe I figured this one out, there is a maillog_file line missing in the Dockerfile. Temp fix: added

  POSTCONF_maillog_file: '/dev/stdout'

to mail-receiver.yml and rebuilt, but this should probably be fixed in the docker image

RUN >/etc/postfix/main.cf \
+	&& postconf -e maillog_file=/dev/stdout \
	&& postconf -e smtputf8_enable=no \
...
7

So after adding this, the error is gone, and the logs are working? If so, would you mind submitting a PR to make that change?

8

https://github.com/discourse/mail-receiver/pull/11

9

https://github.com/discourse/mail-receiver/pull/12

10

Thanks @md-misko - I’ve merged the PR and bumped the discourse/mail-reciever:release tag on Dockerhub.

I’m sure you’re already aware, but in case anyone else comes across this topic, you can update your mail receiver version by running:

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver
11

Have you got any ideas of how to test that the current running image is running the latest version?

12

A little convoluted… but I think this should work:

# First, make sure you've got the latest base image locally
docker pull discourse/mail-receiver:release

# Get the top layer of the base image
BASE_IMAGE_HASH=$(docker history discourse/mail-receiver:release -q | head -n 1)

# Get the layers of the **running** version
RUNNING_IMAGE_HASH=$(docker container inspect mail-receiver -f "{{.Image}}")
RUNNING_IMAGE_LAYERS=$(docker history $RUNNING_IMAGE_HASH -q)

# Check if the running image layers include the current base image:
[[ "$RUNNING_IMAGE_LAYERS" == *"$BASE_IMAGE_HASH"* ]] && echo "Up to date"

That will print “Up to date” if you’re up to date. Otherwise, the final line will print nothing, and exit with a non-zero status.

13

Oh. That’s brilliant. And looks like it’s a general solution that I have previously found only one-off solutions for. It would have taken me a while to figure that out. The RUNNING_IMAGE_LAYERS is what I didn’t know to look for.

I tested it on an instance that had been upgrade and one that hadn’t and it appears to behave as expected.

Thanks so very much!