Lo strato applicativo di Internet
Ora ci accingiamo ad installare su ogni computer un server SMTP, in modo che si possano inviare e ricevere email da un computer all'altro, senza dover transitare dall'esterno, come codificato da header del tipo
| From: alice <labint@alice.labint> To: bruno <labint@bruno.labint> |
In questo esempio, alice è seduta davanti a alice.labint, e vi sta lavorando con login labint. Per inviare una email al suo collega bruno, loggato come labint su bruno.labint, lo User Agent di posta elettronica di alice utilizza
L'SMTP server di alice quindi, interrogando il DNS autorevole per bruno.labint, scopre che il MX è ancora bruno.labint , a cui in definitiva invia a sua volta l'email.
Se al contrario, alice vuole inviare una email ad un indirizzo email domiciliato presso un nome a dominio associato ad un IP pubblico, allora dovrà usare
Stabiliamo dunque di configurare l'SMTP Outbound presente su mail.labint in modo che questo, anzichè tentare di contattare direttamente il server di posta indicato dal RR MX del dominio di destinazione (che molto probabilmente rifiuterebbe di accettarla, come difesa dallo spam), invii tutta la posta in uscita ad un suo smarthost fisso, residente sulla Internet pubblica, in modo che sia questo a consegnare l'email a destinazione. Qualora il destinatario della email di alice (ad es bruno <bruno.delmont@hotmail.com>) scelga di rispondere ad alice.delmar, quest'ultima troverà la risposta presso il dominio gmail.com.
La distribuzione Ubuntu 9.10 installata al laboratorio, prevede l'utilizzo del server SMTP Postfix. Ci sono tre diversi modi di configurarlo:
Dato che la prima modalità parte da sola all'atto dello scaricamento, illustriamo cosa rispondere alle domande, tenendo però presente che se questa modalità non dovesse andare a buon fine, possiamo ricorrere ad una delle altre due. Usando Synaptic, dopo aver cercato, selezionato e scaricato Postfix, ci compare una finestra di configurazione, in cui per ogni domanda, possiamo chiedere l'aiuto, che ci chiarifica il senso delle scelte da effettuare. Vediamo ora le risposte da fornire nei due casi individuati, ossia l'installazione del proprio server, e del server di Outbound:
Il risultato della configurazione è visualizzabile nel file /etc/postfix/main.cf, la cui lista completa dei parametri di configurazione è ottenibile come man postconf. Nel nostro caso, avremo il risultato:
| myhostname = mionome.labint mydestination = mionome.labint, localhost.labint, localhost relayhost = mynetworks = 127.0.0.0/8 |
mentre per l'outbound SMTP, occorre aggiungere a mynetworks la rete locale 192.168.0.0/16, istruendolo così a permetterne l'uso come Relay da parte degli altri computer della LAN, come illustrato dalla documentazione. Inoltre, l'outbound SMTP deve inserire, alla riga relayhost, quello designato per inoltrare le email sulla Internet pubblica.
Notiamo infine che mentre mydestinations permette a Postfix di capire se comportarsi da MDA oppure ri-lanciare l'email verso la destinazione, myhostname viene usato come fqdn per le email spedite dagli utenti locali. Ecco dunque la sequenza di controllo che si sviluppa ad ogni email ricevuta:
Per sperimentare l'invio delle email utilizziamo un MUA (client di posta), ad esempio possiamo usare Evolution. Se è la prima volta che lo apriamo la configurazione di un nuovo profilo partirà da sola, altrimenti, ci possiamo arrivare dal menù modifica/preferenze. Chiamiamo l'account di questo nuovo profilo labint@mionome.labint, che corrisponderà anche al proprio indirizzo email, ed impostiamo per la posta in uscita il server SMTP appena installato, e residente sul nostro stesso computer, indicandolo quindi come 127.0.0.1; per ora, non richiediamo nessuna opzione di sicurezza. Quindi, usciamo da Evolution, e rientriamo. Monitorando il file di log di Postfix mediante il comando tail -f /var/log/mail.log, ed eventualmente tenendo aperto wireshark con filtro di cattura port 25, proviamo a spedire una email verso l'indirizzo di un nostro collega, come labint@collega.labint.
Che succede? Non parte? Che messaggio di errore osserviamo ? Proviamo a capire cosa è successo, dall'analisi del nostro file di log, ed eventualmente, anche di quello del nostro collega. Ad esempio:
Dopo aver eventualmente modificato il file di configurazione, dobbiamo fare in modo che Postfix (o Bind) lo rilegga: impartiamo allora il comando sudo service postfix restart (o equivalente). Controllando il file di log, verifichiamo che il processo si riavvii.
Qualora l'email spedita sia stata correttamente accettata dal proprio SMTP server, ma questo non riesca a contattare l'SMTP di destinazione, l'email rimane nel limbo della directory /var/mail/spool. Il nostro SMTP, di tanto in tanto, tenta di spedirla di nuovo, e dopo un pò a sua volta ci invia una email con la quale ci avvisa del ritardo. Da parte nostra, possiamo interrogare la coda di inoltro con il comando mailq, che se invocato con l'opzione -q, scatena un nuovo tentativo di invio.
Ora che siamo in grado di scrivere ai computer di labint, cerchiamo anche di leggere la posta ricevuta. Dato che siamo seduti davanti allo stesso computer su cui è in esecuzione l'SMTP ricevente, possiamo verificare che l'email che un nostro collega ci ha scritto, si è effettivamente parcheggiata in un file di sistema, immettendo il comando cat /var/mail/labint. In modo più comodo, potremmo accedervi mediante un client di posta testuale, come ad esempio mutt, oppure mail che è presente nel pacchetto mailutils (sito GNU).
Per potervi accedere dal client grafico di email Evolution dobbiamo ri-aprire Modifica/preferenze ed editare l'account, specificando sulla linguetta Ricezione email di usare un File spool mbox standard Unix, ed indicando il percorso /var/mail/labint. Più avanti, è mostrato come accedervi mediante protocollo imap.
Come già accennato, per inviare email verso dominii esterni al laboratorio, dobbiamo
Per questo, apriamo di nuovo la finestra Modifica/preferenze di Evolution, e aggiungiamo un nuovo account, per il quale utilizziamo il nostro indirizzo email ufficiale, ed indichiamo come server per la ricezione quello del nostro provider (ad es per libero, imapmail.libero.it), completo di nome utente e password, e come server SMTP per l'invio, quello presso mail.labint, che è configurato per usare come smarthost l'SMTP server dell'ateneo. Infine, per distinguere questo accont dall'altro, possiamo dargli un nome indicativo, come ad es. aalef@libero.it via mail.labint.
Ora, non resta che verificarne il funzionamento. A ben vedere, si poteva usare direttamente l'SMTP di uniroma1, senza passare dall'Outbound proxy!
Modifichiamo ora la configurazione dello User Agent in modo da comporre i messaggi in HTML. Per Evolution, si sceglie il nostro account in Modifica/preferenze, quindi preferenze di composizione dalla colonna di sinistra, e si spunta Formato messaggi in HTML come Comportamento predefinito. Quindi
Ora che nel capture il traffico è incrociato, con gli stessi due IP che si scambiano il ruolo di mittente e destinatario, come facciamo a separare il traffico delle due comunicazioni? Ovviamente, vale sempre il filtro creato con "follow TCP stream"... ma più in generale, i due Client useranno due diverse porte effimere, e dunque è questo il modo per distinguere i due tipi di traffico.
Se apriamo l'email ricevuta, e scegliamo di visualizzarne il sorgente, ad esempio digitando control-u, possiamo
Meglio ancora, salviamo il messaggio come un file, e poi apriamolo con il solito editor gedit, in modo da ritrovarci nella stessa situazione ottenibile osservando ad esempio per questo messaggio salvato. Osserviamo come
Notiamo ora come nella parte HTML l'immagine sia referenziata citando il Content-ID: <1197403030.18175.2.camel@alef-laptop> definito nella parte MIME che la rappresenta. Verifichiamo come l'immagine sia rappresentata con una codifica di trasferimento di tipo Base64.
Osserviamo come la parola Perù presente nel Subject sia stata trasformata nella stringa =?ISO-8859-1?Q?Per=F9?=, in accordo al metodo indicato come Encoded Word, utilizzando perdipiù un charset di riferimento (ISO-8859-1) diverso da quello usato nel body della email.
Facciamo ora caso alla modalità di rappresentazione delle lettere accentate. Nella parte HTML, benchè sia dichiarato l'uso del charset UTF-8, si adotta un Transfer-Encoding a 7bit, dato che non sono presenti caratteri diversi dall'insieme US-ASCII. Infatti, le lettere accentate (e non solo), sono rappresentate per mezzo di Numeric Character Reference, un metodo precedente alla definizione dell'Unicode, e che rappresenta un carattere mediante la sequenza &#nnn; in cui nnn sono due o più cifre decimali che individuano il codepoint del carattere rappresentato, nell'ambito del charset dichiarato per il documento.
Per quanto riguarda la parte in text/plain invece, l'effettiva codifica UTF-8 ad 8 bit usata per rappresentare i caratteri non-ASCII, può essere apprezzata utilizzando un editor binario: adoperiamoci quindi per scaricare GHex impartendo il comando sudo apt-get install ghex, ritrovandolo in Applicazioni/Programmazione. Quindi, possiamo aprire il file contenente il testo della email salvata, e verificare come per le lettere accentate vengano effettivamente usati due bytes. Con un pò di pazienza, potremmo anche verificare come risalire ai codepoints rappresentati.
Come illustrato nella guida di ubuntu, la distribuzione è armonizzata con il server Dovecot, che scarichiamo mediante Synaptic, selezionando dovecot-imapd, oppure mediante il comando sudo apt-get install dovecot-imapd.
Dovecot si compone di diversi processi, ed i principali sono
Scegliamo di accedere all'email mediante lo user agent Evolution, adottando il protocollo IMAP. Per questo:
ora, cliccando sulla cartella inbox (o in arrivo), sarà chiesta la password per l'utente indicato (ovvero quella usata in fase di login, ed il cui hash è tipicamente salvato in /etc/shadow), e sarà possibile leggere le email ricevute in locale.
Verificare quindi con Wireshark cosa è successo:
| * OK Dovecot ready. A00000 CAPABILITY * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN A00000 OK Capability completed. A00001 LOGIN labint password-in-chiaro A00001 OK Logged in. A00002 NAMESPACE * NAMESPACE (("" "/")) NIL NIL A00002 OK Namespace completed. A00003 LIST "" {1+} . .... etc etc etc |
In rosso, sono indicati i messaggi inviati dal client: come si vede, la password viene trasmessa in chiaro. Proviamo ora a configurare tutti quanti lo stesso server IMAP, corrispondente a mail.labint, e verifichiamo la possibilità per IMAP di avere più connessioni contemporanee alla stessa mailbox. Possiamo ora facilmente trasformare anche questo esperimento, in una nuova forma di chat. Ma... non ci permette di entrare? In tal caso, sniffando, si osserva
| * OK Dovecot ready. A00000 CAPABILITY * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED A00000 OK Capability completed. A00001 LOGIN labint password-in-chiaro * BAD [ALERT] Plaintext authentication is disabled, but your client sent password in plaintext anyway. If anyone was listening, the password was exposed. A00001 NO Plaintext authentication disallowed on non-secure connections. A00002 LOGOUT * BYE Logging out A00002 OK Logout completed. |
Questo comportamento è dettato dalla direttiva di configurazione disable_plaintext_auth = yes, presente nel file /etc/dovecot/dovecot.conf di mail.labint, e attiva di default. In questo caso il Dovecot in esecuzione su mail.labint, accorgendosi che l'IP di provenienza è differente dal proprio, ci mette in guardia dei rischi di sicurezza, a meno che questo non sia esplicitamente permesso, commentando la direttiva di configurazione disable_plaintext_auth = yes. Anziché seguire questa strada, valutiamo le possibilità di mettere in sicurezza la ricezione delle email.
L'abilitazione alla autenticazione del ricevente ci mette in grado di assolvere al punto 4) dei requisiti di sicurezza per la posta elettronica. Se chiediamo a Evolution il tipo di autenticazione supportato dal server IMAP (Modifica/Preferenze, e poi Modifica del profilo email creato, e quindi Ricezione email, e poi Controlla tipi supportati), il capture di Wireshark mostra lo scambio
| * OK Dovecot ready. A00000 CAPABILITY * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED A00000 OK Capability completed. |
in
cui osserviamo come il protocollo IMAP permetta al client di investigare
sulle Capability del server: quelle che ci
interessano, in questa fase, sono SASL e STARTTLS. Dato che per Evolution
la risposta ottenuta determina la cancellazione dei tipi di autenticazione
diversi dalla password, ed avendo capito che per password, si intende in
chiaro, ciò significa che per procedere, occorre abilitare le funzioni
crittografiche previste dal server Dovecot, ossia il Simple
Authentication and Security Layer (SASL)
oppure il TLS. Ma prima, conviene svolgere qualche
considerazione relativa al formato con cui sono memorizzate le password
presso il server.
Se le password memorizzate presso il server sono salvate in chiaro, queste possono essere utilizzate congiuntamente ad un qualunque meccanismo di autenticazione, perché una volta che il server riceve una password su cui è stata operata una trasformazione crittografica, fosse anche un semplice hash, non deve far altro che applicare la medesima trasformazione sulla propria copia della password, e verificare se i risultati corrispondono.
D'altra parte, nel caso in cui il server venga compromesso, e sia trafugato il file con le password in chiaro di tutti gli utenti, avremmo combinato un bel casino. Per questo motivo si preferisce memorizzare (almeno presso il server) le password in forma crittografata. In tal modo, se la password ci viene inviata in chiaro (esponendo però chi la invia al rischio di farsela rubare), non dobbiamo far altro che ripetere su questa la trasformazione crittografica utilizzata nella fase di salvataggio, e procedere al confronto. Se invece la password ci arriva già crittografata, allora... in generale, il meccanismo di crittografia usato per memorizzare le password sul server, deve essere legato a quello adottato dalla procedura di autenticazione. Come risultato, se si consente agli utenti di scegliere uno tra diversi meccanismi crittografici, si hanno due possibilità:
Notiamo per inciso che la semplice crittografia della password prima dell'invio non protegge da attacchi di replica, e quindi occorre adottare soluzioni basate su di una sfida come ad es. CRAM-MD5.
Infine, nel caso in cui la trasmissione si avvalga dei servizi crittografici offerti da uno strato inferiore, in grado di garantire la riservatezza della comunicazione, come nel caso di IPSec/ESP o di TLS, allora si può tornare ad effettuare l'invio della password in chiaro, e mantenere le password presso il server in un formato crittografico unico.
Come illustrato nella parte di teoria, (SASL) è una libreria che offre ai protocolli applicativi l'uso di diversi meccanimsi crittografici a scelta. Tra i vari possibili meccanismi di autenticazione utilizzabili da Dovecot, scegliamo di attivare CRAM-MD5.
Per questo, editiamo (come root) il file /etc/dovecot/dovecot.conf, localizzando la linea che elenca i meccanismi, e modificandola come
| mechanisms = plain cram-md5 |
Seguendo le indicazioni di un howto, scegliamo di generare una password criptata con uno schema compatibile con CRAM-MD5, da associare all'utente labint che effettivamente esiste sul computer, e di memorizzarla in un database di password corrispondente ad un semplice file in formato passwd, che salviamo in /etc/dovecot/cram-md5.pwd. Per fare questo,
| {HMAC-MD5}fc5a0359693c29d35d38945ba0f4baf46f4f4a5ed064d67c9cbd533944742ba8 |
| labint:{HMAC-MD5}fc5a0359693c29d35d38945ba0f4baf46f4f4a5ed064d67c9cbd533944742ba8 |
| passdb passwd-file { args = /etc/dovecot/cram-md5.pwd} |
Se ora eseguiamo di nuovo la richiesta del tipo di autenticazione supportata, osserviamo che adesso CRAM-MD5 non è cancellato, e lo possiamo selezionare. Quindi, sniffando con Wireshark il traffico corrispondente ad una richiesta di Send/Receive, otteniamo il capture
| * OK Dovecot ready. A00000 CAPABILITY * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=CRAM-MD5 A00000 OK Capability completed. A00001 AUTHENTICATE CRAM-MD5 + PDE4NDk0MzMxMjQzNjI0ODMuMTIwMTcwODQzMUBhbGVmPg== bGFic29mdGVsIDU1ZWIzNDYyMDdmMDE4NzEyODVkYjJmMTUxYWY4M2Zl A00001 OK Logged in. A00002 NAMESPACE * NAMESPACE (("" "/")) NIL NIL A00002 OK Namespace completed. . ... etc etc etc |
in cui appunto osserviamo l'offerta AUTH=CRAM-MD5, la sua scelta, l'invio della sfida, e la risposta, contenente la codifica base64 del nome dell'utente, e l'HMAC-MD5 calcolato a partire da challenge e password. Possiamo verificare che il contenuto di challenge e response corrisponde a quanto illustrato a lezione utilizzando un comando per la co-decodifica base64, ossia impartendo
| echo bGFic29mdGVsIDU1ZWIzNDYyMDdmMDE4NzEyODVkYjJmMTUxYWY4M2Zl | base64 -d - |
L'uso di un servizio di sicurezza a livello di trasporto svincola lo strato applicativo dal doversi preoccupare di possibili attacchi di sicurezza, e permette l'invio di password in chiaro. In questo caso, mentre l'utente si autentica presso il server inviando la propria password, anche il server si autentica presso l'utente, mediante l'invio di un proprio certificato. Perché ciò sia possibile, occorre editare di nuovo il file /etc/dovecot/dovecot.conf, e decommentare (a meno che non sia già operativo un default equivalente) le linee
| ssl_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem ssl_key_file = /etc/ssl/private/ssl-cert-snakeoil.key |
che contengono i riferimenti ad una chiave privata (.key), ed al certificato X.509 autofirmato (.pem), relativo alla rispettiva chiave pubblica, che sono preinstallati su linux. A questo punto ri-configuriamo Evolution, chiedendo di abilitare TLS, come previsto dalla RFC 2595, passando ancora da Modifica/Preferenze, scegliendo l'account/Modifica, Ricezione email/usa connessione sicura/TLS. Dopo aver richiuso e ri-lanciato Evolution, accedendo alla nostra mailbox ci viene mostrata una finestra chiedendo se accettare o meno il certificato autofirmato ricevuto, rilasciato dalla CA con Common Name Ubuntu, e con fingerprint bd:58:66:16:b1:a5:bf:fa:8e:14:3c:1f:23:39:41:bc.
Stavolta il capture di Wireshark appare come segue:
| * OK Dovecot ready. A00000 CAPABILITY * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=CRAM-MD5 A00000 OK Capability completed. A00001 STARTTLS A00001 OK Begin TLS negotiation now. .^....E......9..8..5..f..3..2......../........... . ... etc etc etc |
e dopo la richiesta (confermata) di utilizzare il TLS, il dissettore di IMAP non è più in grado di decodificare il traffico. Invece, qualora in Evolution si richieda l'SSL anzichè il TLS, si può ancora vedere qualcosa, come mostrato in questo capture.Nel caso dell'SSL, la connessione IMAP avviene sulla porta 993 anziché la 143, e l'handshake protocol inizia subito, senza passare dall'opzione STARTTLS. In effetti, è proprio l'uso della porta 993 a indurre wireshark alla decodifica corretta, dato che è la porta ben nota per IMAP over SSL. Ma anche nel caso del TLS con STARTTLS, si può comunque richiedere il decode as...
Nelle esercitazioni sugli aspetti di sicurezza, si illustra come generare ed utilizzare un certificato differente.
Torniamo ora al server SMTP di uscita. Anche per questo, possiamo abilitare le opzioni di sicurezza, agendo sul file di configurazione. Postfix non offre un supporto alla sicurezza in modo diretto, ma utilizza invece i servizi offerti da altri componenti software. In particolare, può utilizzare il componente di autenticazione SASL offerto da Dovecot, che abbiamo già configurato correttamente, e quindi sarà proprio quello che useremo. Seguendo le indicazioni fornite nella documentazione di Postfix e relativa a SASL e TLS, operiamo come segue:
| smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache |
| smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject smtpd_sasl_authenticated_header = yes |
| smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth |
Ora, apriamo il file di configurazione di Dovecot con sudo gedit /etc/dovecot/dovecot.conf e, come indicato nella documentazione di Postfix, aggiungiamo nella sezione auth default {} il nome ed i privilegi per il socket Unix di comunicazione tra Dovecot e Postfix:
| auth default { socket listen { client { path = /var/spool/postfix/private/auth mode = 0660 user = postfix group = postfix } } } |
A questo punto, possiamo far ripartire entrambi i server con i comandi
| sudo /etc/init.d/postfix restart sudo /etc/init.d/dovecot restart |
e provare a spedire email con Evolution. Innanzitutto, chiediamo (Edit/Preferences, selezioniamo il profilo, Edit, Sending Email) di usare una connessione TLS. Scriviamo un messaggio in uscita, e verifichiamo che il capture prodotto con Wireshark sia simile a questo
| 220 alef-laptop ESMTP Postfix (Ubuntu) EHLO [127.0.0.1] 250-alef-laptop 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN STARTTLS 220 2.0.0 Ready to start TLS ....]...Y...%U.o.`yy.........4.Z..r....q..# ...\W|(.x...D.>...M..j3. K...b......... |
dove appunto, notiamo la presenza della estensione AUTH PLAIN CRAM-MD5, identica a come l'avevamo configurata per Dovecot, mentre a seguito della negoziazione TLS, il contenuto diventa indecifrabile. Quindi, riconfiguriamo nuovamente Evolution, rimuovendo la richiesta del TLS, ed inserendo invece quella per l'autenticazione CRAM-MD5. Sniffando di nuovo, notiamo che il messaggio ora viaggia in chiaro, ma prima della sua accettazione, il client si è autenticato:
| ... 250 DSN AUTH CRAM-MD5 334 PDE3MjU2NDQxMDYyNDYyNjkuMTE3OTI2ODYyNEBhbGVmLWxhcHRvcD4= YWxlZiAyMmQzMjI0MmY4Mjg1MGViZTk5YWNmZDIxMDNlMjc1Nw== 235 2.0.0 Authentication successful MAIL FROM:<alef@infocom.uniroma1.it> 250 2.1.0 Ok ... |
| Received: from [127.0.0.1] (alef-laptop [127.0.0.1])
(Authenticated sender: alef) by alef-laptop (Postfix) with ESMTP id CC520186128 for <aalef@libero.it>; Wed, 16 May 2007 00:36:10 +0200 (CEST) |
Pertanto possiamo concludere che, abilitando l'autenticazione SMTP, siamo riusciti a conseguire i punti 1) e 3) dei requisiti di sicurezza per la posta elettronica, mentre per il 2), questo non può essere garantito, in quanto sarebbe necessaria l'esistenza di un rapporto di fiducia tra tutte possibili coppie di server SMTP di transito.
Infine, se riconfiguriamo ancora una volta Evolution per utilizzare sia l'autenticazione CRAM-MD5 che il TLS, in ricezione possiamo ancora osservare l'header che dichiara l'avvenuta autenticazione, mentre osservando il capture, verifichiamo che questa ha luogo dopo che si è attivato il TLS, e questo è il motivo per cui con il TLS, l'autenticazione può anche essere basata semplicemente su plaintext.
Nel corso della esercitazione, le cose possono non andare così lisce come previsto, ma spesso è sufficiente tenere d'occhio i file /var/log/messages e /var/log/mail.log (o .warn, o .err) per scoprire la natura del problema. Tenerli d'occhio vuol dire leggerli mediante il comando less (per andare ad inizio/fine file, si usino i simboli < e >), oppure (meglio ancora) in una altra finestra terminale, si inserisca il comando
| tail -f /var/log/mail.log |
che visualizzerà le righe del file, men mano che queste vengono aggiunte dal demone SMTP.
Dopo aver attivato sul nostro computer il server web Apache, potremo sperimentare l'accesso alla propria posta in forma webmail, mediante l'applicazione CGI Squirrelmail.
Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade
dietro le quinte di Internet, completo di cattura del traffico.
Scopri
come effettuare il download,
ricevere gli aggiornamenti,
e contribuire!
