Mail-receiver and/or Discourse are not posting email replies

Product Support Self-hosting

AI-generated summary

The user dfriestedt is experiencing issues with their mail-receiver in Discourse, where email replies are not being posted. They have investigated the logs and found temporary failures, but are unsure of the cause.

david suggests checking if the mail-receiver is running the latest version and provides a link to a topic on how to update it. He also recommends verifying the API key in the mail-receiver config and checking for rejected emails in the /admin/email/rejected logs.

dfriestedt confirms they are running the latest version and have checked the API key, but still experience issues. They also mention not seeing any rejected emails.

david proposes testing the network connection between the containers by entering the mail-receiver container and running a wget command to the DISCOURSE_MAIL_ENDPOINT.

dfriestedt discovers the issue is due to an incorrect DISCOURSE_MAIL_ENDPOINT URL, which had two .com and used http instead of https. They thank david for pointing them in the right direction.

1

I recently migrated discourse from AWS to DO Migrate from AWS to Digital Ocean with 2 containers, spaces and 2 CDNs - #3 by dfriestedt. Everything is working great, except for my mail-receiver.

When I reply by email and inspect the logs with ./launcher logs mail-receiver I get the follwing.

Operating environment:
RUBYGEMS_VERSION=2.7.7
MAIL_DOMAIN=reply.EXAMPLE.com
BUNDLER_VERSION=1.16.3
DISCOURSE_API_USERNAME=system
LANG=en_US.UTF-8
HOSTNAME=discourse-beta-ubuntu-s-4vcpu-8gb-nyc1-01-mail-receiver
RUBY_VERSION=2.3.7
GEM_HOME=/usr/local/bundle
PWD=/
HOME=/root
DISCOURSE_API_KEY=REMOVE
BUNDLE_PATH=/usr/local/bundle
BUNDLE_APP_CONFIG=/usr/local/bundle
TERM=xterm
BUNDLE_SILENCE_ROOT_WARNING=1
RUBY_MAJOR=2.3
SHLVL=1
RUBY_DOWNLOAD_SHA256=c61f8f2b9d3ffff5567e186421fa191f0d5e7c2b189b426bb84498825d548edb
PATH=/usr/local/bundle/bin:/usr/local/bundle/gems/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DISCOURSE_MAIL_ENDPOINT=http://discuss.EXAMPLE.com.com/admin/email/handle_mail
DOCKER_HOST_IP=172.17.0.1
_=/usr/bin/env
Delivering mail sent to reply.EXAMPLE.com to Discourse
Starting Postfix

Looks like I’m getting a status of “sent” in the logs, however the reply is not showing up in discourse. Any thoughts here? This only started to happen after I migrated from AWS to DO.

<22>Sep 28 15:27:24 postfix/master[1]: daemon started -- version 3.2.4, configuration /etc/postfix
<22>Sep 28 15:28:32 postfix/smtpd[82]: connect from mail-vs1-f104.google.com[209.85.217.104]
<22>Sep 28 15:28:32 postfix/smtpd[82]: B56602F7524: client=mail-vs1-f104.google.com[209.85.217.104]
<22>Sep 28 15:28:32 postfix/cleanup[89]: B56602F7524: message-id=<b1642e591e436f0abeea7d2f34a48aa9@frontapp.com>
<22>Sep 28 15:28:32 postfix/qmgr[81]: B56602F7524: from=<drew@XXXX.com>, size=21558, nrcpt=1 (queue active)
<22>Sep 28 15:28:32 postfix/smtpd[82]: disconnect from mail-vs1-f104.google.com[209.85.217.104] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
<23>Sep 28 15:28:32 receive-mail[91]: Recipient: replies+9009a1d55776827244f5c75332c2efa7@reply.EXAMPLE.com
<22>Sep 28 15:28:32 postfix/pipe[90]: B56602F7524: to=<replies+9009a1d55776827244f5c75332c2efa7@reply.EXAMPLE.com>, relay=discourse, delay=0.3, delays=0.17/0/0/0.13, dsn=2.0.0, status=sent (delivered via discourse service)
<22>Sep 28 15:28:32 postfix/qmgr[81]: B56602F7524: removed
2

I’ve investigated the logs by running the following. Looks like I’m getting some temporary failures for an unknow reason.

./launcher enter mail-receiver
mailq

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
348432F7524*   11603 Mon Sep 28 16:01:06  mapmeister@XXX.net
                                         replies+429b18013a7bd110cab88a1a0f57f4cd@reply.XXX.com

95ED82F7526*   21757 Mon Sep 28 16:01:10  drew@XXX.com
                                         replies+9009a1d55776827244f5c75332c2efa7@reply.XXX.com

42A2C2F6EE0    21607 Mon Sep 28 15:25:32  drew@XXX.com
                                                           (temporary failure)
                                         replies+9009a1d55776827244f5c75332c2efa7@reply.XXX.com

324792F6EDF    23547 Mon Sep 28 15:23:22  drew@XXX.com
                                                           (temporary failure)
                                         replies+b42b43ae2bde8b6b951d46647f387b32@reply.XXX.com

D07792F7525    21712 Mon Sep 28 15:53:04  drew@XXX.com
                                                           (temporary failure)
                                         replies+9009a1d55776827244f5c75332c2efa7@reply.XXX.com
3

Are you running the latest version of the mail-receiver container? You might be interested in this topic:

Some other things to check:

  • Does the API key in your mail_receiver config match with an API key in the Discourse admin UI?
  • Do you have any emails showing in the /admin/email/rejected logs?
4

Hello. Thanks for your reply

in mail-receiver.yml I have base_image: discourse/mail-receiver:release and do not see an error message about the mail-receiver being old. I’ve rebuilt the mail-receiver many times.

I do not see any email as rejected here: /admin/email/rejected
I did issue a new API key for user system with all privileges. I’m using that in mail-receiver.yml. I was thinking the API was the issue, but I’ve check the numbers match a few times.

5

Curious, I’m seeing no activity on the API I created

6

To test the network connection between the containers, you could try entering the container like

./launcher enter mail-receiver

And then try

wget -O - $DISCOURSE_MAIL_ENDPOINT

If the connection works successfully, you should see

wget: server returned error: HTTP/1.1 404 Not Found

If not, then double check the DISCOURSE_MAIL_ENDPOINT value in your config.

7

The level of my stupidity is insane. I deserve a massive dunce hat.

Connecting to discuss.360velo.com.com (199.59.242.154:80).

com.com… ??? I had the wrong DISCOURSE_MAIL_ENDPOINT. I had two .com.com in the URL and i should have been using https rather than http. Thank you very much for pointing me in the right direction.