Accesso al relay del destinatario della posta negato

Sto cercando di abilitare le risposte via email utilizzando il contenitore mail-receiver, ma ottengo costantemente errori:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Accesso al relay negato

Perché succede? Come posso accedere al contenitore mail-receiver, esaminare la configurazione di Postfix e debuggarla? Ho disabilitato il server Postfix sul sistema in cui viene eseguito, a causa di un conflitto sulla porta 25. È sbagliato?

Sono abbastanza sicuro che i record DNS MX siano corretti e il problema si verifica da qualsiasi server che invia posta in entrata. Sto utilizzando Amazon SES per l’invio in uscita nel contenitore dell’applicazione e questo funziona correttamente.

Sono un principiante di Discourse e non so come debuggare l’ecosistema. Sono un esperto di Postfix, ma non so come configurarlo in questo universo containerizzato.

Per prima cosa, se hai già un’istanza di Postfix in esecuzione, non hai davvero bisogno del contenitore per la ricezione delle email.

Puoi configurare Postfix come ricevitore di email per le risposte e impostare Discourse per interrogare tale casella di posta.

Questa guida del 2014 ti fornirà le idee necessarie per iniziare; presumo che tu sappia configurare Postfix in autonomia.

Non sono affatto d’accordo. Il vantaggio del mail-receiver è che le email vengono inviate tramite API, anziché interrogate. C’è una differenza significativa nel tempo necessario perché le email arrivino su Discourse utilizzando il mail-receiver (minuti contro secondi).

C’è anche una grande differenza nella semplicità di configurazione: il mail-receiver richiede l’aggiornamento di sole tre righe di un file yml, mentre la procedura OOBE di postfix richiede… di più.

Quell’errore implica che i domini di posta non corrispondono.

Poiché stai oscurando parti del messaggio, non possiamo facilmente risolvere il problema per te.

Se ricevi qualsiasi email come previsto, questo implica che qualcuno sta cercando di utilizzare il tuo server di posta per inviare messaggi a un altro dominio. Ad esempio, qualcuno potrebbe aver puntato il proprio record MX al tuo indirizzo IP. Oppure, e non ne ho mai sentito parlare :wink:, qualcuno potrebbe cercare di utilizzare in modo illecito il tuo server di posta per inviare email indesiderate.

Tutti questi errori provengono dallo stesso IP? Riesci a vedere nei log per quale dominio sono destinati i messaggi errati?

La cosa più semplice da fare è ignorarli.

Ho riscontrato questo problema su un mail-receiver che funzionava in precedenza, al quale avevo apportato alcune modifiche. Pensavo di dover ricostruire il container, ma chiaramente qualcosa non era andato a buon fine, dato che ho ricevuto diversi errori ‘Relay access denied’ per tutti i destinatari. La configurazione DNS era corretta.

Alla fine, un semplice vecchio git pull e launcher rebuild mail-receiver hanno risolto il problema. Lo pubblico solo nel caso possa essere utile anche ad altri.

Ho lo stesso errore con i report di mail-receiver: Relay access denied (in reply to RCPT TO command).

La ricezione della posta non funziona per la nuova installazione, ma l’ho già fatta funzionare in precedenza. Credo che tutte le impostazioni siano corrette, ma potrei aver tralasciato qualcosa.

Questo di solito significa che la posta viene recapitata a un dominio che non è quello che il destinatario è configurato per accettare.

L’ho impostato per lo stesso sottodominio del sito discourse.

Per il valore del record MX è “sottodominio.dominio”, e l’host dovrebbe essere solo “sottodominio” o @?

Qualcuno sa cosa causa l’errore “Accesso al relay negato”?

Si verifica quando il dominio del destinatario non corrisponde al dominio configurato in mail-receiver.yml.

È quello l’indirizzo a cui stai inviando l’email?

Stesso indirizzo, ora funziona dopo la ricostruzione del ricevitore di posta.
Credo di averlo ricostruito prima, ma non funzionava, è un bene che ora funzioni.

devo consentire ulteriormente la porta 25 affinché mail-receiver funzioni correttamente?

In questo caso, funzionare correttamente significherebbe che le email in arrivo che appaiono in .\launcher logs mail-receiver raggiungano l’interfaccia di amministrazione di Discourse.

Sì, devi aprire la porta 25. Potrebbe essere aggiunta a questa guida come regola opzionale.

Beh, non ne ho 25 aperte. Quindi, no.

Ma ufw status non è così interessante. Invece nft list ruleset lo è.

Aggiornamento: ufw deny 25 è stato applicato e mail-reciver funziona correttamente (07/02/2025)

Posso confermare che è corretto, anche se ho commesso un altro errore. Si tratta del mio secondo forum per implementare mail-receiver, e sul primo avevo il record MX del dominio che riceve le email Value come DISCOURSE_BASE_URL

Ora ricevo le email nel mio (secondo) forum UI, piuttosto che solo nel primo :tada:

Nota: questa convinzione di correttezza potrebbe essere dovuta al fatto di non aver eseguito ./launcher rebuild mail-receiver dopo aver modificato lo yml (06/02/2015)

Immagino che non sia necessario consentire la porta 25, ad esempio, su un firewall del pannello Azure o VPS, quindi pre-Ubuntu

perché il valore del record MX dovrebbe puntare al sito Web, non al dominio di posta elettronica, interessante

La guida ufficiale menziona che la porta 25 deve essere aperta:

Io stesso ho riscontrato un problema con il ricevitore di posta perché ho dimenticato di aprire la porta 25 nel mio firewall. L’aggiunta della regola ha risolto il problema.

una soluzione migliore potrebbe essere quella di consentire solo l’indirizzo IP pertinente?

Non diciamo questo al mio ricevitore di posta :wink:

L’invio avviene tramite Amazon SES. La ricezione avviene tramite mx al dominio del forum e ora entra in gioco Docker.

Il motivo è Docker e il suo modo di funzionare interno. Semplicemente non si preoccupa di ufw. Se vuoi una spiegazione esatta e dettagliata, aspetta un secondo: una volta ho chiesto perché Discourse non si preoccupa del mio firewall, e il motivo era il traffico dei pacchetti. Ma capire a fondo cosa sta succedendo non è la mia tazza di tè. Per me è sufficiente che le cose funzionino. E fidati di me: ufw ha aperte solo le porte 22, 80 e 443.

Suppongo che tu abbia citato una situazione in cui il ricevitore di posta si occupa anche dell’invio di e-mail utilizzando postfix.