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

Je tente activement d’activer les réponses par e-mail en utilisant le conteneur mail-receiver. Je rencontre systématiquement des erreurs :

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Accès de relais refusé

Pourquoi cela se produit-il ? Comment puis-je accéder au conteneur mail-receiver pour examiner la configuration Postfix et la déboguer ? J’ai désactivé le serveur Postfix sur le système où cela s’exécute en raison d’un conflit avec le port 25. Est-ce une erreur ?

Je suis raisonnablement certain que les enregistrements DNS MX sont corrects, et cela se produit depuis n’importe quel serveur envoyant des e-mails entrants. J’utilise Amazon SES pour les e-mails sortants dans le conteneur de l’application, et cela fonctionne correctement.

Je suis nouveau dans Discourse et je ne sais pas comment déboguer l’écosystème. Je suis un expert de Postfix, mais je ne sais pas comment le configurer dans cet univers conteneurisé.

Premièrement, si vous avez déjà une instance Postfix en cours d’exécution, vous n’avez pas vraiment besoin du conteneur de réception de courriels.

Vous pouvez configurer Postfix comme récepteur de courriels pour les réponses et configurer Discourse pour qu’il interroge cette adresse.

Ce #tutoriel de 2014 devrait vous donner une idée suffisante pour démarrer, et je suppose que vous pourrez configurer Postfix par vous-même.

Je ne suis absolument pas d’accord avec cela. L’avantage du mail-receiver est que les e-mails sont poussés via l’API, plutôt que sondés. Il y a une différence significative dans le temps nécessaire pour qu’un e-mail arrive dans Discourse en utilisant le mail-receiver (minutes contre secondes).

Il y a aussi une énorme différence de simplicité dans la configuration : le mail-receiver nécessite la mise à jour de trois lignes d’un fichier yml, tandis que l’OOBE de Postfix nécessite… davantage.

Cette erreur implique que les domaines de messagerie ne correspondent pas.

Comme vous masquez certaines parties du message, nous ne pouvons pas facilement dépanner cela pour vous.

3 « J'aime »

Si vous recevez tout courrier comme prévu, cela implique que quelqu’un tente d’utiliser votre serveur de messagerie pour acheminer du courrier vers un autre domaine. Par exemple, si quelqu’un a pointé son enregistrement MX vers votre adresse IP. Ou, et je n’ai jamais entendu parler de cela :wink:, quelqu’un tentait malicieusement de faire livrer du courrier indésirable par votre serveur de messagerie.

Tous ces erreurs proviennent-elles de la même adresse IP ? Pouvez-vous voir dans les journaux quel domaine ces messages erronés sont destinés ?

La chose la plus simple à faire est de l’ignorer.

3 « J'aime »

J’ai rencontré ce problème sur un mail-receiver qui fonctionnait auparavant et que j’avais modifié. J’avais pensé reconstruire le conteneur, mais visiblement quelque chose n’avait pas fonctionné correctement, car j’ai reçu plusieurs erreurs « Relay access denied » pour tous les destinataires. La configuration DNS était correcte.

Finalement, un bon vieux git pull suivi de launcher rebuild mail-receiver a résolu le problème. Je poste ceci au cas où cela pourrait aider d’autres personnes.

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 »