Hm. Ho la stessa configurazione Vultr di @MathiasFoster e @jryans qui, e ho riscontrato lo stesso problema (Net::OpenTimeout). ufw allow https ha fatto funzionare la mia posta in arrivo.
Ma ora il sito non invia più email. Prima di configurare la posta in arrivo, la posta in uscita funzionava bene.
Non ho nulla di complicato in corso:
notification_email è admin@tasat.org.
La posta in uscita utilizza smtp.titan.email su Hostinger.
In skipped email, vedo \u003creplies+verp-14c9cc6eb915b08d4983c90c744ba4b4@forum.tasat.org\u003e: Sender address rejected: not owned by user admin@tasat.org
Sono nuovo nella creazione di email. Dovrei rimuovere “forum.” dalle stringhe di mail_receiver.yml e rendere “replies@tasat.org” un alias di invio di “admin@tasat.org”?
Il ricevitore di posta è indipendente da Discourse e dall’invio di email, agisce solo come un semplice server di posta configurato per ricevere email, utilizzando l’API di Discourse per inviare tali email a Discourse.
L’unica cosa che mi viene in mente nell’impostazione che potrebbe influire sull’invio è l’impostazione dell’indirizzo “reply by email address”, anche se dovrebbe solo impostare Reply-To sulle email in uscita e non influire sull’indirizzo del mittente.
Solo per confermare, sembra che tu abbia queste (tra le altre) in app.yml:
In tal caso, le notifiche via email che non accettano risposte funzionano ancora? Credo che la verifica dell’email ne sia un esempio, quindi potresti provare a creare un account e vedere se quell’email viene inviata correttamente.
Con questa configurazione, ciò che dovrebbe accadere per le email che possono accettare risposte è che l’email inviata utilizzi: From: admin@tasat.org (anche indirizzo del mittente) Reply-To: replies+abc123@forum.tasat.org
Tipicamente Reply-To non viene trattato come parte delle informazioni del mittente, fornisce solo un indirizzo To predefinito da utilizzare quando le persone rispondono, ma forse Hostinger lo tratta come tale. Potresti essere in grado di aggiungere un alias di invio per replies@forum.tasat.org.
Credo che Vultr (o forse semplicemente l’installazione di Docker quando ufw è presente) abbia alcune regole che impediscono ai container di comunicare tra loro, il che significa che il ricevitore di posta non può connettersi a Discourse. ufw allow https aggira questo problema.
Sulla rete predefinita, solo se un container si connette direttamente a un altro container tramite indirizzo IP locale, si tratta dell’indirizzo IP locale del container stesso.
Quando il ricevitore di posta cerca il nome del dominio di Discourse, non otterrà quell’indirizzo IP locale, quindi dovrà uscire dalla rete Docker e passerà attraverso ufw almeno una volta per raggiungere Discourse.
Questa è una situazione separata, sebbene correlata. Si tratta di connessioni in arrivo dall’esterno e Docker aggiunge regole per consentire il passaggio delle porte esposte.
Non ho molta familiarità con le regole delle catene netfilter/iptables, ma credo che quanto sopra mostri:
Se la connessione proviene da docker0, ovvero dalla rete Docker predefinita, ritorna alla catena precedente (interrompe l’elaborazione delle regole in quella catena).
Altrimenti, se la connessione proviene da qualsiasi altra cosa tranne docker0, se è anche https o http, specifica DNAT causandone il passaggio alla catena FORWARD.
Quindi, con la disposizione mostrata nell’altro argomento, ciò che accade è che se il traffico https o http proviene dall’esterno, viene indirizzato a Docker. Se invece il traffico proviene dalla rete Docker, verrà restituito e rifiutato o scartato dalla catena INPUT.
Ciò che fa ufw allow https è aggiungere una regola alla catena INPUT che la accetta. In questo modo, quando la connessione viene restituita alla catena INPUT come sopra, verrà accettata e troverà Docker in ascolto, venendo infine instradata al container.
Grazie per le risposte! Sono dovuto essere via per un po’, ma ci sto tornando…
Sì, è quello che ho al momento.
Quando provo a creare un account adesso, il pulsante di invio non fa nulla. Come se sapesse che non funzionerà. (E non compare nulla in Skipped o altrove.)
Modifica: Ho impostato “replies@tasat.org” come alias di invio per admin@tasat.org, e ho confermato che funziona per inviare e ricevere. Ho anche confermato la consegna di un’email inviata da un client esterno all’indirizzo replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org
Nell’interesse di provare qualcosa, ho cambiato reply by email address:
da replies+%{reply_key}@forum.tasat.org
a replies+%{reply_key}@tasat.org
Ma non cambia i risultati.
Non arriva a mail-tester. Tutti i tentativi di invio finiscono sotto “skipped” con una varietà di questo messaggio:
553 5.7.1 <replies+verp-8c79cd4e83023bda6df0624c2cacd36e@tasat.org>:
Sender address rejected: not owned by user admin@tasat.org
Forse questo è interessante..? Quando eseguo discourse-doctor, l’invio di email fallisce come segue:
==================== MAIL TEST ====================
Per un test robusto, ottieni un indirizzo da http://www.mail-tester.com/
Invio email a REDACTED . .
Test invio a admin@tasat.org usando smtp.titan.email:587,
username:admin@tasat.org con autenticazione plain.
Connessione al server SMTP riuscita.
Invio a admin@tasat.org. . .
Email non inviata.
Motivo: 553 5.7.1 <replies+verp-3cc19f7b135e6f56219e030999db9e29@tasat.org>:
Sender address rejected: not owned by user admin@tasat.org
L’invio diretto all’indirizzo replies+ (o a un indirizzo forum.tasat.org) da un client di posta elettronica funziona – segue l’alias “replies” e finisce nella casella di posta dell’admin. Da dove proviene il rifiuto?
Ho dato un’occhiata alla sezione dell’articolo “Prevent outgoing host email from interfering.” Non ho un percorso /etc/postfix – ma ecco il mio output di netstat:
MODIFICA IMPORTANTE – Ho ricevuto una risposta dal supporto Titan stasera: “L’indirizzo reply-to e l’indirizzo from devono essere gli stessi, altrimenti l’email non verrà recapitata.” Quindi immagino che tutta la risoluzione dei problemi sia inutile e devo cercare un nuovo host email che non imponga quel requisito.
L’argomento seguente (collegato in fondo a quel documento) contiene anche informazioni sulla gestione dei bounce per questi e altri:
Io stesso utilizzo il piano flessibile di Mailgun (interamente all’interno della franchigia gratuita), ma so che c’è stata confusione sui loro prezzi e potenzialmente le cose sono cambiate per i nuovi utenti da quando mi sono iscritto. L’ultima volta che ho visto (non ho idea se sia ancora vero), era possibile passare a flex dopo la fine della prova, era solo incredibilmente poco chiaro.
Giusto.
Puoi passare a mailgun flex, anche se rendono difficile capirlo. Circa una volta al mese li contatto via email chiedendo perché sia così difficile da trovare.
@Simon_Manning e @pfaffman – grazie ancora per l’input e i suggerimenti, mi hanno messo sulla strada giusta.
Ho deciso di provare MailerSend, poiché il loro attuale piano gratuito è piuttosto generoso. Dovrebbe essere sufficiente per il nostro sforzo no profit per un po’ di tempo. Finora tutto funziona bene
