Inviare email dalle app self-hosted senza mail server

Quali app self-hosted devono inviare messaggi email

Per inviare messaggi email dalle app self-hosted non serve un server di posta. Serve un relay: un account SMTP autenticato, configurato una sola volta sull’host, a cui tutte le app del server affidano la posta in uscita. Gestire le caselle di posta è il problema più complesso, ed è un problema diverso.

Ricevere posta significa accettare connessioni da tutta Internet sulla porta 25, filtrare lo spam, archiviare e sottoporre a backup le caselle e proteggere la reputazione dell’indirizzo IP per tutto il periodo in cui il server resta operativo. Questo compito è diventato effettivamente più difficile. Inviare posta significa gestire il reset della password, la conferma della registrazione, l’avviso di “backup non riuscito” e la notifica di una risposta sul forum. Si tratta di messaggi brevi, a basso volume, inviati uno alla volta. Un relay li gestisce e la configurazione richiede un pomeriggio.

Stabilisci quale dei due problemi devi risolvere. Valutare se gestire ancora una propria casella di posta convenga è una domanda reale con una risposta concreta e, per la maggior parte delle persone, la risposta è no. Se la tua risposta è sì, un server di posta Mailcow completo su un VPS è la soluzione corretta. L’altra parte, l’invio, serve quasi a tutti, ma quasi nessuno la pianifica.

Prima, due termini. SMTP (simple mail transfer protocol) è il protocollo utilizzato da ogni componente di questa configurazione. Un relay, chiamato anche smarthost, è un server che accetta la posta autenticata e la consegna ai destinatari usando i propri indirizzi e la propria reputazione.

Perché il tuo VPS non può consegnare posta sulla porta 25

Quasi tutti i provider VPS bloccano per impostazione predefinita la porta TCP in uscita 25. La porta 25 è quella utilizzata dai server di posta per comunicare tra loro. Un VPS compromesso con la porta 25 in uscita aperta potrebbe quindi inviare spam direttamente a ogni server di posta ricevente. I provider eliminano quei pacchetti invece di rifiutarli. Per questo il sintomo è una connessione che resta in attesa e poi va in timeout, non un errore.

Esegui il test dal server:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Se il primo comando resta in attesa per tutti i cinque secondi, mentre il secondo risponde immediatamente, il blocco è confermato. Alcuni provider lo rimuovono dopo una verifica dell’account. La maggior parte non lo fa.

Il blocco non è il motivo principale per usare un relay. Anche con la porta 25 aperta, i messaggi inviati direttamente da un indirizzo VPS appena assegnato finiscono nello spam oppure vengono rifiutati, perché quell’indirizzo non ha una cronologia di invio e appartiene a un intervallo che i server riceventi considerano spazio di hosting. Le indicazioni di Google per i mittenti richiedono DNS forward e reverse validi per l’IP di invio. Inoltre, molti indirizzi VPS hanno un record PTR (pointer) generico che non è possibile modificare. Un relay mette a disposizione indirizzi che hanno già una cronologia.

Le porte di submission sono la soluzione. La porta 587 usa STARTTLS: la sessione inizia in chiaro e viene poi aggiornata a TLS. La porta 465 usa TLS implicito (transport layer security): la sessione è cifrata fin dal primo byte. Entrambe sono destinate ai client autenticati, entrambe sono aperte sulle reti VPS e il tuo relay supporta almeno una delle due.

Scegli un relay e un sottodominio per l’invio

Esistono molti provider di posta transazionale e svolgono tutti la stessa funzione. Valutali in base a quattro aspetti:

• una porta di submission, 587 o 465, con SMTP AUTH
• la firma DKIM con il tuo dominio e il tuo selector, non soltanto con quello del provider
• dati su bounce e reclami consultabili tramite dashboard o webhook
• un piano adatto al tuo volume. Ad agosto 2026 diversi provider includono ancora alcune migliaia di messaggi al mese senza costi, ma queste condizioni cambiano spesso; consulta quindi la pagina dei prezzi aggiornata e non un post di blog

Invia la posta delle applicazioni da un sottodominio. Usa ad esempio notify.example.com invece di example.com. I destinatari valutano la reputazione per dominio, quindi un invio problematico dalle applicazioni resta separato dal dominio utilizzato per le fatture e per la posta del team. Non considerare questa separazione assoluta: alcuni destinatari aggregano i segnali dei sottodomini al dominio organizzativo. Un sottodominio riduce quindi l’impatto, ma non lo elimina.

Configura il relay una sola volta per ogni applicazione self-hosted

L'approccio più immediato consiste nell'aprire la pagina delle impostazioni di ogni applicazione e inserirvi host SMTP, nome utente e password. Nextcloud, il forum, Grafana, Vaultwarden e il monitor di uptime hanno tutti quel modulo. In questo modo la credenziale viene memorizzata in sei punti e in sei formati diversi; in diversi casi finisce in un database che esegui il backup come dati, non come configurazione. Quando ruoti la password, ne aggiorni cinque. La sesta applicazione smette di inviare messaggi senza avvisare: la maggior parte delle applicazioni registra l'errore SMTP lato server e mostra comunque all'utente una pagina di operazione completata.

Configura invece il relay una sola volta sull'host e fai inviare i messaggi alle applicazioni localmente. Esistono due strumenti adatti a questo scopo; la scelta dipende dalla gestione della coda.

msmtp è un client compatibile con sendmail e non usa un daemon. Si connette, invia il messaggio e termina. Non dispone di una coda: se il relay non è raggiungibile, il messaggio va perso e l'applicazione chiamante riceve uno stato di uscita diverso da zero.

Postfix configurato come satellite è un mail transfer agent completo, con una coda reale. Accetta subito il messaggio, ritenta per giorni in caso di errore e conserva la credenziale del relay in un file accessibile soltanto a root. Usalo quando è importante non perdere un avviso durante un'interruzione del relay oppure quando più applicazioni vengono eseguite con utenti di sistema diversi.

msmtp, l'opzione più semplice

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta installa il symlink /usr/sbin/sendmail, quindi qualsiasi programma che richiama sendmail raggiunge msmtp senza sapere che è presente.

Scrivi /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on imposta sempre un'intestazione From e sostituisce quella esistente, quindi rimpiazza il valore prodotto dall'applicazione con l'indirizzo in from. Senza questa opzione, un cron job invia i messaggi come root@your-hostname e il relay li rifiuta perché non è un indirizzo verificato. syslog on invia il log a syslog, quindi puoi leggerlo con journalctl -t msmtp. In alternativa puoi usare un percorso logfile condiviso, ma ogni utente che invia messaggi deve avere il permesso di scrivervi. Su un host multiutente questa configurazione crea facilmente problemi.

Imposta manualmente i permessi. msmtp applica i controlli ai file di configurazione per-utente (~/.msmtprc), per i quali rifiuta l'esecuzione con contains secrets and therefore must have no more than user read/write permissions. Non applica alcun controllo a /etc/msmtprc, perché carica semplicemente quel file se è leggibile.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v stampa l'intera conversazione SMTP, quindi puoi vedere ogni risposta del relay. Un invio riuscito termina con una risposta 250 che accetta il messaggio. Una riga authentication failed indica che il nome utente o la password non sono corretti, oppure che il relay richiede una chiave API al posto della password dell'account.

Qui emerge il limite principale, ed è il motivo per cui molte persone scelgono Postfix. Con la modalità 600 e il proprietario root, solo root può inviare messaggi. Un'applicazione eseguita come www-data non può leggere il file; msmtp lo ignora e l'applicazione termina con un errore che indica che l'account predefinito non è stato trovato. La soluzione consiste nell'usare un gruppo:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

Questo significa, in modo esplicito, che ogni membro del gruppo mail può leggere la password del relay e inviare messaggi dal server usando il tuo dominio. Su un VPS amministrato soltanto da te, è una configurazione accettabile. Se invece eseguono applicazioni che non hai scritto tu, con utenti diversi, non lo è. In questo caso Postfix è la scelta migliore, perché tali applicazioni non vedono mai la credenziale.

Postfix come satellite

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules è obbligatorio. Senza di esso Postfix registra warning: SASL authentication failure: No worthy mechs found, perché le librerie dei meccanismi PLAIN e LOGIN non sono installate in /usr/lib/sasl2.

Imposta il resto con postconf -e, che modifica direttamente /etc/postfix/main.cf:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

Le parentesi quadre intorno all'hostname del relay impediscono a Postfix di cercare un record MX per quel nome e fanno sì che si connetta direttamente all'hostname. Alcuni hostname dei relay pubblicano record MX che puntano altrove. Senza le parentesi, i messaggi seguono quei record e raggiungono il server sbagliato.

smtp_tls_security_level = encrypt rende TLS obbligatorio, quindi il messaggio non viene mai inviato in chiaro. Questa opzione non verifica il certificato. La documentazione di Postfix è esplicita: a quel livello la consegna continua anche se il certificato del server non è attendibile o contiene un nome errato. Se vuoi verificare il certificato, usa verify oppure secure e lascia impostato smtp_tls_CAfile.

La credenziale viene inserita in un unico file accessibile soltanto a root:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap crea la copia indicizzata che Postfix legge effettivamente. Se in seguito modifichi il file di testo e dimentichi postmap, Postfix continua a usare il vecchio database senza registrare nel log alcuna indicazione. In Postfix 3.9 e versioni successive, il tipo di mappa predefinito è lmdb. Se preferisci questo tipo, scrivi lmdb: sia nel parametro sia nell'argomento postmap. Specificare il tipo in entrambe le righe mantiene coerenti le due configurazioni.

Le applicazioni continuano a indirizzare la posta a root@hostname. Riscrivi il mittente:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Una tabella regexp: viene letta direttamente, quindi non richiede alcun postmap. Da questo momento ogni messaggio esce con lo stesso mittente dell'envelope e la stessa intestazione From, come richiesto dal relay. Lo svantaggio è che tutte le risposte arrivano nello stesso punto. Imposta quindi un'intestazione Reply-To nelle singole applicazioni, specificando l'indirizzo della persona che deve ricevere le risposte.

Invia un messaggio di test e leggi il log:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Un messaggio consegnato registra status=sent, seguito tra parentesi dalla risposta del relay. Qualsiasi altro valore indica il motivo dell'errore. status=deferred con Connection timed out significa che qualcosa punta ancora alla porta 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A indica che l'hostname del relay è errato oppure che il DNS non funziona sul server. mailq elenca i messaggi bloccati e sudo postqueue -f li ritenta immediatamente.

Raggiungere il relay dell’host dai container Docker

Un container non può chiamare il sendmail dell’host, perché il binario non è presente nell’immagine e la coda non è condivisa. Fornisci invece ai container una destinazione di rete. Postfix può restare in ascolto sull’indirizzo del bridge Docker.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Leggi il tuo indirizzo del bridge dal primo comando, invece di copiare questo valore, perché un progetto Compose crea una propria rete su una subnet diversa e docker network inspect <name> la visualizza. Usa restart e non reload: la documentazione di Postfix specifica che, dopo la modifica di inet_interfaces, devi arrestare e riavviare il servizio; un reload non applica la modifica. Ogni applicazione usa quindi il server SMTP 172.17.0.1, la porta 25, senza autenticazione e senza TLS, perché questo traffico non lascia mai l’host. Se i tuoi servizi si trovano su una rete Compose, eseguire Docker Compose su un VPS spiega da dove proviene quella subnet.

Questo è il passaggio che può causare problemi. Un Postfix in ascolto su un indirizzo pubblico con un mynetworks permissivo è un open relay: utenti sconosciuti inviano la propria posta tramite il tuo account relay, il provider lo sospende e la reputazione del tuo dominio viene danneggiata per mesi. Controlla entrambi i lati dopo ogni modifica.

ss -tlnp | grep ':25'

L’output deve mostrare solo l’indirizzo di loopback e l’indirizzo del bridge. Da un’altra macchina, nc -vz your.server.ip 25 deve fallire.

SPF, DKIM e DMARC per il dominio di invio

Pubblica tutti e tre i record prima del primo invio reale. Sono gratuiti, sono record DNS e sono i primi elementi che i server destinatari verificano.

SPF (sender policy framework) elenca i sistemi autorizzati a inserire il tuo dominio nel mittente dell'envelope. Pubblicalo sul sottodominio di invio:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Copia il valore include: dalla pagina di configurazione del relay, perché un include che non si risolve produce un errore permanente invece di un pass. La valutazione SPF si interrompe dopo dieci meccanismi che eseguono query DNS e restituisce permerror. I server destinatari lo considerano un errore, quindi limita il numero di include. Pubblica esattamente un record v=spf1 per ogni nome: due record producono anch'essi un permerror.

DKIM (domainkeys identified mail) firma ogni messaggio con una chiave privata detenuta dal relay, mentre i server destinatari recuperano la chiave pubblica corrispondente dal DNS. Il relay fornisce un selector e un record TXT oppure un CNAME da pubblicare:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM è più importante di SPF perché continua a funzionare dopo l'inoltro. Quando una mailing list o una regola .forward inoltra il messaggio, questo arriva dall'indirizzo IP del sistema che lo ha inoltrato. SPF quindi fallisce, mentre la firma continua a essere verificata correttamente.

DMARC (domain-based message authentication, reporting and conformance) indica ai server destinatari come comportarsi quando nessuno dei due controlli è allineato e chiede loro di inviare report. Pubblicalo sul dominio organizzativo:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Inizia con p=none e leggi i report per due settimane. p=none non modifica la consegna dei messaggi: abilita soltanto i report. In questo modo puoi individuare i sistemi che avevi dimenticato e che inviavano messaggi usando il tuo dominio. Passa quindi a p=quarantine e infine a p=reject. Pubblicare p=reject il primo giorno permette di scoprire che il sistema di fatturazione stava inviando messaggi usando il dominio, ma soltanto dopo che un cliente non ha ricevuto una fattura.

Controlla ciò che è visibile su Internet, non ciò che mostra il pannello DNS:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Un output vuoto indica che il record non è ancora stato propagato oppure che il nome è errato. Un record corretto cinque minuti fa può continuare a risultare errato nelle cache per la durata del TTL precedente (time to live). Controlla quindi il TTL prima di trarre conclusioni.

Mantieni allineati From e Return-Path

Ogni messaggio contiene due indirizzi del mittente, verificati in modo diverso. Il mittente della busta viene specificato nel comando SMTP MAIL FROM e compare nel messaggio consegnato come Return-Path. L’intestazione From contiene l’indirizzo visualizzato dal destinatario.

SPF verifica il dominio del mittente della busta rispetto all’indirizzo IP del client connesso. DKIM indica il dominio che ha firmato il messaggio, come d=. DMARC ha esito positivo solo quando almeno uno di questi due domini è allineato al dominio dell’intestazione From. Con l’allineamento rilassato (adkim=r, aspf=r, impostazione predefinita) viene considerato valido anche un sottodominio. Di conseguenza, un mittente della busta su notify.example.com è allineato a un’intestazione From su example.com. Con l’allineamento rigoroso non lo è.

La regola pratica è semplice: usa lo stesso dominio per l’intestazione From e per il mittente della busta. In questo modo il problema non si presenta. È esattamente ciò che set_from_header on configura in msmtp e ciò che sender_canonical_maps configura in Postfix.

Leggi il verdetto nel messaggio consegnato. In Gmail, "Mostra originale" visualizza l’intestazione scritta dal destinatario:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

In questo caso tutti e tre i controlli hanno esito positivo. Qualsiasi altro risultato indica il controllo che ha avuto esito negativo e, di solito, anche il motivo. È l’informazione più rapida per eseguire il troubleshooting su questo argomento.

Bounce e segnalazioni, prima che aumenti il volume

Un bounce si verifica quando il destinatario rifiuta il messaggio. Un hard bounce è permanente e Gmail lo indica come 550 5.1.1 The email account that you tried to reach does not exist. Un soft bounce è temporaneo: può restituire un codice 4xx perché la casella è piena o per effetto del greylisting, quindi il relay riprova automaticamente.

I relay misurano il tasso di hard bounce e sospendono gli account che continuano a inviare messaggi a indirizzi inesistenti, perché questo comportamento è tipico di una lista acquistata. Le segnalazioni sono ancora più importanti. Una segnalazione si verifica quando una persona preme il pulsante antispam. Le linee guida di Google per i mittenti (verificate ad agosto 2026) chiedono di mantenere il tasso di spam sotto lo 0.30%, secondo i dati di Postmaster Tools, e raccomandano di restare sotto lo 0.10%.

Prima che aumenti il volume, predisponi questi quattro elementi:

• un webhook, oppure un controllo settimanale della suppression list del relay, per rilevare tutti i bounce
• un indirizzo From corrispondente a una casella reale che qualcuno controlla, con Reply-To configurato per indicare la destinazione delle risposte
• una conferma prima di aggiungere qualsiasi indirizzo, in modo da non inviare mai messaggi a un indirizzo che il proprietario non ha inserito
• un rate limit sul modulo che attiva l'invio dei messaggi

Gli ultimi due punti sono quelli che causano per primi i problemi nelle applicazioni self-hosted. Un modulo di registrazione non protetto consente a chiunque di inserire l'indirizzo di un'altra persona. Il server invia la conferma e il destinatario la segnala come spam. Bloccare l'abuso dei moduli di iscrizione è un'attività di deliverability tanto quanto di prevenzione degli abusi.

Non usare questo percorso per la posta bulk. Le newsletter richiedono la gestione delle liste e gli header per la disiscrizione, che la posta transazionale non include. Gestiscile quindi tramite un'istanza self-hosted di Listmonk su un sottodominio dedicato, con una reputazione distinta. La posta di notifica proveniente da un forum self-hosted si colloca nel mezzo: ha una struttura transazionale, ma un volume bulk. Di solito è il primo tipo di messaggio a mostrare se la configurazione è affidabile.

Come riferimento, le regole di Gmail per i mittenti bulk si applicano oltre 5,000 messaggi al giorno inviati a indirizzi Gmail e richiedono SPF, DKIM, DMARC e la disiscrizione con un clic per la posta di marketing. La maggior parte delle applicazioni self-hosted non raggiunge questa soglia. La parte relativa all'autenticazione è ormai richiesta da ogni mittente, indipendentemente dal volume.

Provalo prima di considerarlo affidabile

swaks è lo strumento adatto. Parla SMTP e stampa l’intera conversazione, così puoi vedere quale passaggio non è riuscito.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

Questo verifica direttamente le credenziali sul relay. Per verificare il percorso usato effettivamente dalle applicazioni, indica invece l’host relay:

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

Controlla quindi il risultato end-to-end, direttamente dal server, inviando messaggi reali. Nulla di tutto questo può essere dimostrato dai soli file di configurazione, quindi esegui personalmente i test:

• invia un messaggio a un servizio di valutazione come mail-tester.com, che analizza SPF, DKIM, DMARC e il contenuto del messaggio e spiega le ragioni del punteggio
• invia un messaggio a una casella presso ciascuno dei due provider effettivamente utilizzati dagli utenti e leggi Authentication-Results nel messaggio originale
• analizza un messaggio con learndmarc.com quando il risultato dell’allineamento non è evidente
• avvia un invio direttamente dall’applicazione, non soltanto dalla riga di comando, perché è l’applicazione a impostare l’header From

Un ultimo avvertimento. Anche un dominio nuovo con tutti e tre i record corretti può finire nello spam, perché non ha ancora una cronologia e i destinatari prestano attenzione ai domini comparsi la settimana precedente. Inizia con volumi ridotti e invia messaggi che gli utenti si aspettano. La reputazione si costruisce da quel momento in poi e nessuna configurazione può evitare questa fase.

FAQ

Perché la porta in uscita 25 è bloccata sul mio VPS?

Quasi tutti i provider bloccano per impostazione predefinita la porta TCP 25 in uscita, perché un server compromesso con quella porta aperta può inviare spam direttamente ai server di posta destinatari. I pacchetti vengono scartati invece di essere rifiutati, quindi il sintomo è una connessione che resta in attesa e poi va in timeout, non un messaggio di errore. Verificatelo eseguendo nc -vz -w 5 gmail-smtp-in.l.google.com 25 accanto a nc -vz -w 5 smtp.relay.example 587: il primo resta in attesa, mentre il secondo risponde immediatamente. La soluzione non è chiedere la rimozione del blocco. Inviate i messaggi tramite un relay sulla porta di submission 587 o 465, che restano aperte e sono destinate ai client autenticati.

Mi servono SPF, DKIM e DMARC per inviare solo poche notifiche dell'applicazione?

Sì, e il volume non cambia la situazione. I server destinatari applicano gli stessi controlli a un singolo messaggio per la reimpostazione della password e a una campagna di cinquantamila messaggi. Senza SPF e DKIM, la posta non è autenticata e le attuali indicazioni di Google per i mittenti richiedono almeno uno dei due meccanismi per ogni mittente. Senza DMARC non ricevete report, quindi il primo segnale di un problema può essere un utente che segnala di non aver ricevuto il link di reimpostazione. Tutti e tre sono record DNS, non hanno costi e la loro pubblicazione richiede circa dieci minuti.

Devo usare msmtp o Postfix come client relay?

Usate msmtp quando una sola persona amministra il server e la perdita di un messaggio durante un'interruzione del relay è accettabile. Consiste in un unico file di configurazione, senza demone, e non accoda i messaggi: se il relay non è raggiungibile, il messaggio viene perso. Usate Postfix come satellite quando vi serve una coda che ritenti l'invio per giorni o quando più applicazioni vengono eseguite con utenti di sistema diversi. Postfix conserva la password del relay in un file accessibile soltanto a root, che le applicazioni non leggono mai, mentre msmtp richiede che il relativo file di configurazione sia leggibile da ogni utente che invia messaggi.

Perché la posta della mia applicazione viene rifiutata perché proviene da root?

I job cron e molte applicazioni costruiscono il mittente usando l'utente locale e il nome host, producendo un valore simile a root@srv1.localdomain. Questo non è un indirizzo verificato presso il relay, quindi il relay rifiuta il messaggio con una risposta 553 o 554 che indica l'indirizzo del mittente. Correggete il problema a livello di host, invece di intervenire in ogni applicazione: set_from_header on insieme a un indirizzo from in /etc/msmtprc, oppure sender_canonical_maps con sender_canonical_classes = envelope_sender, header_sender in Postfix. Impostate Reply-To in ogni applicazione se le risposte devono raggiungere una persona.

Un sottodominio separato per la posta dell'applicazione protegge davvero il dominio principale?

In parte, e conviene comunque utilizzarlo. I destinatari valutano la reputazione per dominio, quindi i reclami relativi a notify.example.com restano in gran parte associati a notify.example.com, mentre il dominio principale continua a recapitare i messaggi. Il limite è concreto: alcuni destinatari riportano i segnali dei sottodomini al dominio organizzativo e una policy DMARC pubblicata a livello organizzativo si applica ai sottodomini, a meno che non impostiate separatamente sp=. Considerate il sottodominio una misura di contenimento dei danni, non una garanzia.