Mail-Receiver-Konfiguration: 403-Fehler beim smtp_should_reject Endpoint

Hallo Discourse Community,

Ich stoße auf ein Problem bei der Einrichtung des Mail-Receivers für mein selbst gehostetes Discourse-Forum. Trotz Befolgung der offiziellen Dokumentation hier erhalte ich die folgende Fehlermeldung in meinen Logs:

Failed to GET smtp_should_reject answer from https://forum.get.it/admin/email/smtp_should_reject.json: 403 450 4.7.1 replies+d6c9064e799543ae371fbf74ba32845a@reply.get.it: Recipient address rejected: Internal error, API request failed

Hier ist meine aktuelle mail-receiver.yml-Konfiguration:

base_image: discourse/mail-receiver:release
update_pups: false

expose:
  - "25:25"   # SMTP

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

  MAIL_DOMAIN: reply.get.it
  POSTCONF_smtpd_tls_key_file: /letsencrypt/reply.get.it/reply.get.it.key
  POSTCONF_smtpd_tls_cert_file: /letsencrypt/reply.get.it/fullchain.cer
  POSTCONF_smtpd_tls_security_level: may

  DISCOURSE_BASE_URL: 'https://forum.get.it'
  DISCOURSE_API_KEY: [**************]
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
  - volume:
      host: /var/discourse/shared/standalone/letsencrypt
      guest: /letsencrypt

Schritte, die ich bisher unternommen habe:

  1. API-Schlüssel-Neuerstellung: Einen neuen API-Schlüssel generiert und den DISCOURSE_API_KEY in mail-receiver.yml aktualisiert.
  2. Konfigurationsprüfung: Überprüft, ob DISCOURSE_BASE_URL und MAIL_DOMAIN korrekt eingestellt sind.
  3. Container-Neuerstellung: ./launcher rebuild mail-receiver ausgeführt, nachdem die oben genannten Änderungen vorgenommen wurden.

Trotz dieser Bemühungen besteht das Problem weiterhin. Hat jemand ein ähnliches Problem gehabt oder kann Einblicke geben, was schiefgehen könnte?

Vielen Dank im Voraus für Ihre Hilfe!

Ist Ihr API-Schlüssel granular oder global (obwohl, wenn Sie nicht die strengen Berechtigungen hätten, würde die Fehlermeldung wahrscheinlich anders lauten, wie z. B. unauthorized:thinking: ?

Gibt es weitere Informationen in Ihren Protokollen?