Configura email in arrivo per consegna diretta su siti self-hosted con Mail-Receiver

Ciao! Ho un problema strano in cui ho configurato tutto seguendo la guida e funziona benissimo! Tuttavia, qualcosa è andato storto con l’email in uscita, che pensavo non sarebbe stata influenzata da nulla di tutto ciò. Sidekiq restituisce il seguente errore per ogni tentativo di email (tutte bloccate nell’elenco Retries) da quando ho attivato mail-receiver:

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_read: unexpected eof while reading

Le mie ricerche mi portano a credere che questo sia in qualche modo correlato a TLS. Avevo decommentato le righe relative a TLS nel file .yml, ma anche ricommentandole non ho risolto il problema. Ho provato le istruzioni nella guida per risolvere i conflitti di Postfix, ma apparentemente non ho Postfix? (La directory /etc/postfix nella guida non esiste sulla mia istanza, né riconosce postfix come servizio.) E secondo i risultati di netstat, solo docker-proxy sta utilizzando la porta 25.

Stiamo usando Gmail come servizio SMTP in uscita, e infatti stavamo usando Gmail per il polling POP3 in entrata prima di questo. Ho cancellato alcuni record MX che puntavano a Google, ma la guida diceva di farlo.

Questo è il mio mail-receiver.yml, con alcuni dettagli ovviamente omessi:

## questo è il template del container mail-receiver
##
## Dopo aver apportato modifiche a questo file, DEVI ricostruire
## /var/discourse/launcher rebuild mail-receiver
##
## FAI MOLTA ATTENZIONE QUANDO MODIFICHI!
## I FILE YAML SONO ESTREMAMENTE SENSIBILI A ERRORI DI SPAZIATURA O ALLINEAMENTO!
## visita http://www.yamllint.com/ per validare questo file se necessario

base_image: discourse/mail-receiver:release
update_pups: false

expose:
  - "25:25"   # SMTP

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

  ## Dove le email al tuo forum dovrebbero essere inviate. In generale, va benissimo
  ## usare lo stesso dominio del forum stesso qui.
  MAIL_DOMAIN: discourse.[mydomain].org
# decommenta queste righe (e il volume sottostante!) per supportare TLS
  POSTCONF_smtpd_tls_key_file:  /letsencrypt/discourse.[mydomain].org/discourse.[mydomain].org.key
  POSTCONF_smtpd_tls_cert_file:  /letsencrypt/discourse.[mydomain].org/fullchain.cer
  POSTCONF_smtpd_tls_security_level: may


  ## L'URL di base per questa istanza di Discourse.
  ## Sarà qualunque sia l'URL del tuo sito Discourse. Ad esempio,
  ## https://discourse.example.com. Se stai eseguendo una configurazione in sottocartella,
  ## assicurati di tenerne conto (ad es. https://example.com/forum).
DISCOURSE_BASE_URL: 'https://discourse.[mydomain].org'

  ## La chiave API master del tuo forum Discourse. Puoi ottenerla dalla
  ## scheda "API" del tuo pannello di amministrazione.
  DISCOURSE_API_KEY: [myapikey]

  ## Il nome utente da utilizzare per l'elaborazione delle email in entrata. A meno che tu non abbia
  ## rinominato l'utente `system`, dovresti lasciarlo così com'è.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# decommenta per supportare TLS
  - volume:
      host: /var/discourse/shared/standalone/letsencrypt
      guest: /letsencrypt

La tecnologia email è un po’ al di fuori della mia competenza, quindi apprezzo qualsiasi consiglio, anche se è per farmi notare che ho trascurato qualcosa di stupido durante la configurazione. Grazie!

1 Mi Piace

Come pensavi, non ha niente a che fare con il ricevitore del collo. L’host tramite cui stai inviando la posta ha un certificato SSL rotto.

Bene, l’ho capito dopo molti tentativi. Il problema è probabilmente derivato dal fatto che il dominio su cui ospitiamo la nostra istanza Discourse non è lo stesso dominio su cui si trovavano i nostri record MX. Una volta superata quella confusione, tutto si è risolto.

È sicuramente un mio stupido errore, ma la guida ha contribuito un po’ alla mia confusione con questo:

Non è molto chiaro che le due voci forum.example.com non debbano essere identiche, e nel mio caso dovevano essere diverse. Forse le persone che utilizzano questa guida dovrebbero essere abbastanza esperte da saperlo, ma io non lo ero. Quindi lascio questo qui per chiunque altro possa incontrare un problema simile. Ho imparato alcune cose sul DNS che non sapevo, quindi è stata una buona esperienza di apprendimento, e ora funziona tutto alla grande. :slight_smile:

Beh, ho parlato troppo presto. Le email in uscita funzionano bene, le risposte in entrata sembrano funzionare bene, ma l’invio all’indirizzo email di una categoria non va a buon fine in modo silenzioso. Ho copiato e incollato l’indirizzo direttamente dalle impostazioni in una nuova email, quindi so che non ci sono errori di battitura.

I log del mio mail-receiver hanno fondamentalmente tre tipi di voci. Quella riuscita, che era una risposta via email a un post esistente, appare così:

Sep 20 16:59:44 discourse-mail-receiver postfix/smtpd[277]: connect from server168-1.web-hosting.com[68.65.122.144]
Sep 20 16:59:45 discourse-mail-receiver postfix/smtpd[277]: NOQUEUE: reject: RCPT from server168-1.web-hosting.com[68.65.122.144]: 454 4.7.1 <[category]@discourse.[domain].org>: Relay access denied; from=<ryan@[redacted].com> to=<[category]@discourse.[domain].org> proto=ESMTP helo=<server168-1.web-hosting.com>
<22>Sep 20 16:59:45 policyd-spf[288]: : prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=[redacted]; helo=server168-1.web-hosting.com; envelope-from=ryan@[redacted].com; receiver=discourse.[domain].org Sep 20 16:59:45 discourse-mail-receiver postfix/cleanup[281]: 4CCED114200: message-id=<20240920165945.4CCED114200@discourse-mail-receiver.localdomain>
Sep 20 16:59:45 discourse-mail-receiver postfix/smtpd[277]: disconnect from server168-1.web-hosting.com[68.65.122.144] ehlo=1 starttls=0/1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=3/6

A parte questo, ci sono due tipi di (quelli che presumo siano) errori, ognuno dei quali si ripete parecchio. Il primo appare così:

Sep 20 17:00:23 discourse-mail-receiver postfix/qmgr[124]: 5D162FC26D: from=<double-bounce@discourse-mail-receiver.localdomain>, size=960, nrcpt=1 (queue active)

E l’altro:

Sep 20 17:00:23 discourse-mail-receiver postfix/error[293]: 8DC3BFC141: to=<postmaster@discourse-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=126622, delays=126622/0.05/0/0, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=discourse-mail-receiver.localdomain type=MX: Host not found, try again)

E questo è ciò che mostra il mio mailq, solo voci come questa ancora e ancora e ancora:

3D07BFC23D      960 Fri Sep 20 06:42:23  double-bounce@discourse-mail-receiver.localdomain
(delivery temporarily suspended: Host or domain name not found. Name service error for name=discourse-mail-receiver.localdomain type=MX: Host not found, try again)
                                         postmaster@discourse-mail-receiver.localdomain

Parte di questo sembra avere a che fare con le email che Discourse invia, che poi vengono respinte per qualche motivo. mail-receiver ha qualche funzionalità per elaborare questi bounce, o rimarranno per sempre nella mailq?

In secondo luogo, perché le risposte funzionano, ma l’invio diretto via email a una categoria no? Grazie ancora per il tuo aiuto e la tua pazienza. :slight_smile:

Queste sembrano le voci di log per il fallimento verso l’indirizzo di una categoria piuttosto che per il successo nel rispondere a un post.

Non sono sicuro al 100%, ma penso che relay access denied suggerisca che discourse.[domain].org probabilmente non sia il dominio utilizzato per MAIL_DOMAIN in mail-receiver.yml. Possibilmente l’indirizzo di risposta è consentito attraverso altri mezzi.

So cosa viene utilizzato in MAIL_DOMAIN finisce in almeno un posto in un file di configurazione di postfix, quindi cambiarlo probabilmente richiede la ricostruzione del container. Hai cambiato MAIL_DOMAIN e, in tal caso, hai eseguito ./launcher rebuild mail-receiver in seguito?

2 Mi Piace

[Scusate per aver premuto accidentalmente invio prima di finire il mio post precedente]

Sto ancora sbattendo la testa su questo problema. Ma ho una nuova idea su quale potrebbe essere il problema. Sto lavorando con due domini, chiamiamoli [domain1] e [domain2]. Il mio relay SMTP di Gmail è ospitato su [domain1]. La mia istanza Discourse, così come il mio mail-receiver, è ospitata su [domain2].

Come imposto l’impostazione reply-by-email-address in Discourse per forzare un indirizzo di risposta su [domain2], quando l’email viene inviata da [domain1]? Ottengo l’errore SSL EOF menzionato sopra quando tento di farlo. Presumo che ci sia qualche trucco di autenticazione DNS o qualcosa che mi sfugge.

Sembra che alla fine l’abbia capito. Per fare in modo che l’indirizzo “reply-to” si trovi in un dominio diverso da quello del relay SMTP, ho dovuto allentare alcune impostazioni in Google Workspace. Ora sembra che tutto funzioni come previsto in entrambe le direzioni.

1 Mi Piace

Un’ultima domanda. Anche se ora tutto funziona correttamente, ho ancora un sacco di vecchie voci nella mia mailq. Si tratta molto probabilmente di email generate con le impostazioni sbagliate e che quindi rimarranno bloccate nel limbo per sempre. Preferirei semplicemente eliminarle e andare avanti. Quindi, come si svuota la mailq?

Post un po’ vecchio, ma forse il motivo più comune per l’errore SSL EOF è un conflitto tra le versioni di OpenSSL: v1.1.1f vs v3. L’aggiornamento di quel vecchio 1.1.1f sarà la soluzione. E la cattiva notizia è che, ad esempio, Ubuntu 20.x non può usarne uno più recente, quindi l’intero Ubuntu deve essere aggiornato.

1 Mi Piace

Sono al limite, dopo aver passato ore. Non riesco a superare questo errore del Launcher, anche se i nomi dei miei file di configurazione sono tutti in minuscolo.

“ERRORE: Il nome della configurazione non deve contenere caratteri maiuscoli, spazi o caratteri speciali. Correggi il nome della configurazione ed esegui nuovamente ./launcher.”

mentre eseguo

./launcher rebuild mail-receiver

o

./launcher bootstrap mail-receiver

o

./launcher start mail-receiver

Posso vederlo qui nel codice sorgente del launcher

Grrrrrrrrrr – Per favore, aiutami!

Ho provato tutto nel post collegato sopra relativo alla localizzazione e tutto ciò che ho potuto trovare altrove.

./launcher rebuild app___ stanno funzionando bene!

Ho un possibile indizio: questo ha iniziato ad accadere subito dopo aver premuto accidentalmente il tasto Bloc Maiusc (ma con solo 2 lettere maiuscole) mentre stavo nominando il file di configurazione, che ho poi immediatamente disattivato e riscritto le 2 lettere prima ancora di salvarlo.

Difficile immaginare come questo breve errore di battitura/correzione possa aver causato questo, ma forse le maiuscole sono bloccate in un buffer da qualche parte, o ???

È ben al di là delle mie conoscenze, ma mi sorprende che il messaggio di errore non restituisca la variabile $config :thinking:
Sicuramente aiuterebbe nel debug.

1 Mi Piace

Grazie @Canapin! - questo è ciò che sto cercando di configurare:

https://www.perplexity.ai/search/provide-the-code-lJcI4BrFQ2auuD42ehYFwA

Puoi copiare e incollare tutto il contenuto della tua riga di comando?

Dal tuo ./launcher start mail-receiver al messaggio di errore, così come il nome esatto del file .yml?

Se rinomino il file di configurazione in Mail-receiver.yml, ./launcher start Mail-receiver produrrà

ERROR: Config name 'Mail-receiver' must not contain upper case characters, spaces or special characters. Correct config name and rerun ./launcher.

Qui il messaggio di errore contiene il nome del file.

Inoltre, se esegui ./launcher start aaa, non troverà alcun file corrispondente e elencherà quelli disponibili. Li sceglie solo dalla cartella, quindi non c’è niente di magico qui, ma forse produrrà qualcosa di interessante :person_shrugging:

ERROR: containers/aaa.yml does not exist or is not readable.

Available configs ( app, mail-receiver )

Grazie mille, ho risolto e funziona.

Qual è stato il problema alla fine? Potrebbe aiutare altri :slight_smile:

Non c’è stato alcun problema, è stata solo una curva di apprendimento per capire come interagiscono i vari componenti del server per l’instradamento di domini e posta elettronica. Non avevo mai approfondito prima postfix. È stato divertente e ho imparato molto.

La ricetta che ho finalmente trovato è usare un mail-receiver.yml (un container docker) accoppiato a ogni istanza di Discourse, condividendo tutti la porta 25 utilizzando la funzionalità di trasporto in postfix per gestire l’instradamento.

2 Mi Piace

Sul mio server dedicato (con Ubuntu 22.04 e Postfix installato) utilizzo un file mail-receiver.yml separato per ogni istanza di Discourse in cui ho abilitato la funzionalità di invio tramite posta elettronica.

Questa configurazione crea un container separato per ogni istanza di Discourse sul mio server (accanto al tipico container app) che riceve ed elabora le e-mail per la corrispondente istanza di Discourse.

Le e-mail in arrivo per tutti i forum di Discourse sul server vengono ricevute da Postfix tramite la porta standard 25, dove il file di configurazione principale di Postfix utilizza una “transport map” per “inoltrare” ogni e-mail al forum di Discourse previsto analizzando il nome del dominio nell’indirizzo e-mail “To:”.

Quindi, oltre alle istruzioni di questo argomento, ho…

  1. modificato il file di configurazione Postfix esistente in: /etc/postfix/main.cf

  2. quindi, ho aggiunto il corrispondente file postfix transport map in: /etc/postfix/transport

  1. infine, ho aggiunto i file corrispondenti per creare il container e-mail per ciascuno dei forum:
    /var/discourse/containers/mail-receiver-domain1.yml
    /var/discourse/containers/mail-receiver-domain2.yml
    /var/discourse/containers/mail-receiver-domain3.yml
    /var/discourse/containers/mail-receiver-domain4.yml
    /var/discourse/containers/mail-receiver-domain5.yml

3 Mi Piace

Non c’è DISCOURSE_MAIL_ENDPOINT in mail-receiver.yml, e c’è anche DISCOURSE_BASE_URL da modificare.

2 Mi Piace

Utilizzo un servizio di inoltro email che supporta l’inoltro di email in formato JSON a un webhook.

Questa è un’opzione per la consegna diretta di email?

1 Mi Piace