Usare un server email locale/sendmail per le email in uscita?

Installazione Ospitare
1

Abbiamo configurato il nostro server di posta elettronica e mi stavo chiedendo come usarlo al meglio con il container Docker di Discourse.

Naturalmente posso configurare i dettagli e le credenziali SMTP, ma mi sembra un sovraccarico non necessario, dato che il server SMTP è in esecuzione sulla stessa macchina.

sendmail funziona, ma Discourse è nel container, quindi non ha accesso a sendmail sul suo host.

Cercando qualcosa qui nel forum si trova un esempio in cui è stato utilizzato DISCOURSE_SMTP_DOMAIN senza credenziali, dove fare lo stesso con swaks all’interno del container funziona: How to get Discourse to work with Postfix - #18 by sonmicrosystems Immagino che in quel caso si tratti ancora di una normale submission SMTP sulla porta predefinita, e Postfix la accetta senza autenticazione, dato che la richiesta proviene da localhost?

Qualcuno è a conoscenza di un altro metodo? Vedo che la libreria Ruby utilizzata supporta generalmente tutto: GitHub - discourse/mail: A Really Ruby Mail Library
Nelle impostazioni di Discourse, ciò che ha attirito la mia attenzione è un campo Delivery method:

image
image643×198 6.22 KB

Non posso modificare queste impostazioni nell’interfaccia grafica, immagino perché il YAML del container le impone tramite DISCOURSE_SMTP_ADDRESS ecc.? Ma non riesco a trovare una variabile per il metodo di consegna.

Forse qualcuno conosce un altro modo, e nel frattempo, sto configurando l’autenticazione sulla porta di submission SMTP normale. Grazie per DISCOURSE_SMTP_FORCE_TLS, aggiunto più di recente, ma non ancora parte di alcun esempio (dovrebbe esserlo). Non ho intenzione di consentire STARTTLS, ma solo TLS implicito/immediato.

2

Sovraccarico non necessario come? Devi inviare i dati da Discourse al server SMTP in qualche modo? No?

Ps: se è un altro container, in teoria potresti usare la rete bridge e usare il nome del container smtp invece dell’hostname se è quello che stai cercando, ma non ti darà alcun vantaggio in termini di prestazioni.

2 Mi Piace
3

Ci sono due modi per inviare email tramite un server SMTP locale:

  1. connettersi e autenticarsi alla porta di submission, come la 587 con STARTTLS o la 465 con TLS implicito/immediato => richiesta di rete, controlli e restrizioni applicati tramite smtpd
  2. usare sendmail o simili, che invoca il comando locale pickup (nel caso di Postfix), senza effettuare alcuna connessione di rete, e bypassando tutti i controlli e le restrizioni configurate per il servizio di submission smtpd.

Quest’ultimo è più semplice e veloce, implementato nei comuni sistemi di runtime e framework, come PHP mailer e questa libreria di posta Ruby utilizzata da Discourse. E l’autenticazione viene bypassata, non sono necessarie credenziali in chiaro da memorizzare da nessuna parte. O in altre parole: il server SMTP non viene utilizzato affatto in questo caso, ma solo il client SMTP.

Voglio dire, sì, la connessione alla porta di submission non dovrebbe avere un impatto significativo sul carico del server, rispetto a ciò che fa altrimenti Discourse. Quest’ultimo punto può essere risolto con, ad esempio, la regola smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject alla porta di submission, per consentire le submission dagli IP di loopback (impostazione predefinita, mynetworks), prima di effettuare qualsiasi autenticazione. Se la richiesta dal container viene vista con un altro IP, può essere aggiunta a mynetworks. Immagino che sia così che ha funzionato nel caso del topic che ho linkato prima.

Vedremo la prossima volta che aggiorneremo/ricostruiremo il nostro Discourse, quando verranno applicate le impostazioni SMTP modificate. Riporterò come funziona.

Ma sarebbe comunque interessante sapere se ci sono altri modi e cosa significa l’impostazione “Metodo di consegna”.

Postfix è in esecuzione sull’host, non all’interno di un container, ma non farebbe molta differenza, poiché rimane un’autenticazione basata sulla rete.

Sì, un pensiero successivo, ha senso che sendmail ecc. dall’host/altro container non possano funzionare all’interno di un container, poiché richiedono l’accesso diretto a vaste parti degli eseguibili, delle librerie e delle configurazioni di Postfix, suppongo. A meno che non ci sia una sorta di socket magico che possa essere bind-mounted nel container o qualcosa del genere :smile:.

2 Mi Piace
4

È passato un po’ di tempo da quando mi sono addentrato così tanto nella microgestione di sendmail. Ho il Mailcow stack su una VM e Discourse su un’altra. Non so se varrà mai la pena scavare così a fondo se non per divertimento.

Auguro a tutti voi il meglio nelle vostre avventure, riportate ciò che avete imparato.

1 Mi Piace
5

Probabilmente no :sweat_smile:. Ma sono un perfezionista in certi contesti e mi piace scavare a fondo e imparare tutti i dettagli. Mi ci sono volute diverse sere per configurare Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd, … passo dopo passo, imparando quasi ogni impostazione disponibile, perché i valori predefiniti sono così, se e perché potremmo volerla diversamente, ecc. Ma ehi, ora mi sembra di capire la maggior parte delle cose meglio della maggior parte degli autori di guide arbitrarie sui server di posta elettronica :face_with_tongue:.

6

Sto spostando questo argomento in Installation > Hosting. Non consigliamo di provare a gestire il proprio server di posta elettronica, come sapete se avete letto le istruzioni ufficiali per l’installazione. La posta elettronica è difficile!

7

Non sono sicuro di cosa abbia a che fare Discourse con il fatto che il sistema possa ospitare anche un server di posta elettronica o meno? A parte il fatto che questo teoricamente apre un altro modo per inviare e-mail, ovviamente.

Per ricevere e-mail (altro argomento), tuttavia, ha un effetto, poiché non è possibile ospitare il contenitore del ricevitore di posta elettronica, almeno non per ascoltare direttamente sulla porta 25. Ma l’utilizzo diretto dell’API del ricevitore di posta elettronica di Discourse si è rivelato solo 2-3 righe nella configurazione di Postfix: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng

Ma sono d’accordo, configurare correttamente il server di posta elettronica non è stato esattamente un compito facile, come menzionato sopra. Ma super interessante da imparare :slightly_smiling_face:.

1 Mi Piace
8

Sì! È impegnativo e interessante, di sicuro. Ho avuto le mie avventure installando ogni tipo di servizio e cercando di gestirli da solo, in una vita precedente! :upside_down_face:

Sono felice che tu aggiorni questo argomento con le tue scoperte a beneficio degli intrepidi viaggiatori futuri, te compreso. Ma tieni presente che la categoria Support è per installazioni supportate, discourse core e plugin e componenti ufficiali.

1 Mi Piace
9

Cosa. Dovecoat buono. Perché allora postfix? Perché non dovecoat exim?

10

Cosa c’è che non va in Postfix? Faceva parte della prima guida alla configurazione del server di posta che ho letto e le sue opzioni di filtro interne per ridurre spam e accessi bot all’inizio della pipeline sembravano un buon argomento.

Beh, un po’ fuori tema, per quanto riguarda l’uso di sendmail/pickup da Discourse.

Segnalo questo come risolto/risposto. Ha senso che il container Discourse non possa accedere al sendmail dell’host, indipendentemente dal server. Quindi deve utilizzare la submission SMTP, per la quale è possibile autenticarsi ad esempio tramite l’intervallo di indirizzi IP del container Docker in Postfix, saltando l’autenticazione passdb/userdb su Dovecot.

11

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