Allora.. vediamo un po' cosa sono riuscito a tirare fuori dalla
documentazione di sendmail tenendo presende due cose fondamentali:
1) sendmail e' un pozzo senza fondo
2) le mie osservazioni sono inevitabilmente piene di lacune e vanno
considerate come semplici tracce da seguire.
Bene.
A partire dalle release 8.12.* sendmail usa una logica di
funzionamento abbastanza diversa dalla sua classica ma non impedisce
all'utente di adottare la _vecchia_ tecnica.
In base al nuovo funzionamento e' possibile agire da utente senza
modificare i permessi del binario (/usr/sbin/sendmail) riuscendo
quindi a raggiungere un importante obiettivo in termini di sicurezza.
L'utente ha la possibilita' di _preparare_ l'invio che poi viene
gestito a livello di demone da sendmail.
Ma andiamo per gradi.
Dopo l'installazione del programma la situazione e' questa
$> ls -l /usr/sbin/sendmail
-r-xr-sr-x 1 root smmsp 561676 giu 20 17:18 /usr/sbin/sendmail
$> ls /etc/mail | grep cf
sendmail.cf
submit.cf
In /etc/mail spicca subito la presenza di un file cf che nelle
vecchie versioni di sendmail non c'era e cioe' submit.cf. Di default
e' questo il file di configurazione che sendmail legge e che rispetto
a sendmail.cf (il vecchio-classico file cf) fondamentalmente contiene
l'indicazione di smistare la coda in /var/spool/clientmqueue (e non
in /var/spool/mqueue secondo sendamail.cf).
Quando a Giuseppe suggerivo di modifiacare il sendmail.cf per
eliminare la stringa di warning che compariva nei suoi headers,
semplicemente sbagliavo in quanto quel file veniva ignorato: le
modifiche andavano fatte in submit.cf.
Una volta che le mail si trovano in clientmqueue lo svuotamento della
coda avviene tramite l'attivazione di sendamil in modalita' _queue
runner_; il programma e' impostato in maniera che l'utente non debba
fare nulla per svuotare la coda, visto che queue runner viene gestito
a livello demone, ma nessuno ci impedisce di disattivare il demone
all'avvio e di lanciarlo nel momento in cui a noi serve.. dopo cioe'
aver lanciato la connessione.
Su slackware sendmail-demone e' gestito tramite lo script
$> cat /etc/rc.d/rc.sendmail
#!/bin/sh
# Start/stop/restart sendmail.
# Start sendmail:
sendmail_start() {
if [ -x /usr/sbin/sendmail ]; then
echo "Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta
-bd -q25m"
/usr/sbin/sendmail -L sm-mta -bd -q25m
echo "Starting sendmail MSP queue runner: /usr/sbin/sendmail -L
sm-msp-queue -Ac -q2
5m"
/usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
fi
}
....
...
...
che e' richimato dalla stringa contenuta in /etc/rc.d/rc.M
$> grep sendmail /etc/rc.d/rc.M
# Start the sendmail daemon:
if [ -x /etc/rc.d/rc.sendmail ]; then
. /etc/rc.d/rc.sendmail start
fi
Commentando queste ultime stringhe i _demoni_ di sendmail (sono due
infatti) non partono all'avvio del sistema.
Quindi:
1) scrivo le mie mail con mutt in off-line
2) le invio (finiscono in /var/spool/clientmqueue)
3) mi connetto
4) lancio lo script dei demoni con
#> /etc/rc.d/rc.sendmail start
5) le mail.. partono.
A questo punto sendmail in modalita' demone esiste in background e
trascorsi 25 minuti provvedera' a svuotare nuovamente l'eventuale
coda accumulatasi (dobbiamo essere connessi).
Per evitare questo dobbiamo-possiamo semplicemente fermare sendmail
con
#> /etc/rc.d/rc.sendamil stop
Se invece non vogliamo fermare la modalita' demone (magari abbiamo
appena scritto un'altra mail e vogliamo subito riconnetterci per
inviarla) allora possiamo lanciare
#> /etc/rc.d/rc.sendamil restart
con tale comando semplicemente killiamo i processi di sendmail
esistenti e li lanciamo _nuovi di zecca_ (il countdown dei 25 minuti
riparte quindi dal momento in cui lanciamo il restart)
Faccio notare:
1) gli ultimi tre comandi che ho indicato li puo' lanciare solo root
(apriamo un'altra console o un altro terminillo e' agiamo da root)
2) sendmail-demone funziona a due livelli. Il demone base e' attivato
tramite
/usr/sbin/sendmail -L sm-mta -bd -q25m
Senza questa prima modalita' del demone, la seconda del queue runner
non puo' essere attivata
/usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
Su queste stringhe si puo' intervenire agendo magari sui tempi. Di
default su slack sono impostati a 25 minuti. Considerate che non
avendo la necessita' del demone in background (smistate in locale con
procmail, inviate e vi disconnettete) in definitiva diventa
irrilevante il timing dei demoni.
Una volta lanciato lo start dei demoni per svuotare la coda vi
conviene poi lanciare lo stop.
3) credo sia conveniente impostare degli alias sui vari start, stop
ed eventualmente restart (alias che vanno infilati nei file bash di
root e non dell' utente)
Nella parte iniziale della mail ho rammentato di alcune modifiche che
suggerii a Giuseppe.
Il file su cui agire e' submit.cf e le modifiche da fare sono:
1) inserire l'utente nella lista degli utenti-fidati (trusted-users).
Quindi cercate in submit.cf la sezione apposita e aggiungete il nome
del vostro utente preceduto da una T.
Per syd
$> cat /etc/mail/submit.cf
.....
.....
#####################
# Trusted users #
#####################
# this is equivalent to setting class "t"
#Ft/etc/mail/trusted-users
Troot
Tdaemon
Tuucp
Tsyd
....
....
Questa modifica e' fondamentale per impedire che sendmail ci avverta,
tramite un messaggio di warning inserito nelle nostre intestazioni,
che la mail e' stata inviata da un utente non fidato.
2) Ed ora la modifica piu' _delicata_ (non tecnicamente ma
concettualmente):
sendmail lo possiamo usare in maniera tale che semplicemente incarichi
il server smtp del nostro provider di inviare le mail oppure in
maniera tale che la nostra macchina si trasformi nel nostro server
smtp.
Per raggiungere il secondo obiettivo _non_ dobbiamo fare nulla mentre
per il primo dobbiamo modificare la stringa (sempre in submit.cf)
# "Smart" relay host (may be null)
DS
in questo modo
# "Smart" relay host (may be null)
DSnomedelserversmtpdelnostroisp
syd avrebbe fatto
# "Smart" relay host (may be null)
DSout.virgilio.it
Notate che nel caso in cui decidessimo di usare come smtp la nostra
macchina (nessuna modifica) l'invio delle mail passerebbe
necessariamente da clientmqueue _anche_ se al momento dell'invio
fossimo connessi: dovremmo quindi lanciare il demone in ogni caso.
La cosa puo' sembrare strana ma non lo e': se siamo un server smtp, e'
sendmail che deve gestire il tutto ed e' naturale pensare che siamo
connessi 24 ore su 24 ed e' quindi normale che ci sia un demone in
background che smista a cadenze temporali predefinite.
Se incarichimo altri server di inviare la nostra posta allora il
demone serve a poco, lo usiamo ugualmente al momento della
connessione ma in maniera.. come dire.. riadattata. D'altra parte
solo la necessita' di una coda da gestire puo' spingerci a usare un
MTA completo al posto di uno ridotto (mi riferisco naturalmente a
connessioni dial-up).
Arwan.. quello che a te conviene fare e' rivolgerti al tuo isp;
quindi fai l'ultima modifica che ho indicato.
In futuro, quando avrai un po' di dimestichezza, deciderai eventuali
comportamenti diversi.
Come richiamiamo sendmail all'interno di mutt?
syd inserirebbe questo comando all'interno del suo .muttrc
set sendmail = "/usr/bin/sendmail -f [EMAIL PROTECTED]"
L'opzione -f garantisce che il Return-path risulti impostato sul
campo from che coincide con l'indirizzo indicato.
D'altra parte syd usa account diversi per liste diverse quindi
preferisce la tecnica degli hook
send-hook .* "set sendmail = '/usr/bin/sendmail -f [EMAIL PROTECTED]'"
send-hook majalinux "set sendmail = '/usr/bin/sendmail -f [EMAIL PROTECTED]'"
Notate che uso /usr/bin/sendmail che e' un symlink al rispettivo
binario posizionato in /usr/sbin
Il papiro che ho scritto sopra, vale nel caso in cui decidessimo di
sfruttare le caratteristiche di maggior sicurezza del nuovo sendmail.
Vogliamo usare sendmail come facevamo in passato chiudendo un occhio
sulla sicurezza ma guadagnado un pochino in termini di semplicita'
d'uso?
Allora.. da tutto quello che ho scritto sopra cancellate la sezione
dedicata alla gestione dei demoni (start-restart-stop), considerate
valide le informazioni sulle modifiche da fare al file di
configurazione che questa volta pero' non e' piu' submit.cf ma
sendmail.cf e modificate i permessi del binario in questo modo
#> chmod a+s /usr/sbin/sendmail
tenendo presente che potrete sempre ritornare alla situazione dei
permessi originaria (vi dico questo nel caso in cui voleste
sperimentare la vecchia e la nuova tecnica di sendmail per capire
quale vi aggrada meglio) con
#> chmod a-s /usr/sbin/sendmail
#> chmod g+s /usr/sbin/sendmail
Affinche' sendmail legga sendmail.cf e non submit.cf dovete
richiamarlo all'interno di .muttrc con l'opzione -Am
set sendmail = "/usr/bin/sendmail -Am -f [EMAIL PROTECTED]"
la stessa modifica sulle stringhe degli hook.. se li usate.
Ripeto: sendmail di default legge submit.cf, con l'opzione -Am legge
sendmail.cf.
In questo file c'e' scritto che la coda e' gestita in
/var/spool/mqueue.
Quindi
1) scriviamo la mail in off-line
2) la inviamo e finisce in /var/spool/mqueue
3) ci connettiamo
4) svuotiamo la coda con
$> sendmail -q -v
Ci disconnettiamo e il gioco e' fatto. Nessun demone lavora in
background (abbiamo naturalmente gia' disattivato sendmail tra gli script
d'avvio).
Faccio notare che lo svuotamento della coda lo puo' fare direttamente
l'utente.
Indubbiamente questa procedura e' piu' semplice ma ci impedisce di
sfruttare le doti di maggior sicurezza che il nuovo sendmail ci
offre.
A voi la scelta.
Alcune osservazioni per finire.
Non ho usato la tecnica della generazione dei file di configurazione
di sendmail. E' stata una scelta ponderata (sperismo bene!) in
seguito alla lettura della doc di sendmail (naturalmente di una parte
della doc). I file forniti di default sono davvero fatti bene a tal
punto che, rispetto alle precedenti release di sendmail che io gia'
conoscevo ( quelle della serie 8.11.*), il numero di modifiche da fare
si e' praticamente quasi annullato (prima di modifiche ne facevo
davvero tante).
La generazione tramite m4 e' consigliata solo nel caso di esigenze
davvero particolari, per la considerazione delle quali vi rimando alla
stessa documentazione.
Per essere piu' chiaro.. se avessi usato la tecnica della generazione
avrei ottenuto due file cf praticamente identici a quelli forniti di
default nelle parti corrispondenti alle mie esigenze.
Allora ragazzi.. spero di non aver dimenticato nulla ma sappiate che
e' molto probabile. D'altra parte non e' stato facile fare svariate
prove per cercare di capire il funzionamento dello zio send.
Io navigo con abbonamento flat e per entrare nella logica delle code
ho dovuto simulare una connessione dial-up ad ogni prova buttando
prima giu' e poi facendo resuscitare la mia schedina di rete.
Se qualcosa non vi e' chiara chiedete pure.. ma leggete attentamente
quello che ho gia' scritto, in quanto e' probabile che alcuni
adattamenti alla vostra configurazione vadano necessariamente fatti e
questo solo voi potete saperlo.
Vabbe'.. mi sto intortando.. chiedete e basta ;))
--
syd
-----
Slackware 9.0 * K 2.4.20
-----
