In grado di ricevere e-mail in mail-receiver ma NON in Discourse?

Supporto Installazione
1

Questo è per un’installazione iniziale, e non sono certo un guru del DNS! Ecco dove mi trovo:

  • I test per l’invio di email funzionano perfettamente. Sto utilizzando MailGun con il loro sottodominio “mg” consigliato. Sto inviando sulla porta 2525. Ho inserito l’API di MailGun per i webhook nel campo corrispondente nelle impostazioni (loro hanno TRE API: è quella giusta??). Ho anche inserito i record MX per il sottodominio mg nelle mie impostazioni DNS. Il controllo di validazione di MailGun dice che tutto funziona correttamente, così come mail-tester.com.
  • L’invio in entrata è configurato con un sottodominio chiamato “inbound”. Se invio un’email da un account Gmail a fake@inbound.[mydomain].org, vedo che l’email arriva nel log del mail-receiver. Se invio, da Discourse, un’email di test allo stesso indirizzo tramite Impostazioni > Email, l’email sembra scomparire: non appare nulla nel cestino dei rifiutati. Per il resto sto utilizzando la ricezione diretta e semplice delle email in entrata.

A causa di altri errori autoinflitti nel processo di configurazione, ho deciso di ricominciare da zero: ho eliminato il mio droplet, reinstallato Discourse e sto ricominciando tutto da capo. Non ho però eliminato l’account MailGun e sto effettivamente utilizzando lo stesso webhook API di prima. Potrebbe questo essere il problema? Sto però utilizzando una nuova chiave API generata da Discourse (quella vecchia, ovviamente, è stata vaporizzata quando ho eliminato il droplet).

L’unica altra cosa a cui riesco a pensare è l’endpoint in mail-receiver.yml. Il mio appare così: DISCOURSE_MAIL_ENDPOINT: 'https://inbound.[mydomain].org/admin/email/handle_mail'

Qualche idea su dove si trovi il blocco? (La ciliegina sulla torta è che tutto funzionava perfettamente qualche tempo fa, prima di eliminare il droplet. Apparentemente sono un apprendista lento :stuck_out_tongue_winking_eye:). Grazie a tutti!

2

Questo dovrebbe essere il dominio del tuo forum, non quello della tua email. Puoi confermare che il tuo forum non si trova su inbound.[mydomain].org? Ad esempio, se Meta utilizzasse questo metodo, l’URL apparirebbe così:

DISCOURSE_MAIL_ENDPOINT: 'https://meta.discourse.org/admin/email/handle_mail'

Inoltre… questo non ha nulla a che fare con Mailgun, se non per assicurarsi di ignorare le istruzioni di Mailgun di aggiungere record MX per il dominio. Come indicato:

Nota: i provider di email in uscita come Mailgun potrebbero chiederti di aggiungere record MX che puntano ai loro server. Devi rimuoverli in modo che i record MX del tuo forum puntino solo al dominio del tuo forum. I record SPF e DKIM devono comunque puntare ai server del tuo provider di email in uscita in modo da poter inviare email.

4

@tobiaseigen Ci stiamo avvicinando! Ho apportato la modifica rimuovendo il sottodominio della posta in arrivo dall’endpoint. Ho salvato, quindi riavviato il ricevitore di posta (perché non so cosa sto facendo!). Ho eseguito un test. Nessun risultato. Poi ho effettuato una ricostruzione completa dell’applicazione. Quindi ho creato due nuovi account utilizzando indirizzi email diversi. Ho quindi utilizzato l’account amministratore per inviare un messaggio privato a uno di questi. Ciò ha generato un’email come previsto. Ho quindi risposto tramite email al messaggio privato. Ecco il risultato nel registro della posta:

<22>Nov 25 02:38:20 postfix/pipe[89]: AB09913F5CB: to=<replies+da32f82583043bb63fee8be53f9bd3fd@inbound.[mydomain].org>, relay=discourse, delay=0.35, delays=0.19/0/0/0.15, dsn=4.3.0, status=deferred (temporary failure)

Effettivamente ci stiamo avvicinando! Non sono sicuro di cosa significhi esattamente questo errore temporaneo? Sono passate 13 minuti e l’invio in Discourse non è ancora avvenuto. Strano.

Devo precisare che ho creato il sottodominio “inbound” perché desidero che un indirizzo email admin@[mydomain].org sia gestito da un altro host di posta.

2 Mi Piace
5

Ho un po’ di difficoltà a capire il tuo utilizzo dei nomi di dominio. Sul mio sito, il DISCOURSE_MAIL_ENDPOINT e il record MX per le email in arrivo appartengono allo stesso dominio, puntando al server Discourse, come spiegato nel post originale su Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Sembra che tu stia cercando di utilizzare domini diversi.

In genere, è consigliabile utilizzare un sottodominio del tipo forum.miodominio.org per il tuo Discourse, per separare il forum dal tuo sito web principale e dalle email su miodominio.org.

6

Sono felice di chiarire :slightly_smiling_face: e farò finta che il mio dominio sia thesite.org per semplicità. Quello che noto è un problema SSL nei log del ricevitore di posta:
<19>Nov 25 19:11:29 receive-mail[160]: Failed to POST the e-mail to https://inbound.thesite.org/admin/email/handle_mail: hostname "inbound.thesite.org" does not match the server certificate (OpenSSL::SSL::SSLError)

Per rispondere alla tua domanda, avevo due obiettivi che presumo siano estremamente comuni:

  1. admin@thesite.org diventi un indirizzo per gli utenti per contattare l’amministratore
  2. thesite.org avvii il forum (nessun sottodominio)

Attualmente le mie impostazioni DNS di Namecheap sono così (TTL = Auto e Priority = 10):

1   A Record   @                  (Indirizzo IP)     
2   A Record  inbound.            (Indirizzo IP)    
3   CNAME     email.mg.           mailgun.org.   
4   CNAME     inbound.            thesite.org.   
5   CNAME     www.                thesite.org.    
6   TXT       @                   forward-email=(qualcosa)
7   TXT       mg                  v=spf1 include:mailgun.org ~all
8   TXT       smtp._domainkey.mg. k=rsa; p=(qualcosa)
9   MX        @                   mx1.forwardemail.net.  
10  MX        @                   mx2.forwardemail.net.
11  MX        inbound.            thesite.org.
12  MX        mg.                 mxa.mailgun.org.
13  MX        mg.                 mxb.mailgun.org.

Le mie impostazioni containers/mail-receiver.yml sono:
MAIL_DOMAIN: inbound.thesite.org
DISCOURSE_MAIL_ENDPOINT: 'https://thesite.org/admin/email/handle_mail'
DISCOURSE_API_KEY: (qualcosa)
DISCOURSE_API_USERNAME: system ← uguale alla chiave API
* nota—> Ho lasciato le righe di LetsEncrypt così come erano (non ho rimosso il “#”)

Altre impostazioni:

  • modificato da riga di comando l’hostname in inbound.thesite.org
  • email di contatto = admin@thesite.org
  • email di notifica = noreply@mg.thesite.org
  • email di risposta 1 = replies+%{reply_key}@inbound.thesite.org
  • email di risposta 2 = %{reply_key}@inbound.thesite.org
  • trova post correlato con chiave = ON
  • polling manuale = ON
  • chiave API Mailgun = INSERITA …ma questo potrebbe essere un problema perché proviene da un precedente tentativo di installazione
  • Impostazioni > Email > Impostazioni: Indirizzo = smtp.mailgun.org
  • Impostazioni > Email > Impostazioni: Porta = 2525
  • Impostazioni > Email > Impostazioni: user_name = postmaster@mg.thesite.org

Hai qualche idea su come procedere? …e un enorme GRAZIE in anticipo! Metto anche in copia @pfaffman poiché è stato così gentile da essere una risorsa aiutandomi con le difficoltà passate relative alla configurazione. La tua guida “Semplice e diretta” è stata estremamente utile. Saluti!

2 Mi Piace
7

Hai ricompilato entrambi i container per la posta e l’applicazione? Penso che la soluzione più semplice sia rimuovere ciò che tenta di fornire un certificato al ricevitore della posta. Il certificato funziona per il sito?

Se il sito Discourse non si trova su inbound.thesite.org, questo è il problema. L’idea è che il nome host sia lo stesso sia per il sito Discourse che per il ricevitore della posta. Dovrai consultare Impostazione di Let’s Encrypt con più domini per risolvere la questione.

Questo esula piuttosto dall’ambito previsto della guida per il ricevitore della posta. Se queste indicazioni non ti bastano per rimetterti in carreggiata e hai un budget a disposizione, sentiti libero di contattarmi.

4 Mi Piace
8

Quindi la domanda è: è possibile ottenere entrambi gli obiettivi che ho definito sopra (sembrano assurdi ma comuni)? L’unica soluzione è reindirizzare, nelle impostazioni DNS, gli utenti che digitano www.thesite.org e/o thesite.org verso subdomain.thesite.org? Se è così, dovrò semplicemente accettare di cambiare l’indirizzo email visibile in qualcosa di brutto come admin@subdomain.thesite.org.

Posso accettare di cambiare l’indirizzo email dell’amministratore se è assolutamente necessario. Sembra che stiamo trascurando qualcosa di ovvio, ma forse mi sto perdendo qualcosa (probabilmente è così!).

9

Se ciò che desideri è che il destinatario della posta riceva le email su un dominio diverso dal tuo dominio Discourse, penso sia possibile. La soluzione più semplice è non utilizzare il certificato Let’s Encrypt nel ricevitore di posta.

1 Mi Piace
10

@pfaffman sei un genio! Ha funzionato!! :clap: :clap: :clap: Seguendo la guida Configurazione di Let’s Encrypt con più domini, la ricostruzione di Discourse seguita da quella di mail-receiver (probabilmente una delle due non era necessaria) ha fatto il miracolo. Eccolo fatto!

Più tardi stasera, vorrei copiare e incollare l’articolo originale “Consegna diretta semplice per la posta in arrivo” in un documento Google e proporre le mie modifiche suggerite. Non è colpa di nessuno di voi, ma ci sono parti dell’articolo originale che non sono intuitive per qualcuno come me che non conosce o non comprende le righe di comando. Penso che i due obiettivi che ho definito sopra siano molto comuni per molte installazioni, e ora so che l’obiettivo finale può essere raggiunto.

Ho altre suggerimenti per l’intero tutorial di configurazione. Ho una lista in corso di modifiche suggerite per rendere il processo il più semplice possibile.

Grazie mille per il tuo aiuto in tutto questo! Apprezzatissimo!

1 Mi Piace
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.