Certain system emails are not sending

[jmturner]

Summary

Discourse is not sending certain system emails. Test emails can be successfully sent from the UI as well as the Ruby scripts and the system successfully sends upgrade reminder emails, so the infrastructure seems correct. However, new users do not get login link emails or email confirmation emails sent. I can see nothing in logfiles to indicate why.

Steps to reproduce

1. Attempt to log in to Discourse
2. Put email/username in form.
3. Click "email me a login link."
4. No email gets sent.

What is the expected correct behavior?

Discourse should send an email to the email of the user, with a login link included.

Relevant logs and/or screenshots

Environment

• Image version / tag: 3.1.0
• Host OS: Debian Bullseye (running in an unprivileged LXC container on Proxmox)

Any logs | docker-compose.yml

``` version: '2.4' services: discourse-app: container_name: discourse-app image: tiredofit/discourse:latest labels: - traefik.enable=true - traefik.http.routers.discourse-example-org.rule=Host(`discourse.example.org`) # REDACTED - traefik.http.services.discourse-example-org.loadbalancer.server.port=3000 volumes: - ./logs:/data/logs - ./data/uploads:/data/uploads - ./data/backups:/data/backups environment: - TIMEZONE=America/New_York - CONTAINER_NAME=discourse-app

  - DB_HOST=postgresdb
  - DB_NAME=REDACTED
  - DB_USER=REDACTED
  - DB_PASS=REDACTED

  - REDIS_HOST=discourse-redis
  - SITE_HOSTNAME=discourse.example.org # REDACTED

  - CONTAINER_ENABLE_MESSAGING=TRUE
  - SMTP_PORT=25
  - SMTP_HOST=postfix
  - SMTP_OPENSSL_VERIFY_MODE=none
  - SMTP_ENABLE_START_TLS=true

  - DEVELOPER_EMAILS=REDACTED@REDACTED

restart: always
networks:

- proxy

  - services
extra_hosts:
  - postgresdb:172.17.0.1
  - postfix:172.17.0.1
ports:
  - 2020:2020
  - 8082:80
  - 3001:3000
  - 10150:10050

discourse-redis:
image: tiredofit/redis:7
container_name: discourse-redis
volumes:
- ./redis:/var/lib/redis
environment:
- TIMEZONE=America/New_York
- CONTAINER_NAME=discourse-redis
- CONTAINER_ENABLE_MESSAGING=TRUE
- SMTP_HOST=postfix
- SMTP_PORT=25
- SMTP_OPENSSL_VERIFY_MODE=none
- SMTP_ENABLE_START_TLS=true

networks:
  - services
restart: always
extra_hosts:
  - postgresdb:172.17.0.1
  - postfix:172.17.0.1
ports:
  - 2021:2020
  - 6379:6379
  - 10151:10050

discourse-db-backup:
image: tiredofit/db-backup
container_name: discourse-db-backup
volumes:
- ./dbbackup:/backup
environment:
- TIMEZONE=America/New_York
- CONTAINER_NAME=discourse-db-backup
- DB_HOST=postgresdb
- DB_TYPE=postgres
- DB_NAME=REDACTED
- DB_USER=REDACTED
- DB_PASS=REDACTED
- DB_DUMP_FREQ=1440
- DB_DUMP_BEGIN=0000
- DB_CLEANUP_TIME=8640
networks:
- services
restart: always
extra_hosts:
- postgresdb:172.17.0.1
- postfix:172.17.0.1
ports:
- 2022:2020
- 10152:10050

networks:
proxy:
services:
~

</details>

<!-- Include anything additional -->
I note that I do have to do a "gem install actionmailer" to get the test_email_settings.rb script to run.

I'm sadly not familiar enough with Discourse or your handy container to know where the issue lies.

### Possible fixes
<!-- If you can, provide details to the root cause that might be responsible for the problem. -->
I am guessing a batch job somewhere (sidekiq?) is not running like it should. I don't know if the unprivileged nature of the LXC container I'm running in is the root cause. I am using the suggested 'nesting=1' which allows containers to run inside containers.

[tiredofit]

Strange that it works one way yet not the other.
The image performs SMTP settings into the /app/config/discourse.conf file - Perhaps you would want to see if some of those settings may fix it and get it going? You'd want to pkill puma following that to let the settings be read.

[jmturner]

I see that two configurations are present in discourse.conf, perhaps from an append instead of a replace? The settings that are present seem correct and I can't see how multiple identical values would cause an issue but that might be another bug to track down.

I pared discourse.conf down to one configuration, pkilled puma, and attempted an email link again. Still no love. The container never attempts to connect to the mailhost.
Here's what gets logged into discourse.log:

I, [2023-02-15T16:57:19.090718 #1799] INFO -- : Started POST "/u/email-login" for REDACTED-IP at 2023-02-15 16:57:19 -0500
I, [2023-02-15T16:57:19.093244 #1799] INFO -- : Processing by UsersController#email_login as /
I, [2023-02-15T16:57:19.093788 #1799] INFO -- : Parameters: {"login"=>"REDACTED-EMAIL"}
I, [2023-02-15T16:57:19.132247 #1799] INFO -- : Completed 200 OK in 38ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 5563)
D, [2023-02-15T16:57:39.514035 #1806] DEBUG -- : Delivering messages [] to client BIGASS-UUID-REDACTED for user
D, [2023-02-15T16:57:42.625406 #1795] DEBUG -- : Delivering messages [] to client BIGASS-UUID-REDACTED for user

FYI, The puma.log, puma-error.log, and sidekiq.log files are all zero-length.

[tiredofit]

Great eyes. Indeed its appending if the container restarts "warm". I'll fix that one up. I'm going to need to open a Dev server to look into this on my own and at the very least get more logging going for those zero byte files.

I have a mountain of things on the go right now, going to put it on my list for near future < next 10 days. I have this running in a production environment and haven't seen similar things.

I do know as well there are a few DISCOURSE_ hidden environment variables when I started reverse engineering their docker repo that may assist with getting SMTP going, I feel we just need a bit more detail - almost trace level logging instead of their logging at this time.

Lets see what I can come up with.

[depau]

I'm having a similar issue with a fresh container I'm trying to set up.

I can't finish the first setup procedure since it fails to send the activation email.

I verified that running the following inside the container does send an email, but the user confirmation email won't send and it won't log any errors:

bundler exec rake emails:test[testemail@example.com]