postfix & saslauth - quick and dirty

Questa va nel novero delle attività rapide: "20 minuti e faccio tutto" ma, dopo 3 ore, mi ritrovo irrimediabilmente ancora a litigare con la tastiera...

Partiamo dal principio. Telecamera ip cinesissima, la cui interfaccia web può essere configurata con un server di posta remoto per mandare gli alert.

Come server smtp potrei usare google/yahoo, mettere le mie credenziali e tutto dovrebbe funzionare. Diciamo però che di questo firmware cinese non mi fido e non voglio salvare al suo interno dei dati "sensibili". Inoltre, sulla stessa rete privata della telecamera, c'è un fantastico Raspberry Pi 3 con Raspbian 8: in poco tempo in teoria ci si può installare un bel server di posta solo per le mail della telecamera, e poi chissà, magari torna utile anche per qualcos' altro.

CONFIGURAZIONI DI BASE

Parto da un banale

Dopo l'installazione, parte una procedura guidata di configurazione. Visto che postfix lo conosco molto bene scelgo: "No Configuration". Così facendo però non crea neppure il file /etc/postfix/main.cf (mi ha preso in parola insomma).
Rilancio la procedura guidata di configurazione

e questa volta scelgo

Lascio tutto di default tranne

dove tolgo le parti IPv6 e aggiungo l'indirizzo della rete locale (192.168.1.0/24).

Così facendo, come mi aveva anticipato quando ho scelto il preset "Local Only", postfix si mette in ascolto solo in localhost. Io devo però servire anche la rete locale e gli altri dispositivi ad essa connessi, per cui postfix deve stare in ascolto sull'interfaccia ethernet.

Modifico quindi /etc/postfix/main.cf in questo modo

Sono le solite modifiche di postfix. Che indirizzi ip possono utilizzare il mail server per spedire mail all'esterno?

Visto che questo host non ha certo un FQDM (ha un nome, p3gab, ma non è conosciuto in rete con questo nome e di certo non ha un dominio vero), aggiungo anche

così che, le mail spedite da questo server, arrivino da da mittente@p3gab.

Vado a commentare le righe

per evitare che si presenti l'errore

Tutto funziona correttamente facendo le classiche prove con telnet.

Questo il file main.cf

Vado poi a mettere in /etc/aliases (e a rigenerare la mappa con newaliases)

in modio che, tutte le mail indirizzate a root e al mio utente locale (tipicamente, le mail che genera il sistema automaticamente - tipo logwatch - , lui di certo non riceve mail dall'esterno visto che la porta 25 da fuori non è raggiungibile) vengano girate al mio vero indirizzo mail.

Giusto per curiosità ecco cosa risponde il server postfix a un EHLO.

Fino a qui tutto bene, ho giusto perso un po' di tempo per capire di dover commentare le 2 righe #default_transport = error, #relay_transport = error per non incappare nell'errore "destinatario sconosciuto" (mea culpa, non ho ancora approfondito il motivo per cui accade).
AGG: Qui spiegano il problema
https://serverfault.com/questions/364873/new-mail-server-cant-send-emails-only-receives
In sostanza, fesso io, ho scelto in fase di configurazione il preset "Local Only" e lui, giustamente, come misura di sicurezza aggiuntiva, non permette di inviare mail all'esterno.

Purtroppo però il firmware della telecamera cinese vuole PER FORZA un'autenticazione smtp e non manda mail senza che questa sia stata effettuata: in soldoni, manda al server il comando AUTH LOGIN, il server non lo riconosce e disconnette subito il client.

Nessun problema, basta implementare l'autenticazione SASL.

AUTENTICAZIONE SASL

Per prima cosa controllo che postfix la supporti (leggi, compilato con le librerie sasl, almeno penso).

Vado a utilizzare la cyrus in quanto non ho interesse a installare dovecot.

Installo sasl

Qui l'elenco dei file che vengono installati con questo pacchetto:
https://packages.debian.org/cgi-bin/search_contents.pl?word=saslauthd&searchmode=searchfiles&case=insensitive&version=stable&arch=i386

Per far partire il demone devo andare, come minimo, a modificare il file di configurazione
/etc/default/saslauthd, andando a specificare:

(adoro - per davvero - quando gli sviluppatori impongono queste modifiche,solo per assicurarsi che l'utente guardi almeno una volta il file di configurazione).

Vado ad aggiungere l'utente postfix al gruppo sasl (file /etc/group).

Ora non mi resta che modificare il file /etc/postfix/main.cf andandogli a dire di utilizzare l'autenticazione sasl. Queste le direttive che aggiungo

Un EHLO al server (dopo averlo riavviato), rivela le nuove capacità di autenticazione dello stesso:

Andando a "spluciare" il file /etc/default/saslauthd, vedo che come meccanismo di autenticazione ha "PAM", per cui vado a creare un utente di sistema di prova per testare se l'autenticazione funziona. Anche se solo di prova darò come shell /sbin/nologin.

Creo l'utente testuser/testpass, e poi provo l'autenticazione con il comando testsaslauthd (dopo aver fatto partire il demone saslauthd tramite systemd).

Ora, è evidente che postfix deve parlare al demone sasl tramite socket. Questo socket, guardando
- systemctl status saslauthd
- oppure /etc/default/saslauthd (OPTIONS="-c -m /var/run/saslauthd")
- oppure la documentazione in /usr/share/doc/sasl2-bin/README.Debian
é
/var/run/saslauthd.

Purtroppo, se si lascia tutto così, l'autenticazione funziona quando si prova con testsaslauthd, ma fallisce miseramente quando da postfix si lancia il comando AUTH LOGIN (o AUTH PLAIN).
Qui un bel link che spiega come fare le prove
https://networking.ringofsaturn.com/Protocols/howtotestsendmailauthentication.php

Lanciando il demone saslauthd in modalità debug in questo modo

noto che, quando lancio il test

ho una risposta

Quando invece mando il comando AUTH LOGIN tramite postfix non ho alcuna risposta, quindi NON stanno comunicando tramite quel socket.

Il problema è questo
https://wiki.debian.org/PostfixAndSASL

ovvero, postfix di default è configurato per "girare in chroot", per cui non riesce ad accedere al socket creatogli da sasl.
Per risolvere è sufficente configurare postfix per non funzionare nella gabbia chroot.
/etc/postfix/master.cf

(la cosa importante è la seconda n).
Questo ultimo passaggio è quello che mi ha fatto perdere 3 ore di tempo, sia per capire il vero motivo (chroot si/no), sia poi per cercare di far dialogare comunque i 2 sistemi pur tenendo postfix in chroot (pare possibile, vedi i miei tentativi qui in fondo, ma non ci sono riuscito).

Ora un'ultima modifica: per quanto l'utente creato per test non abbia shell (/sbin/nologin), non mi piace avere un utente di sistema che in realtà è fasullo e serve solo per fare l' autenticazione smtp. Per questo motivo andrò a utilizzare, come metodo di autenticazione sasl, sasldb e non PAM (o shadow).

SASLDB PLUGIN

Per prima cosa vado a creare una coppia utente/password tramite il comando saslpasswd2 (utente: copia, password: incolla).

Elenco gli utenti creati.

Vado a configurare /etc/default/saslauthd per utilizzare il sasldb e non più PAM.

Il db creato è il file /etc/sasldb2

e deve essere leggibile dall'utente postfix.

Effettuo il restart di saslauthd e controllo che il servizio stia utilizzando il plugin giusto (sasldb e non pam).

Rifaccio le prove di autenticazione, sia con testsaslauthd che con postfix, e, questa volta,  fila tutto liscio.

APPENDICE


main.cf finale


Tentativi di far funzionare sasl con postfix in chroot.

Vado a modificare /etc/default/saslauthd mettendo, come da documentazione, il socket in:

Effettuo le configurazioni consigliate nella documentazione /usr/share/doc/sasl2-bin/README.Debian

Purtroppo però continua a funzionare solo il tester (peraltro specificando a mano il socket in posizione non standard)


NOTA GOOGLE

Certo che, se poi ci si mette anche gmail a complicare la vita con messaggi di questo tipo:

In sostanza: l'ip dinamico che mi è stato assegnato dal provider (Vodafone) ha una cattiva reputazione, per cui google si rifiuta di accettarne la posta.
Peraltro, il mio stesso indirizzo ip è in una blacklist di spamhaus
https://www.spamhaus.org/query/ip/x.y.z.k.h
la PBL, ovvero una lista di indirizzi ip non abilitati a inviare posta non autenticata. Credo che spamhaus sappia che quel range di indirzzi è dinamico e per clienti home, per cui di default non dovrebbe torvarcisi un server di posta ma dei client che si autenticano per spedire la posta. Che delusione però, non si può neppure più giocare.

Print Friendly, PDF & Email