La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

© Francesco Gennai 2000 C Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche.

Presentazioni simili


Presentazione sul tema: "© Francesco Gennai 2000 C Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche."— Transcript della presentazione:

1 © Francesco Gennai 2000 C Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche

2 © Francesco Gennai 2000 Posta elettronica Alcuni cenni su Multipurpose Internet Mail Extensions (MIME) La posta certificata Un progetto basato sullelaborazione 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 (spamming).

3 © Francesco Gennai 2000 MIME Multipurpose Internet Mail Extensions

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

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

6 © Francesco Gennai 2000 Multipurpose Internet Mail Extensions rappresentazione e codifica di dati multimediali per trasmissione via . estende la RFC822 semplicità compatibilità flessibilità

7 © Francesco Gennai 2000 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

8 © Francesco Gennai 2000 Multipurpose Internet Mail Extensions Un messaggio MIME può contenere: più oggetti allinterno 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)

9 © Francesco Gennai 2000 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

10 © Francesco Gennai 2000 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

11 © Francesco Gennai 2000 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

12 © Francesco Gennai 2000 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

13 © Francesco Gennai 2000 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 --AAAconfine Content-type: multipart/parallel; boundary=XXXsepara --XXXsepara Content-type: audio/basic Content-transfer-encoding: base dati audio codificati in base64 --XXXsepara Content-type: image/gif Content-transfer-encoding: base64... dati per immagine gif codificati in base64 --XXXsepara-- --AAAconfine Content-type: text/plain; charset=ISO Content-transfer-encoding: quoted-printable testo scritto in ISO , questo testo =E8 codificato con= =93quoted-printable=94 --AAAconfine--

14 © Francesco Gennai 2000 Multipurpose Internet Mail Extensions Gli RFC di riferimento: RFC2045Part I: Format of Internet Message Bodies RFC2046Part II: Media Types RFC2047Part III: Representation of Non-ASCII Text in Internet Message Headers RFC2048Part IV: Mime Registration Procedures RFC2049Part V: Conformance Criteria and Examples

15 © Francesco Gennai 2000 Alcune note sullorganizzazione di un servizio di posta elettronica

16 © Francesco Gennai 2000 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 Internet cnuce.cnr.it MX 10 mailsrv.cnuce.cnr.it MX 20 mail.xx.cnr.it mailsrv.cnuce.cnr.it mail.xx.cnr.it fw.qualcosa.edu = supporta DSN = NON supporta DSN mail.qualcosa.edu DSN Richiesta/Risposta

17 © Francesco Gennai 2000 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 allinterno di una stessa organizzazione Evitare lattraversamento di gateway, quando possibile

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

19 © Francesco Gennai 2000 Naming Centralizzato e Centralizzazione del servizio

20 © Francesco Gennai 2000 Il servizio di posta elettronica: alcune riflessioni. Dal Naming Centralizzato alla Centralizzazione del servizio Ogni centro di servizio ha un proprio schema per lindirizzamento dei propri utenti: chi usa il nome proprio, chi una semplice sigla 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

21 © Francesco Gennai 2000 Naming Centralizzato Distinzione tra lindirizzo reale (ind. interno) di una mailbox e lindirizzo con cui si identifica la persona o la funzione/ruolo di una mailbox (ind. esterno): Adottare nomi delle mailbox consistenti con luso frequente anche in ambienti diversi (Elenchi telefonici (su carta), biglietti da visita, etc.) è meglio di Adottare nomi mailbox di ruolo come da RFC 2142 webmaster, hostmaster, sales, etc...) Definire ed adottare i nomi di mailbox di ruolo per la tua organizzazione (esempio: etc...)

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

23 © Francesco Gennai 2000 Naming Centralizzato Server mail.iat.cnr.it W ws1.iat.cnr.it PC di F. Gennai IAT Antonio Bianchi e Paolo Rossi hanno le proprie mailbox su ws1.iat.cnr.it Directory server Router 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 allIntranet, laltra senza limiti. Router:Può impedire connessioni SMTP con host diversi da server. Internet

24 © Francesco Gennai 2000 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 allIntranet, laltra senza limiti. Router:Può impedire connessioni SMTP con host diversi da server. Naming Centralizzato: verso una centralizzazione del servizio Server Internet mail.iat.cnr.it W ws1.iat.cnr.it PC di Mario Rossi IRPEM (Ancona) PC di F. Gennai IAT (Pisa) Router Directory server

25 © Francesco Gennai 2000 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 dallutente periferico: gestione utenti, controllo traffico, etc. problemi di rete possono cambiare il livello di affidabiltà della comunicazione client/server. Come ridurre gli svantaggi ?

26 © Francesco Gennai 2000 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 (alias, forward) nel dominio creazione/modifica/canc./controllo mailing list nel dominio controllo attività di logging del sistema

27 © Francesco Gennai 2000 La delega della gestione amministrativa in un servizio centralizzato Lamministratore dispone di uninterfaccia attraverso la quale svolge le attività di gestione del proprio dominio Laccesso allinterfaccia è 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à

28 © Francesco Gennai 2000 Naming centralizzato per organizzazioni topologicamente distribuite Internet LDAP directory server server cnr.it pi.cnr.it iat.cnr.it ict.pi.cnr.it server ge.cnr.it ice.ge.cnr.it itd.ge.cnr.it server pa.cnr.it Rete interna LDAP directory server From: To: Mario.Rossi From: To:

29 © Francesco Gennai 2000 Autenticazione client/server nei protocolli connection-based

30 © Francesco Gennai 2000 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_V4RFC 2222 GSSAPI SKEY EXTERNAL CRAM-MD5RFC 2195 ANONYMOUSRFC 2245 Migrazione di tutti i protocolli verso lutilizzo di autenticazione sicura EXTERNAL può essere TLS (Transport Layer Security - vari draft)

31 © Francesco Gennai 2000 CRAM-MD5 RFC 2195 (P) IMAP/POP AUTHorize Extension for Simple Challenge/Response Offre un metodo per lautenticazione 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 laccesso ANONYMOUS anche con il metodo SASL

32 © Francesco Gennai 2000 From: To: Un esempio Caselle postali aperte e caselle postali chiuse Firewall server Internet Terminal server Pc1Pc2Pcn qualcosa.it acme.it From: To: YES From: To: NO From: To:

33 © Francesco Gennai 2000 From: To: From: To: Un altro esempio Configurazioni anti-relay ed accessi remoti Firewall server Internet Terminal server Pc1Pc2Pcn qualcosa.it acme.it From: To: From: To: From: To:

34 © Francesco Gennai 2000 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 lespletamento 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)

35 © Francesco Gennai 2000 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 ( /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: dallIntranet allInternet)

36 © Francesco Gennai 2000 MIME e MTA 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 allopportuno 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 cnvt messaggio da convertire messaggio convertito convertitore UA reflector UA reflector messaggio convertito

37 © Francesco Gennai 2000 Header MIME (prima e dopo la conversione ) Content-type: multipart/mixed; boundary=x1234y --x1234y Content-type: text/plain Ciao, x1234y Content-type: application/postscript %!PS-Adobe-1.0 %Pages %EndComments %BeginProlog x1234y-- Content-type: multipart/mixed; boundary=x1234y --x1234y Content-type: text/plain Ciao, x1234y Content-type: application/pdf; x-mac-type= ; x-mac-creator= f; name=cnvt.pdf Content-disposition: INLINE; FILENAME=cnvt.pdf Content-transfer-encoding: BASE64 JVBERiOxLjFgHHHJKlllsKIjJjWGRLHSTbwKJYWjJH x1234y--


Scaricare ppt "© Francesco Gennai 2000 C Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche."

Presentazioni simili


Annunci Google