1 / 37

Posta elettronica

C. Consiglio Nazionale delle Ricerche. iat. Istituto per le Applicazioni Telematiche. Francesco Gennai. Marina Buzzi. Posta elettronica. Posta elettronica. Alcuni cenni su “Multipurpose Internet Mail Extensions” (MIME) La posta certificata

shelly
Télécharger la présentation

Posta elettronica

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche Francesco Gennai Marina Buzzi Posta elettronica

  2. 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).

  3. MIMEMultipurpose Internet Mail Extensions

  4. 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

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

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

  7. 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. 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)

  9. 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. 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. 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. 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. 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: base64 • ..... 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-8859-1 • Content-transfer-encoding: quoted-printable • testo scritto in ISO-8859-1, questo testo =E8 codificato con= • =93quoted-printable=94 • --AAAconfine--

  14. 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

  15. Alcune note sull’organizzazione di un servizio di posta elettronica

  16. = NON supporta DSN = supporta DSN 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

  17. 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

  18. 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)

  19. Naming Centralizzato e Centralizzazione del servizio

  20. 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

  21. 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...)

  22. 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).

  23. 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.

  24. Internet Naming Centralizzato: verso una centralizzazione del servizio PC di Mario Rossi IRPEM (Ancona) Mario.Rossi@irpem.an.cnr.it mbby1@mail.iat.cnr.it 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.

  25. 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 ?

  26. 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

  27. 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à

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

  29. Autenticazione client/server nei protocolli “connection-based”

  30. 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)

  31. 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

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

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

  34. 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)

  35. MIME gatewayalcuni 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)

  36. MIME e MTA messaggio convertito messaggio da convertire cnvt UA reflector messaggio convertito • 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 convertitore

  37. Header MIME (prima e dopo la conversione) i2pdf@mailsrv.cnuce.cnr.it 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=50444620; x-mac-creator=4341524f; name=cnvt.pdf Content-disposition: INLINE; FILENAME=cnvt.pdf Content-transfer-encoding: BASE64 JVBERiOxLjFgHHHJKlllsKIjJjWGRLHSTbwKJYWjJH.... ...... .. . . . .. .. . . . . . . . . . . . . . . . . . .. . . --x1234y--

More Related