Archivio Tag: Mail Server

I fondamentali di Qmail

Qmail SMTPPurtroppo in alcune installazioni con Plesk viene ancora utilizzato Qmail come servizio SMTP. Parallels stessa ha invitato da diverso tempo gli utilizzatori del suo pannello di controllo a migrare il servizio SMTP da Qmail a Postfix, la procedura è banale ed il più delle volte (toccando ferro) fila tutto liscio, ma non tutti ancora l’hanno recepita.

Gestire le code con Qmail è un po’ più impegnativo di Postfix, esiste comunque una vecchia utility open source, qmHandle, semplice da usare e che in casi estremi può tirar fuori dai guai.

Una volta installato, qmHandle è un po’ più spartano rispetto a quelli utilizzabili su Postfix. Tra le tante opzioni si trova la possibilità di avere una statistica molto semplice dei messaggi in coda:

qmHandle -s

oppure una elenco dei messaggi in coda con dettagli (sconsigliabile se la coda è numerosa):

qmHandle -l

volendo è possibile visualizzare solo la lista dei messaggi nella coda locale (opzione -L)  o quelli nella coda remota (opzione -R)

qmhandle permette la cancellazione dei messaggi in coda con diverse modalità, come cancellare il singolo messaggio in coda:

qmHandle -dnumero_del_messaggio

oppure tutti i messaggi in coda:

qmHandle -D

e infine l’ultima opzione di cancellazione, quella più utile second0 me, che permette di cancellare i messaggi in coda che contengono una specifica stringa di testo nel subject, utile ad esempio per cancellare tutti gli errori di not delivery effetto della visita di uno spammer:

qmHandle -Stesto

I fondamentali di Postfix

PostfixAmministrando dei server mail basati su Postfix, c’è una manciata di comandi da tener sempre a portata di mano, che fanno sempre comodo.

Per prima cosa il comando per riprocessare la coda di mail:

postfix flush (postfix -f)

Per lo stesso scopo, è disponibile un altro comando

postqueue -f

Per sapere quanti messaggi ci sono in coda è possibile usare lo stesso comando postqueue:

postqueue -p

o in alternativa il comando

mailq

Per svuotare (cancellare) la coda di mail, ci torna in aiuto il comando postsuper con due modalità:

postsuper -d ALL

per cancellare TUTTI i messaggi in coda, indistintamente, oppure

postsuper -d ALL deferred

per cancellare solo i messaggi che si trovano nella condizione di “deferred”, differiti.

Per maggiori info e per le altre opzioni disponibili, consultare i man dei rispettivi comandi.

L’importanza della password

Posta Elettronica e Sicurezza

A causa di una password banale e troppo facile, in un account creato per dei test e infine dimenticato, un server mail ha sfornato oltre 900.000 (novecentomila!) mail di SPAM in un fine settimana. Non tutte inviate per fortuna, i sistemi di sicurezza ed un intervento mirato hanno bloccato ed eliminato le code.

Ne sono uscite comunque abbastanza, ed ora il server mail si ritrova in tutte le RBL (blacklist) conosciute e non, comprese quelle usate dal Vaticano e dai provider dello Zimbabwe.

Non mi mancherà il lavoro a ferragosto…

Stalker aggiorna ComuniGate Pro

CommuniGate ProL’ottimo groupware CommuniGate Pro, altrettanto ottimo se utilizzato anche solo come mail server, funzione per cui è stato concepito, è stato aggiornato alla major release 5.4.0

La nuova versione di CommuniGate Pro 5.4.0 apporta numerose novità e aggiustamenti, tra cui la versione 4 di Pronto e la beta 1.0b11 di Pronto for Android, la versione a 64 bit del connettore MAPI che arriva alla numerazione 1.54.0.3, migliorie diverse al kernel che ora supporta la codifica UTF-8, e molto altro ancora, anche in merito alla sicurezza.
La nuova versione 5.4.0 è disponibile per licenze aggiornate al 1-06-2010

Da notare, per chi aggiorna dalla versione 5.3, che eventuali account AirSync su iPhone vanno rimossi e riconfigurati.

Contestualmente è stato rilasciato anche CommuniGate Pro 5.3.14, minor e bugfix release disponibile per licenze valide al 1-12-2008, che apporta la versione 3.1.4 di Pronto e una serie di bugfix.

Prima di tutto la Risoluzione Inversa

Postmaster

Parliamoci chiaro, te che ti vuoi mettere un server mail in ufficio: se non rispetti alcune regole basilari, farai un solo un gran casino e poi non ti venire a lamentare qui che le tue mail ti tornano indietro, rifiutate come si rifiuta la presenza di un appestato.

La prima di queste regole fondamentali, è che i server si devono presentare tra di loro, e non devono cercare di spacciarsi per chi non sono, come spesso fanno gli spammer. Buone maniere e sincerità sono alla base di una buona comunicazione anche nella vita reale, o no?

I server mail, quando iniziano a parlare fra di loro prima di cominciare a scambiarsi messaggi di posta, si pongono alcune domande. Anzi è il server di destinazione che le pone al mittente, per verificare che sia davvero un server di posta “perbene” come vorrebbe far credere, che non sia uno spammer o peggio ancora un untore.

Dialogo tra server SMTP:

  • Mittente: “Ciao, devo mandarti un paio di mail per i tuoi utenti!”
  • Destinatario: “Si OK, però prima fa il bravo e dimmi chi sei…”
  • Mittente “Giusto, presentarsi è da serverini ben educati, io mi chiamo mail.cicciabombacanottiera.it”

Il server del destinatario, che non è uno scemo, ha già memorizzato l’indirizzo IP del server del mittente e zitto zitto effettua immediatamente due prove per stabilire che il server del mittente sia effettivamente chi dica di essere.

  1. Come prima verifica, si accerta che al nome host dichiarato corrisponda effettivamente l’indirizzo IP con cui si presenta.
  2. La seconda verifica è la classica prova del nove, verifica cioè che all’IP con cui il server mittente si è collegato corrisponda esattamente il nome host di cui sopra.

In pratica, se al nome mail.cicciabombacanottiera.it è stato assegnato l’IP 123.123.123.123, e questo deve essere convalidato dai DNS, all’indirizzo IP 123.123.123.123 deve corrispondere dell’host, mail.cicciabombacanottiera.it.

Record A, Record PTR, Risoluzione Inversa…

Le due prove sono banali interrogazioni ai server DNS, la prima chiede il record A di un dato nome host, la seconda chiede il record PTR di un indirizzo IP, entrambe devono corrispondere, ma un peso maggiore viene dato in genere al secondo test, per una serie di motivi che magari spiegherò in un secondo tempo.

Succede, e pure molto frequentemente, che chi decide di mettersi in casa un mail server si preoccupa, per forza di cose, di far assegnare un nome all’indirizzo IP pubblico destinato al server, un Record A affinché il server mail sia raggiungibile dal mondo. Per forza di cose, dicevo, altrimenti non riceverebbe una beata fava da nessuno…

L’improvvisato postmaster però non si preoccupa di far assegnare un record PTR all’IP da chi gli fornisce la connessione.  Se ha fortuna, ma capita di rado, la connessione e i DNS sono gestiti dalla stessa azienda, e il responsabile della gestione dei DNS, quando riceve la richiesta del Record A capisce che è importante associare anche il Record PTR. Santuomo…

È vero anche (e va detto, sic!) il problema contrario, ossia che molti mail server non effettuano o non considerano il test del reverse check come un errore, come dovrebbe essere, il più delle volte per una configurazione discutibile o frettolosa, e si lasciano recapitare porcherie da chiunque. Postmaster maldestri…

Morale della favola: i server mail non devono accettare missive dagli sconosciuti, e gli aspiranti postmaster devono preoccuparsi, prima di mettere in produzione un server mail, di avere un indirizzo IP ben configurato nei DNS, con tanto di Risoluzione Inversa.

Non è finita qui, ma il resto lo vediamo poi, un pezzo per volta…

Mentre ero arrivato ormai alla fine della stesura di questo post, mi sono accorto che avevo già scritto riguardo Indirizzi IP e  Risoluzione Inversa. La memoria non è più quella di una volta.
Poco male, repetita iuvant…

I love Instagram