Abbiamo già visto nei numeri precedenti che cosa serve ad un sistema unix per leggere o spedire la posta localmente. Si è parlato di MUA e di MTA, concetti che riprendiamo ora per meglio capire cosa sia sendmail, come funzioni, come si compila, configura ed installa sulla nostra macchina.
Il modo migliore per spiegare il funzionamento di sendmail sta nel prendere in considerazione la analogia con la posta che tutti conosciamo, quella cartacea che in Italia non funziona troppo bene.
Mentre l?ufficio postale trasporta lettere reali in buste reali, sendmail trasporta lettere elettroniche in buste elettroniche. Se il destinatario e? nella vostra citta? o nello stesso quartiere, presumibilmente sara? coinvolto un solo ufficio postale. Se il destinatario e? sulla vostra stessa macchina (quindi locale) sendmail lavorera? in locale. Se il destinatario e? molto lontano, un altra citta? o un altro stato, la vostra lettera passera? da diversi uffici postali ed analogamente sendmail lavorera? in locale ed in remoto sulla macchina del destinatario. Una grande differenza sta nei tempi di consegna, che nel caso di sendmail sono ridotti a pochi secondi mentre per la lettera cartacea si parla di giorni. Inoltre grazie all?aggiornamento dei DNS, anche se la macchina del destinatario cambia localizzazione fisica, ricevera? sempre la posta senza causare disguidi.
Un MUA (Mail User Agent) è uno dei molti programmi che gli utenti possono utilizzare per leggere, rispondere o comporre una mail e metterla a disposizione. Tipici esempi sono pine, elm, mail. Solitamente su di una macchina sono disponibili diversi MUA ed ogni utente può usare quello che preferisce, senza compromettere la composizione e/o lettura della posta.
Un MTA è un programma specializzato per il trasposto della posta da una macchina all'altra, proprio come un ufficio postale. Di solito esiste unicamente un MTA installato sulla macchina. Sendmail è un MTA cosi' come lo sono qmail e Smail.
Sendmail (giunto alla release 8.9.3 e disponibile in sorgente all'URL www.sendmail.org) è un MTA forse non di immediata configurazione, ma di sicuro uno dei più usati MTA esistenti. Fondamentalmente oltre al binario /usr/sbin/sendmail, il programma consta di altre parti che costituiscono il cuore del sistema: il sendmail.cf che contiene tutta la configurazione, il path delle code (il famoso spool) che trattiene la posta in uscita sino a quando non è stata inviata ed il file aliases che gestisce il reindirizzamento agli utenti.
La configurazione: sendmail.cf
Il file /etc/sendmail.cf costituisce la vera configurazione del sendmail. Oltre a definire alcune cose quali i permessi ed i percorsi, sendmail.cf contiene tutte le regole per trasformare i vari indirizzi di posta in un nuovo formato tale per cui possano essere spediti ad altre macchine e qui ricevuti. I rulesets sono uno degli aspetti più ostici di sendmail, aspetto che analizzeremo solo marginalmente giusto per capire in che modo sendmail gestisca la posta in entrata ed in uscita. Se voi analizzate una mail arrivata con un editor, vi accorgerete che consta principalmente di due parti:
From marco@tecnogi Wed, 27
Jan 1999 02:15:23 +0200
From: XCmail development
Reply-To: xcmail-dev@fsai.fh-trier.de
Subject: Welcome to XCmail
0.99.6
To: XCmail user Date: Wed,
27 Jan 1999 02:15:23
X-Mailer: XCmail 0.99.6
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding:
8bit
Welcome to XCmail 0.99.6!
Oltre all?header e body si deve considerare anche
l?envelope,
ovvero la busta. Torniamo all?analogia con la posta cartacea. Supponete
di dover mandare una lettera ad un amico che vive in fianco a voi ed anche
una copia ad un altra persona che vive molto piu? lontana. Supponiamo che
i destinatari siano user e user1@dominio.it,
ove il primo, vista la vicinanza, e? uno user locale mentre l?altro e?
quello remoto. Probabilmente voi scriverete la vostra lettera, ne farete
una copia e poi mentre quella per user la metterete in una busta indirizzandola
ma consegnandola manualmente, la copia per user1@dominio.it
sara? messa in un altra busta e portata all?ufficio postale. Mentre nell?intestazione
comparira? che entrambi user e user1 erano i destinatari della lettera,
sulla busta compare solo un destinatario. Nel momento in cui 2 hosts si
parlano per scambiarsi la posta (spedizione e ricezione) si comunicano
vicendevolmente chi sono, a chi va inviata la posta e da parte di chi dopodiché
inviano i dati e chiudono la connessione. Ad ogni passaggio il ricevente
deve convalidare l'informazione replicando con un OK. Questo tipo si sintassi
potete provarla direttamente telnettando la porta 25 ed impartendo i giusti
comandi.
[marco ~]# telnet localhost
25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 tecnogi.com ESMTP Sendmail
8.9.3/8.9.3; Fri, 19 Feb 1999 15:00:07 +0100 (CET)
helo tecnogi.com 250 tecnogi.com
Hello marco@localhost [127.0.0.1],
pleased to meet you
mail from:marco@localhost
250 marco@localhost... Sender
ok
rcpt to: marco@localhost
250 marco@localhost... Recipient
ok
data 354 Enter mail, end with
"." on a line by itself
ciao da oesse
.
250 PAA00523 Message accepted
for delivery
QUIT
221 mail.tecnogi.com closing
connection
Connection closed by foreign
host.
Questa sequenza di passaggi è esattamente quello che succede nel momento in cui voi inviate una mail ad un vostro amico. La riga rcpt to: marco@localhost identifica l?envelope di sendmail. I rulesets sono , come già detto, le regole per trasformare l'indirizzo da noi digitato in qualcosa di comprensibile per la sua spedizione. Sendmail infatti deve modificargli indirizzi per poter individuare eventuali errori o per selezionare gli MDA. I rulesets sono raggruppati in blocchi ed ognuno inizia con la lettera seguita dal numero del ruleset.
S0 è il blocco che definisce l'inizio del ruleset 0, mentre S98 il ruleset 98 e la loro sintassi è sempre del tipo:
Rlhs rhs commento
ove lhs ed rhs sono separati da tab.
Ovvero R (che sta per riscrive) lsh (left hand side) rhs (right hand side).
Se scorrete il sendmail.cf installato di default sulla vostra macchina noterete qualcosa del genere:
R$- $@ $1 @ $R user --> user @ remote
Questa strana sintassi sta ad indicare che l'indirizzo è comparato alla regola sulla sinistra ($-) e se soddisfa questa regola è riscritto in base alla regola sulla parte di destra ($@ $1 $@ $R). In poche parole sendmail verifica la sintassi dell'indirizzo e la manipola per convertirla in un formato che lui meglio gestisce. Alcuni rulesets (dallo 0 al 5) sono definiti internamente da sendmail per avere dei compito molto specifici:
0 risolve l' MDA
1 processa l'indirizzo del
mittente
2 processa l'indirizzo del
destinatario
3 preprocessa tutti gli indirizzi
4 postprocessa tutti gli indirizzi
5 riscrive gli utenti locali
non in /etc/aliases (vedere più avanti).
La gestione e riscrittura del rulesets è sicuramente una delle cose più complicate non solo nella gestione di sendmail, ma in generale nel mondo unix. Chiunque volesse approfondire la personalizzazione di sendmail e la eventuale scrittura di rulesets, dovrebbe armarsi di pazienza e manuale (Sendmail byr Bryan Costales with Eric Allman - Edizione O?Reilly & Associates) in quanto sarà qui impossibile definire la complessità dei rulesets.
Creazione del file mc per la generazione di sendmail.cf
Ma vediamo innanzitutto come si compila, installa e personalizza sendmail per le proprie esigenze. Per poter compilare sendmail bisogna prelevare i sorgenti dal sito ufficiale www.sendmail.org. Questi vanno copiati per esempio in /usr/local e decompressi per esempio con il comando : tar xvzf ./sendmail-8.9.3.tar.gz -C /usr/local e compilati lanciando /usr/local/sendmail-8.9.3/src/Build
Prima di lanciare la compilazione di sendmail, conviene dare una occhiata al file conf.h che contiene parte delle configurazione; normalmente il contenuto del file non va modificato, ma dare una occhiata non fa poi male. Verificato il contenuto di conf.h, procedete con la compilazione di sendmail tramite il comando Build. La fase di compilazione non dovrebbe essere molto lunga, un paio di minuti circa su di un pentium 233MMX (quale il mio) e fatto ciò troverete una nuova dir in src che prende il nome del vostro sistema. Nel mio caso si chiama /usr/local/sendmail-8.9.3/src/obj.Linux.2.2.1.i586.
Qui troverete l'eseguibile di sendmail. Prima di copiarlo in /usr/sbin, vi consiglio di fare un backup del vecchio sendmail e del suo file di configurazione /etc/sendmail.cf (ricordatevi anche di killare l'eventuale sendmail attivo sulla vostra macchina altrimenti non riuscirete a copiare il nuovo binario!)
Ora per poter far funzionare correttamente sendmail si dovrà creare il file di configurazione tramite la macro m4. Il file sendmail.cf sarà il risultato della macro, che prende il file che creerete ora (linux.mc) per generare il file di configurazione voluto.
Posizionatevi in /usr/local/sendmail-8.9.3/cf/cf ed attivate il vostro editor preferito per creare il vostro linux.mc. Come potete vedere, in questa dir ci sono molti file di configurazione per diversi sistemi, potrebbe anche esistere quello per il vostro linux, ma crearlo ex novo non fa male, e ci permette di capire come funziona la configurazione di sendmail.
Il file mc permette di definire tramite delle opzioni standard la configurazione finale di sendmail, costruendo mattone su mattone tutto quello che il vostro sendmail dovrà gestire.
Il file.mc minimale richiesto per far girare sendmail deve contenere almeno le seguenti informazioni:
OSTYPE() --> Il supporto per
il vostro sistema operativo
MAILER() --> definisce l'MDA
da utilizzare
DOMAIN() --> informazioni
sul dominio (non obbligatorio ma consigliato)
FEATURE() --> personalizzazioni
per esigenze multiple (consigliato)
Vediamo insieme le singole voci necessarie per la realizzazione del vostro sendmail.cf
OSTYPE. Gli ostype definiti risiedono in /usr/local/sendmail-8.9.3/cf/ostype ma bisogna fare attenzione: controllate che il vostro sistema abbia i percorsi definiti dall'ostype da voi prescelto (chiaramente linux!). L'ostype di default distributio con sendmail per linux contiene:
divert(0) VERSIONID(`@(#)linux.m4 8.7 (Berkeley) 5/19/1998') define(`LOCAL_MAILER_PATH', /bin/mail.local)dnl
Verificate che il vostro mail.local risieda proprio in /bin o modificate il file linux.m4 variando il path di mail.local
MAILER: I vari MDA non sono automaticamente definiti, ma devono essere specificati attraverso l'uso della macro mailer.m4. La configurazione più comune prevede l'utilizzo della macro local.m4, che viene gestita nel file.mc inserendo MAILER(local). Local supporta l'utilizzo sia di prog che local come MDA.
Ulteriori mailer gestiti da sendmail sono:
cyrus
fax
local
mail
phquery
pop
procmail
smtp
usenet
uucp
Verificate sempre il path del file macro sorgente di riferimento. Per esempio, qualora vogliate utilizzare procmail, procmail.m4 definisce come path di procamail /usr/local/bin/ e potrebbe darsi che il vostro procmail non si trovi li. Avete diversi modi per definre il path corretto: modificare procmail.m4, definire il nuoco path con una azione di define oppure specificare il path nella definizione della macro
(define(`LOCAL_MAILER_PATH', `/usr/bin/procmail')dnl
oppure
MAILER(`procmail', `/usr/bin/procmail')dnl.
DOMAIN: In questo caso l'utilizzo di DOMAIN(generic) è sicuramente quello che serve nella maggior parte dei domini. Questo statement può essere utilizzato per definire più cose al suo interno che raggrupppino configurazioni particoalri del dominio da gestire. Date un occhiata agli esempi presenti per capirne il funzionamento.
FEATURE: Le feature servono ad inserire combinazioni di personalizzazioni per la corretta gestione della posta. Una feature spesso utilizzata è quella del mascheramento del dominio. Cerchiamo di capire di cosa si tratta esattamente. Come avete visto nei numeri scorsi, la vostra macchina ha un nome ed un dominio di appartenenza definiti in /etc/hostname ed in /etc/hosts. Supponiamo per un attimo che la macchina si chiami pippo.pluto.com ove il nome della macchina è pippo ed il dominio di appartenenza sia pluto.com.
Tutte le mail mandate da questa macchina risulteranno mandate da utente@pippo.pluto.com e tale sarà anche il reply address dell'utente.
Il reply address può, per qualche MDA, essere definito tramite l'esportazione di una variabile di ambiente che si chiama REPLYTO. Ma supponiamo che il vostro dominio appartenga ad un altro dominio, che potrebbe essere per esempio quello del provider che vi da la connettività. Allora se voi volete che la posta uscente sia mascherata come se provenisse dal dominio del vostro provider, dovrete operare tramite il feature un operazione di mascheramento del dominio. Questa opzione risulta molto utile a chi ha una connessione dial-up ed ha dato un nome (ed un dominio) fittizio alla propria macchina. Essendo nome e dominio fittizi, nessuno potrebbe raggiungervi (in quanto il DNS non risolve nomi non registrati) rispondendo alla vostra mail, mentre voi vorreste che le mail di riposta arrivassero presso la macchina del vostro ISP dalle quali le scaricherete con fetchmail o popclient.
Se usate come login la stessa login definita dall'ISP sul vostro account di posta e mascherate il dominio con il dominio del vostro ISP, allora le mail inviate da voi risulteranno provenire dalla macchina del ISP.
Ci sono diversi tipi di mascheramento che hanno impatto principalmente sul mascheramento del solo dominio o dell'hostname e del dominio.
FEATURE(allmasquerade)
FEATURE(masquerade_entire_domain)
FEATURE(masquerade_envelope)
FEATURE(limited_masquerade)
MASQUERADE_AS
MASQUERADE_DOMAIN
MASQUERADE_DOMAIN_FILE
Vediamo insieme come funzionano:
Se masquerade_as è definito, allmasquerade modifica l'header utilizzando il dominio mascherato.
Esempio
Supponiamo che il vero nome della vostra macchina sia pippo.pluto.com e voi lo mascheriate come tin.it utilizzando l'opzione allmasquerade e masquerade_as
FEATURE(allmasquerade)dnl
MASQUERADE_AS(tin.it)dnl
MASQUERADE_DOMAIN(tin.it)dnl
Allora, le mail inviate dall'utente paolo@pippo.pluto.com sembreranno provenire dall'utente pippo@tin.it. Fate attenzione in quanto se l'utente pippo@tin.it non esiste o non siete voi (non avete la password per prelevare con pop3 dal server tin.it), non avrete possibilità di leggere la posta!
Limited_masquerade deve essere usato insieme a masquerade_as e masquerade_domain e serve per mascherare solo parte delle macchine che compongono la rete.
Come esempio analizziamo l'eventualità in cui esitano 3 domini: mio.dominio, tuo.dominio e suo.dominio. Se volessimo che tutti i domini siano mascherati tranne suo.dominio dovremo definire qualcosa tipo:
MASQUERADE_AS(tuo.dominio)
FEATURE(`limited_masqueradè)
Cw mio.dominio tuo.dominio
suo.dominio
MASQUERADE_DOMAIN(mio.dominio
tuo.dominio)
Masquerade_entire_domain permette di mascherare completamente il dominio di provenienza compreso l'host e non solo il dominio. Vedete l'esempio di qui sopra per un corretto utilizzo. L'ultimo tipo di mascheramento esistente è il mascheramento dell'envelope, che permette di mascherare oltre all'header anche l'envelope.
L'envelope, come già detto, è quella parte della mail che non è ne l'header nel il corpo della mail stessa. Ovvero è la busta che contiene i destinatari a cui inviare la posta. MASQUERADE_DOMAIN_FILE permette di definire un file in cui memorizzare i domini da mascherare (nel caso siano molti).
Introducendo MASQUERADE_DOMAIN_FILE(/etc/mail/domains) nel file.mc, i domini saranno letti direttamente dal file, che potra? essere semplicemente aggiornato.
Un altra feature interessante è VIRTUSERTABLE che permette di gestire domini virtuali.
Ammettiamo che sulla vostra macchina ci siano più domini: per esempio dom1.com e dom2.com. Se, come spesso avviene, dovessero essere create 2 e.mail con lo stesso nome ma riferire a domini diversi, sendmail non saprebbe come interpretare il risultato e segnalerebbe un errore. Nell'ipotesi che si debbano definire sia info@dom1.com che info@dom2.com sarà utile definire in fase di generazione del sendmail.cf anche il feature VIRTUSERTABLE, che si appoggia ad un file che definisce come ridirigere la mail per info@dom1.come per info@dom2.com.
Si dovrà in questo caso creare un file (/etc/virtusertable) che reindirizzi la posta per i 2 utenti.
Una ipotetica soluzione potrebbe essere:
info@doc1.com pippo@dom1.com
info@dom2.com pluto@dom2.com
Si dovrà quindi creare il database del virtusertable (operazione che dovrà essere fatta ogni qualvolta si aggiorni il file) con il comando:
makemap hash /etc/virtusertable < /etc/virtusertable
Se aggiornate il database , dovete rilanciare sendmail.
Leggo spesso sui newsgroup di persone che hanno un indirizzo di posta presso il loro provider del tipo marbor@domain.it che e? stato scelto usando parte del nome e del cognome. Il problema, pur usando il mascheramento del dominio nasce nel momento in cui lo user attivato sulla macchina locale (normalmente quella a casa) risulta diverso (solo mario per esempio).
Allora, una feature che ci puo? venire utile e? GENERICSTABLE che permette appunto di ridefinire l?header della mail in base ad una tabella creata appositamente dall?amministratore di sistema (root).
Come sempre questa feature si appoggia ad un file in cui sono definiti gli user ed gli indirizzi di e.mail che devono essere modificate. Un esempio, sul caso ipotetico visto prima, potrebbe essere:
mario marbor@domain.it
ove la parte sinistra definisce lo user locale e la parte destra lo user in cui l?header deve essere modificato. Come vedete, questo permette di non fare il mascheramento del dominio. La creazione del database deve essere fatta ogniqualvolta si modifica il file di appoggio ed il file di appoggio deve essere definito nella feature in fase di creazione del file.mc.
Il comando per la sua generazione e?:
makemap hash /etc/genericstable < /etc/genericstable
e la feature deve essere definita (in questo caso) come:
Feature(genericstable, hash -o /etc/genericstable)
Altra features interessante è l'access_db, che permette di creare un database dei domini / utenti per cui non ricevere posta.
Supponiamo infatti che i domini @spam.com e @money.com cosi' come l'utente pippo@dominio.com siano soliti mandare spam (ovvero posta indesiderata).
Un semplice modo per bloccare lo spamming da questi domini e da questo utente sarà quello di creare un file /etc/mail/access in cui inserire i domini e gli utenti da bloccare, eventualmente aggiungendo un codice di errore con cui rispondere.
Per esempio
spam.com
550 Spamming domain
money.com
550 No mail, thanks
pippo@dominio.com
550 no mail from you!
@altro_dominio.com
550 No spam
*.dominio3.it
550 no grazie
pippo@dominio3.it
OK
In questo caso, nonostante dominio3.it sia bloccato, sarà possibile ricevere posta da pippo@dominio3.it, ma solo da lui!
In questo file si possono usare anche le wildcards ma solo per la parte mancante del dominio (il nome dell'host). Si potrà dunque usare *.dom2.com ma non *dom2.com. La feature da inserire nel nostro linux.mc sarà la seguente:
FEATURE(access_db, hash -o /etc/mail/access)
alla quale seguirà il comando
makemap hash /etc/mail/access < /etc/mail/access
per la creazione del database.
Supponiamo che abbiate scritto il vostro linux.mc e che contenga:
divert(0)dnl
VERSIONID(`@(#)linux.mc 8.9.3')
OSTYPE(linux)dnl
DOMAIN(generic)dnl
define(`LOCAL_MAILER_PATH',
`/usr/bin/procmail')dnl
MAILER(local)dnl
MAILER(`procmail', `/usr/bin/procmail')dnl
MAILER(smtp)dnl
MASQUERADE_AS(provider.com)dnl
FEATURE(`masquerade_envelopè)dnl
FEATURE(allmasquerade)dnl
FEATURE(`masquerade_entire_domain')dnl
dnl sta per delete new line in quanto m4 sostituisce, nella generazione del file sendmail.cf, ad ogni comando con righe vuote.
Per ovviare a questo l?utilizzo di ndl per rimuovere le righe bianche.
La creazione del sendmail.cf a questo punto è facilissima: digitate dalla directory in cui avete creato il vostro linux.mc (dovreste essere in /usr/local/sendmail-8.9.3/cf/cf )
m4 ../m4/cf.m4 linux.mc > sendmail.cf
ed in pochi secondi il file di configurazione del vostro sendmail sarà creato e pronto per essere copiato in /etc:
[marco ~]# cp /usr/local/sendmail-8.9.3/cf/cf/sendmail.cf /etc
Ricordate ora di rilanciare sendmail (sendmail -bd -15m) e provate a mandare mail agli amici per verificare che la configurazione sia corretta.
Come forse già sapete, sendmail gestisce un file che si chiama /etc/aliases ove vengono definiti gli alias di posta. Il file ha un formato del tipo:
user1: user2
per fare in modo che la posta per user1 sia mandata a user2.
Lo user1 potrebbe addirittura non essere definito nel vostro /etc/passwd e /etc/shadow, mentre lo user2 lo deve essere. La sintassi completa del file /etc/aliases è la seguente:
user: user
user: /file
user: |programma
user: :include: list
Questa sintassi permette di ridirigere una mail ad un altro utente, ad un programma, ad un file ed ad una mailing list.
Ne primo caso, si potrebbe avere anche una sintassi del tipo:
user: \user, user2, user3, user4@altro_domain.com
che sta a significare che il primo user (preceduto da \) è un utente locale e che quindi sendmail non dovrà verificarne l'esistenza in righe successive di /etc/aliases, mentre user2 e user3 potrebbero essere alias di altri utenti e user4 è addirittura su di un altra macchina.
Nel caso invece si voglia indirizzare la mail ad un file, basterà specificarlo come /file (nome del file con il suo percorso) per trovarsi la mail salvata in quel file. Se si vuole gestire la mail entrante tramite un programma, si dovrà specificare il nome del programma (con percorso) usando la sintassi della pipe, ovvero |programma.
Il programma potrebbe essere scritto in perl che e? un ottimo linguaggio per la gestione di testi.
L'ultimo caso, molto interessante, permette di gestire le mailing list .
Se la parte destra del vostro aliases è del tipo :include: list, la lista dovrà essere un file (con percorso) che presenti gli indirizzi a cui la mail dovrà essere mandata se indirizzata all'utente sulla sinistra.
Vediamo un esempio semplice:
Supponiamo che in aliases sia presente una direttiva del tipo:
ml_list: :include: /home/pippo/lista
e che /home/pippo/lista sia cosi' definito:
pluto
mimmo@dom2.com
andrea@dom3.com
buzzz@dom4.com
mario
#commento
veronica
Una mail indirizzata a ml_list verra? mandata a tutti gli utenti presenti in /home/pippo/lista. Una particolare riguardo deve essere dedicato alla gestione del proprietario della mailing list, in modo che gli eventuali errori siano mandati ad uno user locale, indipendentemente da chi ha mandato il messaggio che ha generato l'errore. Il proprietario della mailing list si definisce attraverso l?inserimento di owner-nome_alias nel file aliases.
Per esempio, rifacendoci all'esempio di cui sopra:
ml_list: :include: /home/pippo/lista
owner-ml_list: veronica
Per essere sicuri che tutti gli errori generatisi nella mailing list possano essere verificati da qualcuno, si può definire anche un proprietario dei proprietari delle mailing list. Usando la sintassi
owner-owner: pippo
qualora veronica non fosse raggiungibile, la segnalazione dell'errore sarà mandata a pippo, in quanto proprietario dei proprietari delle mailing list. Gli indirizzi in aliases in cui non viene specificato il dominio sono indirizzi locali, mentre gli altri sono indirizzi esterni al dominio di appartenenza. Sebbene il file /etc/aliases sia scrivibile solo da root, il file lista potendo risiedere nella home di un qualsiasi utente, ha la possibilità di essere editato e menutenuto da un utente che non deve necessariamente essere root. Inoltre le modifiche agli eventuali file " lista" non necessitano un riavvio di sendmail, svincolando root da una qualsiasi gestione delle mailing list definite. Al contrario, gli aggiornamenti di /etc/aliases prevedono l'esecuzione del comando newaliases per il riaggiornamento del database. Gli user che per un breve periodo di tempo siano raggiungibili presso un altro indirizzo di posta, possono ridirigere le proprie mail senza intervenire su /etc/aliases creando nella propria home il file .forward che ha la sintassi simile ad aliases: /user, user@diminio ove user e? il loro user su quella macchina e user@dominio il nuovo user su cui sono raggiungibili temporaneamente.
L'esistenza di ~/.forward impone al sendmail di forwardare le mail per user ad user@dominio, ed è comodo in quanto non prevede l'intervento dell'amministratore di sistema.
Un altro file fondamentale per sendmail è il file /etc/sendmail.cw, che riassume i domini per cui accettare la posta. Se infatti sulla vostra macchina sono presenti più domini o ancora se la macchina è un hub che raccoglie la posta di diverse altre macchine (campo MX del DNS), il file sendmail.cw dovrà esprimere tutti i domini di ricezione. La sintassi del file risulta essere la semplice lista dei domini come per esempio:
dom1.com
dom2.com
pippo.pluto.com
Sicurezza
Essendo sendmail l?MDA sicuramente piu? usato nel
mondo unix, ed essendo un programma in ascolto su di una porta aperta (la
25), si presta molto ad essere attaccato per sfruttare eventuali bugs per
entrare nel sistema remoto. Fortunatamente, sendmail e? costantemente migliorato
al fine di garantire doti si sicurezza tali da lasciare dormire (spesso)
tranquilli gli amministratori di sistema. Con la crescita di internet ed
il moltiplicarsi degli host ad essa collegati, e? nata una tattica nuova
di "volantinaggio" , che permette di mandare veri e propri volantini a
migliaia di utenti senza che questi ne abbiano richiesti. Questo fenomeno
denominato spamming sfruttava la possibilita? di sendmail, se non perfettamente
configurato, di fare in modo che altri host mandassero le loro mail di
spam attraverso una macchina non appartenente alla loro rete. Un po? come
utilizzare un ufficio postale non del vostro quartiere per spedire migliaia
di mail. Questo provocava un enorme spreco di banda (e di cpu) e cautelva
dietro un certo anonimato i veri mandatari dello spam. Le ultime release
di sendmail hanno una perfetta gestione dello spamming , evitando che altri
server possano utilizzare la vostra macchina come relay per mandare posta.
Infatti, anche sendmail può essere configurato per usare come relay
una macchina diversa dalla vostra.
Verificate il sendmail.cf creato e ricercate introno alla riga 70 l'esistenza di:
# "Smart" relay host (may be
null)
DS
In questo caso è nullo, ma se lo modifichiamo in
DSpippo.pluto.com
(mi raccomando senza spazi) la mail uscente sarà indirizzata al MDA esistente su pippo.pluto.com e da li inviata ai destinatari finali. Questo però solo se pippo.pluto.com ha lasciato aperto al nostro IP la possibilità di fare relay.
La configurazione del relay è definita da un file /etc/mail/relay-domains che definisce gli IP (o le classi di IP) a cui lasciare fare relay dalla nostra macchina. All'interno si dovranno specificare semplicemente gli IP come nell'esempio seguente:
123.34.56.*
244.193.212.18
In questo esempio, relay-domains permette alle macchine con IP da 123.34.56.0 a 123.34.56.255 ed anche 244.193.212.18 di usare la nostra macchina come relay. Visto il proliferare di spam mail, il consiglio è quello di chiudere perfettamente il relay ed abilitarlo solo ed unicamente agli IP fidati della vostra rete. Se lasciato bianco, dovrebbe funzionare unicamente per il localhost, ovvero la vostra macchina (quindi chiuso a tutti tranne al server su cui sendmail sta girando). Per controllare che il vostro sendmail stia lavorando in maniera corretta, verificate da root lanciando il comando
tail -f /var/log/maillog
(o il nome del file su cui loggate la mail entrante
ed uscente, verificandolo dal vostro /etc/syslog.conf) e chiedete ad un
amico di mandarvi una mail.
Otterrete un qualcosa del genere:
Feb 7 09:41:51 tecnogi sendmail[32250]: JAA32249: to=<oesse@tecnogi.com>, delay=00:00:04, xdelay=00:00:00, mailer=local, stat=Sent Feb 7 10:16:13 tecnogi sendmail[32266]: KAA32266: from=<kc@versiontracker.com>, size=23509, class=0, pri=53509, nrcpts=1, msgid=<199902070915.EAA06070@versiontracker.com>, proto=ESMTP, relay=versiontracker.com [209.68.63.234] Feb 7 10:16:13 tecnogi sendmail[32267]: KAA32266: to=oesse@tecnogi.com, delay=00:00:18, xdelay=00:00:00, mailer=local, stat=Sent
Il log di sendmail tiene traccia di tutte le mail entranti ed uscenti, lasciando la possibilità di verificare eventuali inconsistenze ed errori di configurazione. Un buon amministratore di sistema deve sempre scorrere i log del suo sistema per verificarne il funzionamento. Se poi volete loggare tutta la posta entrante ed uscente in un file dovrete lanciare sendmail con l?opzione -X /path/file (X maiscola). Cosi? facendo tutto quello che passa da sendmail verra? loggato nel file specificato. Visto che in questo modo sendmail logga tutto (e proprio tutto) questa opzione e? consigliata solo verificarne il funzionamento. Inoltre non conosco gli aspetti sulla tutela della privacy e quindi non so indirizzarvi se non ad un ufficio legale per chiarimenti in questione. Certo e? che su di un server che un traffico discreto di posta questa opzione rallenta il sistema e da origine ad un file enorme che dovra? essere manutenuto costantemente. Vi suggerisco al limite di lanciare il vostro nuovo sendmail solo per prove con questa opzione, sia per non inpegolarvi con problemi di carattere legale ne per dare origine a file mastodontici che sicuramente non avrete occasione di leggere.