Posta elettronica C Francesco Gennai Marina Buzzi iat Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche Francesco Gennai Marina Buzzi - IAT (Istituto per le Applicazioni Telematiche) http://www.iat.cnr.it - TERENA ( http://www.terena.org - ISOC (Internet SOCiety) http://www.isoc.org - Registration Authority Italiana www.nic.it Posta elettronica

Posta elettronica Alcuni cenni su “Multipurpose Internet Mail Extensions” (MIME) La posta certificata Un progetto basato sull’elaborazione di un messaggio MIME (Progetto: BIBLIO-MIME) La posta elettronica come veicolo di propagazione virus Centralized Management with Delegated Administration (CMDA) Il fenomeno “Unsolicited Bulk Email” (spamming).

MIME Multipurpose Internet Mail Extensions

RFC 822 (S) Standard for the format of ARPA Internet text messages Headers e indirizzi To: From : cc: Subject Data message Normale parte testo caratteri US-ASCII (7bit) lunghezza linea limitata a 80 caratteri

Multipurpose Internet Mail Extensions (MIME) Headers e indirizzi To: From : cc: Subject Uno o più “attachment” Messaggio rispedito (Forward) Multipart message (attachments) Normale parte testo Immagine GIF Documento MS Word Data message Normale parte testo caratteri US-ASCII (7bit) lunghezza linea limitata a 80 caratteri

Multipurpose Internet Mail Extensions rappresentazione e codifica di dati multimediali per trasmissione via e-mail. estende la RFC822 semplicità compatibilità flessibilità

Multipurpose Internet Mail Extensions Superare i limiti imposti da: RFC822 - formato del messaggio RFC821 - (SMTP) trasporto del messaggio senza perdita di compatibilità 7 bit US-ASCII Header seguito da un solo monolitico Body Lunghezza linee in Header e Body La limitazione dei 7 bit e’ veramente critica. Due sono gli approcci: uno e’ quello di MIME che ha stabilito una codifica dei dati affinche’ tutto sia rappresentabile con ascii 7 bit. L’altro e’ quello della estenzione dello standard affinche’ siano supportati caratteri a 8-bit. Questo ovviamente comporta l’aggiornamento di tutto il software preesistente. Body multipart server per il trasoprto di dati multimediali, Per esempio una visualizzaaione di immagine in parallelo all’esecuzione di un brano musicale in un Multipart/parallel.

Multipurpose Internet Mail Extensions Un messaggio MIME può contenere: più oggetti all’interno del messaggio stesso testo di lunghezza illimitata set di caratteri diversi da US-ASCII, consentendo così messaggi in lingue con set di caratteri esteso più fonti nello stesso messaggio file binari per applicazioni specifiche immagini, audio, video, messaggi multimediali rappresentazioni alternative dello stesso oggetto riferimenti esterni (esempio: accesso FTP)

Multipurpose Internet Mail Extensions MIME definisce 8 formati “Content-type” Nuove definizioni via documenti formali (RFC) Content-type: - text - message - image - multipart - audio - application - video - model

Multipurpose Internet Mail Extensions la sintassi del campo “Content-type” Content-type := type “/” subtype [“;” parameter] Esempi: a) Application/Octet-Stream; name=“pippo.bin” b) Image/gif c) Message/external-body; name=“rfc2045.txt”; site=“ftp.ripe.net”; access-type=“anon-ftp”; directory=“rfc” d) Multipart/mixed; boundary=h78kUoI5TX9x

Multipurpose Internet Mail Extensions Content Subtype sono obbligatori per ogni Content Type Registrati presso la IANA (Internet Assigned Numbers Authority). Tre strutture di registrazione: IETF, Vendor (VND.) e Personal (PRS.) Ogni Subtype può avere uno o più parametri Notare che i tipi MIME sono ora utilizzati anche in contesti diversi dalla posta elettronica: World Wide Web, NetNews

Multipurpose Internet Mail Extensions MIME definisce due possibili “algoritmi di trascodifica” per il body (o body part) di un messaggio RFC822: base64 e quoted-printable Content-transfer-encoding: - base64 - 7bit - quoted-printable - binary - 8bit - x-nomecodifica

Esempio messaggio MULTIPART From: ..... Subject: .... Content-type: multipart/mixed; boundary=AAAconfine --AAAconfine parte contenente testo in US-ASCII infatti non e’ marcata con Content-transfer-encoding Content-type: multipart/parallel; boundary=XXXsepara --XXXsepara Content-type: audio/basic Content-transfer-encoding: base64 ..... dati audio codificati in base64 Content-type: image/gif ... dati per immagine gif codificati in base64 --XXXsepara-- Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable testo scritto in ISO-8859-1, questo testo =E8 codificato con= =93quoted-printable=94 --AAAconfine--

Multipurpose Internet Mail Extensions Gli RFC di riferimento: RFC2045 Part I: Format of Internet Message Bodies RFC2046 Part II: Media Types RFC2047 Part III: Representation of Non-ASCII Text in Internet Message Headers RFC2048 Part IV: Mime Registration Procedures RFC2049 Part V: Conformance Criteria and Examples

Alcune note sull’organizzazione di un servizio di posta elettronica

Un servizio SMTP omogeneo MTA che non supportano le più importanti estensioni SMTP non dovrebbero trovarsi sui “percorsi principali” Per esempio ecco cosa accade se un MX non supporta DSN mail.qualcosa.edu mailsrv.cnuce.cnr.it DSN Richiesta/Risposta cnuce.cnr.it MX 10 mailsrv.cnuce.cnr.it MX 20 mail.xx.cnr.it Internet mail.xx.cnr.it fw.qualcosa.edu = NON supporta DSN = supporta DSN

Un servizio SMTP omogeneo Estensioni di cui è consigliabile prevedere il supporto: 8BITMIME, DSN, PIPELINE, ENANCHEDSTATUSCODE, AUTH Rendere omogeneo il livello delle estensioni presenti sui server all’interno di una stessa organizzazione Evitare l’attraversamento di gateway, quando possibile

Una nota sui Firewall Spesso si utilizzano firewall che agiscono sulla comunicazione SMTP limitando l’insieme dei comandi SMTP e degli argomenti. In altre parole limitano l’utilizzo di ESMTP Questo tipo di azione storicamente deriva da problemi riscontrati nel Sendmail Estensioni come NOTARY consentono una migliore traccia del traffico di email. E’ giusto eliminarle ? L’eliminazione delle linee Received che alcuni Firewall effettuano è inappropriata per i messaggi in ingresso. Critica per quelli in uscita (meglio riscriverle)

Naming Centralizzato e Centralizzazione del servizio

Il servizio di posta elettronica: alcune riflessioni Il servizio di posta elettronica: alcune riflessioni. Dal Naming Centralizzato alla Centralizzazione del servizio Ogni centro di servizio ha un proprio schema per l’indirizzamento dei propri utenti: chi usa il nome proprio, chi una semplice sigla..... marco@dominio, mb@dominio, F.Gennai@dominio Server che non supportano i nuovi standard rendono disomogenee le caratteristiche del servizio Server malgestiti creano problemi al servizio in Internet e problemi di sicurezza per lo stesso centro dove sono in funzione

Naming Centralizzato Distinzione tra l’indirizzo “reale” (ind. interno) di una mailbox e l’indirizzo con cui si identifica la persona o la funzione/ruolo di una mailbox (ind. esterno): mbax1@mail.iat.cnr.it F.Gennai@iat.cnr.it mbby1@mail.iat.cnr.it Segreteria@iat.cnr.it Adottare nomi delle mailbox consistenti con l’uso frequente anche in ambienti diversi (Elenchi telefonici (su carta), biglietti da visita, etc.) Francesco.Gennai@iat.cnr.it è meglio di F.Gennai@iat.cnr.it Adottare nomi mailbox di ruolo come da RFC 2142 (postmaster@dominio, webmaster, hostmaster, sales, etc...) Definire ed adottare i nomi di mailbox di ruolo per la tua organizzazione (esempio: segreteria@dominio, etc...)

Naming Centralizzato Per una gestione efficiente del naming utilizzare Directory Services LDAP (LDAPv3 RFC 2251-2256) è la soluzione emergente: LDAP è supportato dai maggiori produttori (spesso in sostituzione (o affiancato) ai Directory Service proprietari).

Naming Centralizzato Internet mail.iat.cnr.it ws1.iat.cnr.it Antonio Bianchi e Paolo Rossi hanno le proprie mailbox su ws1.iat.cnr.it Server W Router Directory server Francesco.Gennai@iat.cnr.it mbax1@mail.iat.cnr.it Antonio.Bianchi@iat.cnr.it antonio@ws1.iat.cnr.it Paolo.Rossi@iat.cnr.it paolo@ws1.iat.cnr.it PC di F. Gennai IAT Server: Distribuzione messaggi in ingresso. Filtra virus, converte formati in base al destinatario. Logging del traffico e degli accessi. Accesso POP/IMAP da client locali. Può controllare campo MAIL FROM dei messaggi in uscita. Può gestire più classi di utenza: una con accesso limitato all’Intranet, l’altra senza limiti. Router: Può impedire connessioni SMTP con host diversi da server.

Naming Centralizzato: verso una centralizzazione del servizio PC di Mario Rossi IRPEM (Ancona) Mario.Rossi@irpem.an.cnr.it mbby1@mail.iat.cnr.it Internet mail.iat.cnr.it ws1.iat.cnr.it Server W PC di F. Gennai IAT (Pisa) Router Directory server Server: Distribuzione messaggi in ingresso. Filtra virus, converte formati in base al destinatario. Logging del traffico e degli accessi. Accessi POP/IMAP da client locali e REMOTI (diverso meccanismo di autenticazione) Gestione del dominio “REMOTA”. Può controllare campo MAIL FROM dei messaggi in uscita. Può gestire più classi di utenza: una con accesso limitato all’Intranet, l’altra senza limiti. Router: Può impedire connessioni SMTP con host diversi da server.

La centralizzazione del servizio Ogni “infrastruttura di servizio” di una certa dimensione può trovare notevoli vantaggi in una centralizzazione del servizio di posta elettronica Vantaggi: pochi server da gestire: globale riduzione dei problemi di gestione. funzionalità aggiornate, maggiore omogeneità. gestione operativa centralizzata: backup, sviluppo, etc. Svantaggi: amministrazione del servizio “lontana” dall’utente periferico: gestione utenti, controllo traffico, etc. problemi di rete possono cambiare il livello di affidabiltà della comunicazione client/server. Come ridurre gli svantaggi ?

La delega della gestione amministrativa in un servizio centralizzato Amministrazione del servizio, introduciamo un nuovo concetto: Centralizzazione della gestione operativa, Distribuzione della gestione amministrativa Attività tipiche della gestione di un dominio: creazione/modifica/canc. mailbox creazione/modifica/canc. indirizzi e-mail (alias, forward) nel dominio creazione/modifica/canc./controllo mailing list nel dominio controllo attività di logging del sistema postmaster@dominio

La delega della gestione amministrativa in un servizio centralizzato L’amministratore dispone di un’interfaccia attraverso la quale svolge le attività di gestione del proprio dominio L’accesso all’interfaccia è protetto da password Più di un dominio può essere amministrato sullo stesso server da amministratori che accedono via rete La distribuzione dei server dovrà tenere conto dei punti di accesso alla rete e del flusso dei messaggi (tra utenti interni, verso utenti esterni) Le connessioni di rete oggi hanno un discreto livello di affidabilità

Naming centralizzato per organizzazioni topologicamente distribuite From: J.Smith@acme.com To: Mario.Rossi@cnr.it Internet pa.cnr.it cnr.it pi.cnr.it iat.cnr.it ict.pi.cnr.it Mario.Rossi@pa.cnr.it Mario.Rossi@pa.cnr.it Rete interna Email server Email server Mario.Rossi Mario.Rossi@pa.cnr.it LDAP directory server ge.cnr.it ice.ge.cnr.it itd.ge.cnr.it Email server Mario.Rossi Mario.Rossi@pa.cnr.it From: Luca.Bianchi@ge.cnr.it To: Mario.Rossi@cnr.it LDAP directory server

Autenticazione client/server nei protocolli “connection-based”

Autenticazione (POP, IMAP, SMTP-draft) SASL (RFC 2222) Simple Authentication and Security Layer: definizione di un metodo per la negoziazione di meccanismi di autenticazione in protocolli “connection-based” Registrati presso IANA: KERBEROS_V4 RFC 2222 GSSAPI SKEY EXTERNAL CRAM-MD5 RFC 2195 ANONYMOUS RFC 2245 Migrazione di tutti i protocolli verso l’utilizzo di autenticazione sicura EXTERNAL può essere TLS (Transport Layer Security - vari draft)

CRAM-MD5 RFC 2195 (P) IMAP/POP AUTHorize Extension for Simple Challenge/Response Offre un metodo per l’autenticazione client/server senza la necessità di far passare le password in chiaro sulla rete. Utilizza la tecnica descritta in RFC 2104 “HMAC: Keyed-Hashing for Message Authentication”. Simile a APOP Server e client conoscono la password Il server invia al client una stringa s (simile a message-id RFC 822) Il server applica una fuzione di hash a (password + s) Il client applica la stessa funzione a (password + s) ed invia il risultato al server Il server può ora autenticare il client Definito ANONYMOUS SASL per offrire l’accesso ANONYMOUS anche con il metodo SASL

Un esempio Caselle postali “aperte” e caselle postali “chiuse” From: Marco.Verdi@qualcosa.it To: K.Newman@fnal.gov From: Mario.Rossi@qualcosa.it To: J.Smith@cuny.edu Internet From: Luca.Bianchi@qualcosa.it To: Mario.Rossi@qualcosa.it YES Terminal server Firewall From: Mario.Rossi@qualcosa.it To: J.Smith@cuny.edu NO Email server Pc1 Pc2 Pcn qualcosa.it acme.it

Un altro esempio Configurazioni anti-relay ed accessi remoti From: Marco.Verdi@qualcosa.it To: K.Newman@fnal.gov From: Marco.Verdi@qualcosa.it To: K.Newman@fnal.gov From: S.Sting@fnal.gov To: Luca.Bianchi@qualcosa.it From: Mario.Rossi@qualcosa.it To: J.Smith@cuny.edu Internet From: Luca.Bianchi@qualcosa.it To: S.Sting@fnal.gov Terminal server Firewall Email server Pc1 Pc2 Pcn qualcosa.it acme.it

MIME e MTA MIME è un meccanismo che attua le sue funzioni nel colloquio tra User Agent Un Gateway tra ambienti diversi deve svolgere importanti funzioni MIME: per esempio inoltrare messaggi verso ambienti proprietari in genere richiede l’espletamento di funzioni quali: conversioni di formati, creazione di header MIME, encrypt/decrypt di messaggi. ma anche in ambiente “omogeneo” evitare la consegna di un messaggio che contiene un documento Word ad un UA che non può visualizzarlo è una funzione importante per un MTA (che possiamo identificare come Gateway tra ambienti UA incompatibili)

MIME gateway alcuni esempi Inoltro di un messaggio verso una lista di distribuzione: limitazioni sul messaggio ma anche sulle singole parti di un messaggio MIME multipart (Esempio: sostituzione di attachment image/gif con parte plain/text di avviso) Inoltro messaggio verso un dispositivo fax (email/fax-gateway) messaggio MIME multipart potrebbe contenere un attachment non compatibile con il dispositivo fax (Esempio: audio/basic) il fax-gateway, può verificare un eventuale firma digitale ed aggiungere al messaggio una parte MIME plain/text che riporti il risultato della verifica Politica di (sicurezza ?): nessun attachment di tipo Word, Powerpoint o Excel può essere trasmesso verso determinati domini (Esempio: dall’Intranet all’Internet)

messaggio da convertire MIME e MTA messaggio convertito messaggio da convertire cnvt UA reflector messaggio convertito convertitore Un esempio pratico: il servizio conversioni il messaggio MIME arriva e ciascuna parte che compone il body viene analizzata se il Content-type corrisponde a quello per cui è richiesta la conversione, la corrispondente parte è passata all’opportuno convertitore. Il risultato è quindi inserito nuovamente nel messaggio originale con Content-type: e gli altri parametri aggiornati se il Content-type non corrisponde a quello per cui è richiesta la conversione la parte viene rinserita nel messaggio originale senza alcuna modifica Al termine di questo processo ho la stessa struttura del messaggio originario, con alcune parti convertite

Header MIME (prima e dopo la conversione) i2pdf@mailsrv.cnuce.cnr.it Content-type: multipart/mixed; boundary=“x1234y” --x1234y Content-type: text/plain Ciao,..... Content-type: application/postscript %!PS-Adobe-1.0 %%Pages %%EndComments %%BeginProlog ............ . . . .. . . . . . . . . . . . . .. . ...... . .. ... . . .. .. .. . . . . ...... --x1234y-- Content-type: multipart/mixed; boundary=“x1234y” --x1234y Content-type: text/plain Ciao,..... Content-type: application/pdf; x-mac-type=50444620; x-mac-creator=4341524f; name=cnvt.pdf Content-disposition: INLINE; FILENAME=cnvt.pdf Content-transfer-encoding: BASE64 JVBERiOxLjFgHHHJKlllsKIjJjWGRLHSTbwKJYWjJH.... ...... .. . . . .. .. . . . . . . . . . . . . . . . . . .. . . --x1234y--