Erreur d'accès relais refusée pour le destinataire du mail

Trying hard to enable replies by email using the mail-receiver container. I consistently get errors:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied

Why is this? How can I get into the mail-receiver container and examine the postfix config and debug it? I have disabled the postfix server on the system on which this is running, because of clash with port 25. Is that wrong?

I am reasonably sure DNS MX records are right, and this happens from any server sending mail inbound, I am using Amazon SES for outbound in the app container and that works fine.

I am a Discourse newbie and I dont know how to debug the ecosystem. I am an expert in postfix, but I don’t know how to configure it in this containerized universe.

First thing first, if You already have a postfix instance running, You don’t really need the mail receiver container.

You can configure postfix as an email receiver for the replies email and configure discourse to poll that email.

This howto from 2014 shall give you enough idea to get started and I assume you can figure postfix on your own.

I don’t agree with this at all, the benefit of the mail-receiver is that emails are pushed via the API, rather than polled. There’s a significant difference in the time taken for email to arrive in Discourse using the mail-receiver (minutes versus seconds).

There’s also a huge difference in simplicity in configuration, mail-receiver requires three lines of a yml file be updated, the postfix OOBE requires… more.

That error implies the mail domains don’t match.

As you’re obfuscating parts of the message we can’t easily troubleshoot this for you.

3 « J'aime »

If you’re getting any mail delivered as you expect, then this implies that someone is trying to use your mail server to deliver mail to some other domain. If, for example, someone pointed their MX record to your IP address. Or, and I’ve never heard of this :wink: , someone was trying to nefariously have your mail server deliver unwanted mail.

Are all of these errors from the same IP? Can you see in the logs what domain they the errant messages are intended for?

The easiest thing to do is to ignore it.

3 « J'aime »

I had this issue on a previously working mail-receiver which I’d made some changes to. I had thought I’d rebuild the container but clearly something hadn’t gone right as I got multiple ’ Relay access denied’ errors for all recipients. DNS was correctly configured.

In the end a good old git pull and launcher rebuild mail-receiver fixed it. Just posting this in case it works for anyone else.

2 « J'aime »

J’ai la même erreur avec les rapports de réception de courrier : Accès au relais refusé (en réponse à la commande RCPT TO).

La réception du courrier ne fonctionne pas pour une nouvelle installation, mais j’ai déjà réussi à le faire fonctionner auparavant. Je pense que tous les paramètres sont corrects, mais j’ai peut-être manqué quelque chose.

Cela signifie généralement que le courrier est distribué à un domaine qui n’est pas celui que le destinataire est configuré pour accepter.

Je l’ai configuré pour le même sous-domaine que le site Discourse.

Pour la valeur de l’enregistrement MX, est-ce « sous-domaine.domaine », et l’hôte est censé être juste « sous-domaine » ou « @ » ?

Quelqu’un sait ce qui cause l’erreur « Relay access denied » ?

Cela se produit lorsque le domaine du destinataire ne correspond pas au domaine configuré dans mail-receiver.yml.

1 « J'aime »

Est-ce l’adresse à laquelle vous envoyez le courrier ?

Même adresse, cela fonctionne maintenant après la reconstruction du récepteur de courrier.
Je pense que je l’avais reconstruit auparavant mais cela ne fonctionnait pas, c’est bien que cela fonctionne maintenant.

dois-je autoriser le port 25 supplémentaire pour que mail-receiver fonctionne correctement.

Dans ce cas, fonctionner correctement signifierait que les e-mails entrants affichés dans .\launcher logs mail-receiver atteignent l’interface d’administration de Discourse.

Oui, vous devez ouvrir le port 25. Cela pourrait être ajouté à ce guide comme règle facultative.

1 « J'aime »

Eh bien, je n’en ai pas 25 ouvertes. Donc, non.

Mais ufw status n’est pas si intéressant. nft list ruleset l’est.

1 « J'aime »

Mise à jour : ufw deny 25 a été appliqué et mail-reciver fonctionne correctement (07/02/2025)

Je peux confirmer que c’est correct, bien que j’aie commis une autre erreur. Il s’agit de mon deuxième forum pour implémenter mail-receiver, et sur le premier, j’avais l’enregistrement MX du domaine recevant les e-mails Value comme DISCOURSE_BASE_URL.

J’ai maintenant les e-mails arrivant dans l’interface de mon (deuxième) forum, plutôt que seulement dans mon premier :tada:

Remarque : cette conviction de correction peut être due au fait de ne pas avoir exécuté ./launcher rebuild mail-receiver après avoir modifié le yml (06/02/2015)

J’imagine que vous n’avez pas besoin d’autoriser le port 25 sur, disons, un pare-feu de panneau Azure ou VPS - donc pré-Ubuntu

parce que la valeur de l’enregistrement MX doit pointer vers le site Web, pas vers le domaine de messagerie, intéressant

Le guide officiel mentionne que le port 25 doit être ouvert :

J’ai moi-même rencontré un problème avec le récepteur de courrier parce que j’avais oublié d’ouvrir le port 25 dans mon pare-feu. L’ajout de la règle a résolu le problème.

une meilleure solution serait de n’autoriser que l’adresse IP pertinente ?

Ne disons pas ça à mon récepteur de courrier :wink:

L’envoi se fait via Amazon SES. La réception se fait par mx vers le domaine du forum et maintenant docker intervient.

La raison est docker et sa façon interne de fonctionner. Il ne se soucie tout simplement pas de ufw. Si vous voulez une explication exacte et détaillée, attendez une seconde - j’ai demandé une fois pourquoi Discourse ne se soucie pas de mon pare-feu, et la raison était le trafic des paquets. Mais comprendre en profondeur ce qui se passe n’est pas ma tasse de thé. Pour moi, il suffit que les choses fonctionnent. Et croyez-moi : ufw n’ouvre que les ports 22, 80 et 443.

Je suppose que vous avez cité une situation où le récepteur de courrier s’occupe également d’envoyer des e-mails en utilisant postfix.

1 « J'aime »