Connessione a un server SMTP su localhost:25 senza autenticazione?

Supporto Installazione
1

Quali sono le impostazioni corrette da passare a ./discourse-setup per connettersi a un server SMTP su localhost:25 senza autenticazione?

Sono molto sorpreso che questo non sia supportato OOTB; è la configurazione predefinita sulla maggior parte delle installazioni Linux.

Il mio server esegue localmente Postfix; non è accessibile da Internet. Funziona perfettamente, ad esempio, quando si esegue il comando mail. Ho trovato alcune guide non ufficiali su Internet che suggerivano modifiche a /var/discourse/containers/app.yml, e alla fine sono riuscito a installarlo e avviarlo con le seguenti impostazioni:

  DISCOURSE_SMTP_ADDRESS: localhost
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse@opensouceecology.org
  DISCOURSE_SMTP_PASSWORD: "none"
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false

Nota che se ometto le variabili DISCOURSE_SMTP_USER_NAME o DISCOURSE_SMTP_PASSWORD, lo script di installazione mi fa una scenata dicendo che sono richieste (bug?).

Ora, quando clicco sul pulsante “Invia di nuovo l’email di attivazione” nell’interfaccia web di Discourse, questa voce appare nel file di log (/var/discourse/shared/standalone/log/rails/production.log):

Started PUT "/finish-installation/resend-email" for 127.0.0.1 at 2019-11-07 13:15:31 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: {"authenticity_token"=>"SzQCvRWiqdXsBKzOjIB0X7KkvXro7Od6SdP8Qa8vvrskPeNYZNos5ORHJfyDUrHiKShZR/txM6NHuqHHCQCR1w=="}
  Rendering finish_installation/resend_email.html.erb within layouts/finish_installation
  Rendered finish_installation/resend_email.html.erb within layouts/finish_installation (Duration: 0.7ms | Allocations: 103)
  Rendered layouts/_head.html.erb (Duration: 0.5ms | Allocations: 103)
Completed 200 OK in 98ms (Views: 3.0ms | ActiveRecord: 0.0ms | Allocations: 4763)
  Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.5ms | Allocations: 141)
Delivered mail c4ca58ca-345e-46c4-81bc-6d0eac7afa04@discourse.opensourceecology.org (11.3ms)
Job exception: wrong authentication type none

…Ma il mio tipo di autenticazione è ‘none’. Qual è l’impostazione corretta per nessuna autenticazione?

EDIT: inoltre, qualcuno può linkarmi la documentazione che definisce tutte le possibili variabili “DISCOURSE_SMTP_*” e tutti i loro valori validi?

EDIT2: questo si sta rivelando molto più difficile di quanto dovrebbe essere. Penso che ‘localhost’ si risolva all’interno del container Docker di Discourse nel container Docker di Discourse stesso (app) – non nell’host Docker che esegue il mio server SMTP Postfix. Ciò è ulteriormente complicato da mynetworks di Postfix e da iptables (configurati dallo script discourse-setup o dai suoi script figli). Qual è la configurazione corretta per far sì che Discourse utilizzi semplicemente il server SMTP su cui voglio eseguire Discourse, senza autenticazione SMTP?

2

Penso che ciò non sia stato molto vero per circa 20 anni.

Non puoi usare discourse-setup per situazioni come la tua perché poche persone hanno server SMTP non protetti da password, anche dietro un firewall.

Quello che farei è configurare le password SMTP per il mio server di posta. In realtà non ci sono molti svantaggi.

Se non vuoi farlo, penso che invece di “none” per l’autenticazione tu possa usare “” (e analogamente per la password e il nome utente).

Penso anch’io. Potresti provare a usare il nome del contenitore. Credo che tu debba verificare che entrambi siano sulla stessa rete Docker.

3

Nel 2019, è la configurazione predefinita per Postfix su RHEL/CentOS. Postfix si lega solo all’interfaccia di loopback e scarta tutte le richieste SMTP che non provengono da 127.0.0.0/8. Nessuna autenticazione richiesta. Non sono sicuro riguardo a Debian, ma immagino che exim abbia una configurazione predefinita simile.

Alcuni argomenti rilevanti su questi forum da altri utenti che hanno incontrato questo problema:

Non sembra esserci un argomento su come configurare questo su RHEL/CentOS con le modifiche necessarie sia a Discourse che a Postfix, quindi lo sto documentando qui.

Questo non sembra essere possibile con lo script discourse-setup, ma sono riuscito a farlo funzionare.

Per prima cosa, ho dovuto scoprire l’indirizzo IP dell’host Docker così come lo vede il container Docker. Usare 127.0.0.1 non funziona perché il container Docker vedrebbe 127.0.0.1 come se stesso. Piuttosto, dobbiamo specificare l’indirizzo IP o il nome host dell’host Docker che esegue il server SMTP Postfix, e che sia raggiungibile dal container Docker (quindi non l’indirizzo IP pubblico dell’host Docker se si desidera che il server SMTP non sia accessibile da Internet, ad esempio).

Ho estratto l’indirizzo IP rilevante dell’host Docker (172.17.0.1) dall’interfaccia docker0 eseguendo questo comando sull’host Docker:

[maltfield@osestaging1 ~]$ ip address show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:80:35:65:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:80ff:fe35:65a1/64 scope link 
       valid_lft forever preferred_lft forever
[maltfield@osestaging1 ~]$

Poi ho modificato il file yaml della mia applicazione Discourse, impostando “DISCOURSE_SMTP_ADDRESS” su 172.17.0.1 come sopra.

[maltfield@osestaging1 ~]$ cd /var/discourse/
[maltfield@osestaging1 discourse]$ grep SMTP containers/app.yml
  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false
[maltfield@osestaging1 discourse]$

Nota che ho prima provato a usare il nome host interno del docker host.docker.internal per questo, ma apparentemente questo nome host non è disponibile per gli utenti Linux di Docker

Poiché la configurazione predefinita di Postfix su RHEL/CentOS si lega solo a 127.0.0.1 (il che è buono), dovrai modificare /etc/postfix/main.cf in modo che si leghi anche all’interfaccia docker0 e aggiungere quella sottorete al gruppo mynetworks in modo che il traffico SMTP proveniente dai container Docker venga accettato da Postfix.

[maltfield@osestaging1 postfix]$ grep -ir '172.17' /etc/postfix/*
/etc/postfix/main.cf:inet_interfaces = 127.0.0.1, 172.17.0.1
/etc/postfix/main.cf:mynetworks = 127.0.0.0/8, 172.17.0.0/16
[maltfield@osestaging1 postfix]$

Dopo queste modifiche, ricostruisci Discourse e dovrebbe ora essere in grado di inviare email attraverso il Postfix dell’host Docker.

/var/discourse/launcher rebuild app

Sebbene questo funzioni, ho alcune domande:

  1. Esiste un’altra variabile d’ambiente o un nome host che punta già all’host Docker (172.17.0.1 in questo caso)?

Ho notato che c’è una variabile d’ambiente DISCOURSE_HOST_IP “iniettata” da launcher. È possibile impostare questa chiave yaml DISCOURSE_SMTP_ADDRESS allo stesso valore dell’altra chiave yaml con qualcosa di simile a questo?

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. In generale, quanto è durevole l’indirizzo IP 172.17.0.1 dell’host Docker? È sempre questo indirizzo IP sui sistemi RHEL/CentOS? Cambierà mai per me?"}
4

@maltfield Volevo solo ringraziarti per le istruzioni.

Ho riscontrato lo stesso problema su Debian… Potrei creare un utente mail separato per Discourse, suppongo, e fargli connettere e accedere al sito:465, ma connettersi alla porta 25 dall’interno è più logico, a mio avviso.

A proposito, su Debian 10 con docker.io dai repository, docker0 è ancora 172.17.0.1/16.

5

Forse hai frainteso ciò che sta dicendo @maltfield?

Per tutto il tempo che ricordo (che va ben oltre i 20 anni), i sistemi Linux (Unix / BSD / Solaris) hanno un server SMTP in esecuzione, configurato di default per inoltrare qualsiasi cosa ricevuta da localhost senza fare domande. Questo solleva qualsiasi altra applicazione in esecuzione su quella macchina dall’avere la necessità di preoccuparsi e configurare le impostazioni SMTP.

6

Sì, la maggior parte dei server Linux non richiede autenticazione per inviare email (né di default né dopo l’installazione e la configurazione). Inoltre, non è necessaria se non inoltrano posta da nessuna rete oltre a quella locale. Gli script di installazione predefiniti di Discourse non funzionano per la maggior parte dei server. Sono progettati per un insieme ristretto di soluzioni cloud basate su Docker.

Puoi leggere le mie istruzioni complete e dettagliate per installare Discourse su un server dedicato bare metal con RHEL/CentOS 7 nella wiki di Open Source Ecology. Nota la sezione su SMTP qui:

7

Beh, in quasi tutti i casi mi affido a te per queste questioni! Immagino che siano passati diversi anni dall’ultima volta che ho gestito un server SMTP su localhost, quindi è probabile che non sappia di cosa sto parlando.

Ancora una prova che ho torto! :man_shrugging:

Bello!

Ma discourse-setup è destinato solo a chi non sa praticamente nulla di amministrazione di sistema. Se sai come installare un server SMTP, puoi modificare un file yml.

8

Se l’host su cui è in esecuzione il contenitore ha un nome ottenibile tramite DNS, è sufficiente specificarlo:

DISCOURSE_SMTP_ADDRESS: real.machine.example.com

Postfix rileverà comunque che l’origine della posta è locale e la gestirà di conseguenza.

9

Se DISCOURSE_HOSTNAME e DISCOURSE_SMTP_ADDRESS sono uguali, causerà problemi?

Ho configurato Postfix e Dovecot sull’host Docker per accettare richieste autenticate tramite TLS. Ho certificati validi per il mio server, ma qualunque configurazione io provi, non riesco a far inviare correttamente le email da Discourse a Postfix in esecuzione sull’host Docker.

Se uso l’hostname (discourse.[myhost].com) non funziona (non si connette nemmeno). Se uso l’indirizzo IP dell’host Docker (172.17.0.1), ottengo

hostname "172.17.0.1" does not match the server certificate

Chiaramente, devo usare il FQDN utilizzato per creare i certificati. Se provo a impostare DISCOURSE_SMTP_ENABLE_START_TLS su false, dice che devo emettere un comando start TLS. Non voglio davvero aprire Postfix senza TLS, quindi non la vedo come un’opzione praticabile.

Utilizzare un relay SMTP esterno non è nemmeno un’opzione perché non voglio pagare di più solo per assicurarmi che le email non finiscano nelle cartelle spam/posta indesiderata delle persone.

Devo dire che ho solo una comprensione rudimentale del networking Docker, una comprensione ancora minore dell’impostazione di un server SMTP Postfix con Dovecot per l’autenticazione, ma non sono un principiante assoluto, ma rendere questa configurazione sicura/protetta si sta rivelando estremamente difficile.

@maltfield Ho letto il tuo articolo su Open Source Ecology ma non voglio usare comunicazioni non autenticate sulla porta 25. L’università per cui lavoro ha protocolli molto rigidi sull’uso di comunicazioni non crittografate e non autenticate (anche all’interno di una configurazione di rete locale come questa). Sono troppo preoccupati che possa essere abusata da uno studente scontento.

10

Quindi, ho capito che c’era qualcosa di strano nell’usare lo stesso hostname sia per il server Discourse che per il server SMTP.

Ulteriori indagini rivelano che il container Docker aggiunge la seguente voce al file hosts:

172.17.0.2	discourse.[mydomain].com discourse

Quindi qualsiasi tentativo di utilizzare lo stesso hostname per il container in esecuzione e l’host Docker causerà l’invio di tutte le richieste emesse dal container al container stesso e non all’host Docker.

Che fiasco! Perché Discourse non fornisce semplicemente un server SMTP di configurazione predefinito nel container!?
OPPURE rende più facile utilizzare Discourse senza Docker!

Due giorni della mia vita persi a causa di questo problema.

11

Alla fine, accetto il fatto che non posso usare TLS per comunicare con SMTP in esecuzione sull’host Docker (senza ottenere certificati utilizzando un nome host diverso). Per far funzionare finalmente questo, ho dovuto assicurarmi che 172.17.0.0/16 fosse aggiunto alla variabile mynetworks nel file main.cf di Postfix:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.17.0.0/16

Questo permette a Postfix di considerare qualsiasi container Docker in esecuzione su questo server come parte della rete.

Un’altra modifica che ho dovuto apportare è stata quella di assicurarmi che smtpd_sasl_security_options fosse impostato su noanonymous per impedire agli “estranei” di utilizzare Postfix come relay SMTP. Assicurati che l’opzione noplaintext non sia impostata qui, altrimenti Postfix consentirà l’autenticazione solo tramite TLS.

smtpd_sasl_security_options = noanonymous

Con queste impostazioni di configurazione, ho potuto specificare le seguenti impostazioni in app.yml:

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1                            # IP address of the Docker host (as seen from within this container)
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse
  DISCOURSE_SMTP_PASSWORD: pa$$word
  DISCOURSE_SMTP_ENABLE_START_TLS: false                        # (optional, default true)
  DISCOURSE_SMTP_DOMAIN: discourse.[mydomian].com                # (required by some providers)
  DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.[mydomain].com # (address to send notifications from)

Ho anche creato un account utente locale sull’host Docker solo per lo scopo dell’autenticazione SASL.
Con queste modifiche, sono finalmente riuscito a inviare e-mail dal container, ma non posso fare a meno di pensare che questa sia una configurazione subottimale. Idealmente, dovrebbe essere possibile utilizzare il nome host desiderato per l’host Docker e far sì che le richieste a discourse.[mydomain].com vadano nel posto giusto.

Ora devo configurare SPF e DKIM per far sì che le e-mail finiscano nelle caselle di posta delle persone (invece che nelle cartelle spam). Spero davvero che un giorno questo doloroso processo sia più automatizzato. Forse fornire alcune istruzioni su come configurare Discourse senza utilizzare Docker (in modo che possa essere utilizzato con cPanel, ad esempio…) o rendere la configurazione della posta elettronica meno dolorosa fornendo una sorta di configurazione SMTP predefinita direttamente nel container Docker!

12

Se torni all’inizio degli anni '90, era come desideri. Le cose di cui parli funzionavano e basta. Ma gli spammer hanno reso tutto molto più complicato. Il processo diventerà solo più difficile, motivo per cui la raccomandazione è di utilizzare un servizio che si occupi di molte delle complicazioni per te.

13

Sono contento che tu abbia configurato la tua posta elettronica!

Ci sono alcuni aggiornamenti sulla guida alla risoluzione dei problemi di posta elettronica rispetto a ieri. Se non sei ancora soddisfatto della tua configurazione di posta elettronica, prova a riprovare!

Può essere risolto utilizzando:

… solo la risoluzione DNS predefinita del nome di dominio in IP.

14

Non fraintendermi. Capisco l’importanza di SPF e DKIM. È solo fastidioso. Vorrei solo che questo potesse essere installato sui nostri attuali server cPanel dove queste cose sono già configurate.

15

Mi mancava questo. Ora funziona con TLS.

Ho anche configurato DKIM, quindi le email non dovrebbero più finire nello spam.