D.A.P. Copertina Sysctl

Articoli

Sendmail considered harmful

Proviamo a elencare alcuni pro e contro di sendmail:
pro:

• è estremamente flessibile:
  permette di operare ogni genere di riscrittura degli header utilizzando le regole presenti in sendmail.cf.
  Inoltre permette di usare bang path e mandare direttamente posta a siti bitnet (se qualcuno ne avesse ancora bisogno);
• è conosciuto da tutti
  bene o male ogni sysadmin degno di questo nome sa almeno configurare le funzioni più semplici;
  
• è l'implementazione di riferimento per SMTP
  nel bene e nel male chi scrive un programma che parli SMTP deve tenere conto del fatto che sendmail è l'MTA più diffuso.

• è altamente insicuro
  in ogni major release vengono tappati mediamente mezza dozzina di buchi nella sicurezza più o meno gravi. Anche se il suo codice viene scrutinato da anni dai maggiori esperti di sicurezza si continuano a trovare vecchi e nuovi bug e più di una volta Daniel J. Bernstein (l'autore di qmail) ha pubblicamente segnalato in comp.security.unix dei bug a poche ore dall'uscita di una nuova release. Il fatto che si tratti di un unico binario setuid root non aiuta per niente ad ottenere del codice pulito e sicuro;
  
• è estremamente lento
  praticamente tutti gli altri MTA lo battono in velocità;
  
• è scomodo da configurare
  anche se io personalmente preferisco giocare un'ora con sendmail.cf ed m4 piuttosto che con quake capisco che altre persone possono avere preferenze diverse, e per un normale utente che vuole mandare la propria posta al provider non è accettabile dovere leggere 120 pagine di manuale, anche se è completo ed estremamente conciso. Comunque una volta imparati i pochi concetti necessari a capire una regola di riscrittura si può leggere sendmail.cf senza dover sapere altro, al contrario di MTA tipo smail dove è necessario imparare a memoria i nomi di moltissimi parametri.

• è ragionevolmente sicuro
  come risultato di essere stato scritto con una attenzione maniacale per la sicurezza, qmail è formato da diversi piccoli programmi che girano con 7 userid differenti non privilegiati e da un solo programma di 15 kb che ha i privilegi di root (necessario per cambiare uid e lanciare il programma che scriverà il messaggio nella home dell'utente). Il sorgente non è stato esaminato tanto come quello di sendmail, ma per ora c'è voluto Wietse Venema per escogitare un attacco DOS contro qmail (che è causato da una mancanza della documentazione piuttosto che da un bug vero e proprio) e ci sono due concorsi che offrono premi in denaro a chi per primo troverà una falla nella sua sicurezza;
  
• è velocissimo
  è uno degli MTA più veloci, e supera sendmail con la massima facilità. Secondo le prove dell'autore supera di molte volte anche Zmailer;
  
• è molto facile da configurare
  si configura tramite dei file di testo, anche se può essere complicato imparare i nomi di ciascuno. Ogni utente può gestire le proprie mailing list e avere un numero arbitrario di alias, riducendo la necessità di usare filtri come procmail;
  
• è affidabile
  si ha la garanzia che una volta accettato un messaggio questo non venga perso. Inoltre qmail può salvare la posta nel formato Maildir, che non necessita di lock ed è resistente ai crash di sistema ed alle perversioni di NFS;
  
• è flessibile
  aggiungendo programmini esterni e piccoli script può fare quasi tutto quello che fa sendmail, e di sicuro tutto quello che fa sendmail senza aggiungere proprie regole di riscrittura.

• è diverso da sendmail out of the box non supporta i file .forward di sendmail (ha un suo sistema proprietario, ma se necessario si può usare un add on dell'autore per farlo) e /etc/aliases (c'è un add on anche per questo) e in certi casi insiste in una stretta aderenza agli standard;
  
• consegna la posta concorrentemente
  viene aperta una connessione per ogni messaggio che si vuole mandare, anche se tutti allo stesso host. Secondo prove dell'autore questo permette prestazioni migliori, ma intasa alcuni mailer come il gateway SMTP di Novell;
  
• non consegna messaggi con envelope multipli
  invece di mandare lo stesso messaggio a più destinatari (quando stanno sullo stesso host) manda a ciascuno di loro una copia del messaggio.

• server con utenti non fidati che ne potrebbero compromettere la sicurezza
  
• exploder per grandi mailing list
  
• server con poche risorse
  
• comodo gestore di virtual domain
  
• gestore di utenti mail only (non serve creare un account per ogni utente)
  
• computer connessi solo via PPP (insieme a serialmail)

• la posta viene consegnata di default in ~/Mailbox per avere una maggior sicurezza, quindi bisogna impostare una variabile $MAIL=~/Mailbox in /etc/profile;
• .forward non viene più consultato, ma viene usato .qmail che è molto più flessibile;
• ogni utente può creare delle mailing list tipo "nomeutente-lista" semplicemente creando un file .qmail-lista e usando il piccolo list manager fornito;
• gli alias che non contengono un username sono considerati relativi all'utente "alias", per esempio l'alias di root viene gestito dal file ~alias/.qmail-root;
• gli utenti di sistema (cioè quelli che non possiedono la propria home directory e root) per motivi di sicurezza non possono ricevere posta, ma devono essere gestiti attraverso un alias;
• gestisce le ricevute tramite l'header Notice-Requested-Upon-Delivery-To;
• ha di serie un demone pop3 che non necessita di avere un utente in /etc/passwd per ogni mailbox;
• per massimizzare le prestazioni, prima di consultare /etc/passwd qmail può utilizzare un database compilato.

Di solito chi ha una semplice connessione PPP con un provider è costretto a usare sendmail con hack di ogni tipo per tenere la posta diretta all'esterno nella coda e per uscire con un From e un envelope corretti.

serialmail è un programma scritto apposta per risolvere questo problema, manda con SMTP la posta al proprio provider prendendola dalla maildir (il formato di mailbox sicuro inventato dall'autore) dove qmail la consegna.

L'installazione di qmail è molto semplice e descritta chiaramente nei file INSTALL* forniti e nelle FAQ, quindi non mi ci soffermerò. Per gestire la posta diretta al proprio provider bisogna:

• creare una maildir che contenga tutta la posta in uscita:

  /var/qmail/bin/maildirmake ~alias/pppdir
  chown -R alias.root ~alias/pppdir
  chmod -R 700 ~alias/pppdir
  

  
  
• specificare i domain locali:

  echo 'FQDN.del.mio.pc'>~qmaild/control/locals
  

• creare un virtual domain che riceva la posta per ogni domain:

  echo ':alias-ppp'>~qmaild/control/virtualdomains
  

• creare un alias che metta nella maildir la posta di questo finto domain:

  echo './pppdir/'>~alias/.qmail-ppp-default
  

• e per finire inserire in /etc/ppp/ip-up un comando che mandi la posta al proprio provider (1.2.3.4 è l'IP del mail server remoto):

  /usr/lib/serialmail/maildir2smtp \
    ~alias/pppdir alias-ppp- 1.2.3.4 FQDN.del.mio.pc \
    | /usr/lib/serialmail/maildirbounce
  

• inoltre si può fare in modo che la posta indirizzata al proprio indirizzo internet venga consegnata al proprio utente locale invece di essere mandata al provider:

  echo 'user@provider.it:login@FQDN.del.mio.pc'>~qmaild/control/recipientmap
  

Ma non finisce qui. Con un pò di lavoro è anche possibile gestire la posta fidonet tramite ifmail (che deve essere eseguito con un userid particolare e quindi non può essere configura da un semplice alias), come fare è spiegato in una versione aggiornata dell'Ifmail-HOWTO.

Il sito di partenza per cercare qualcosa a proposito di qmail è www.qmail.org, dove si possono trovare gli archivi della mailing list di qmail e le patch non ufficiali.

Detto questo, indosso le mie fedeli mutande di amianto e aspetto con fiducia i vostri commenti.

di Marco D'Itri

D.A.P. Copertina Sysctl