Posta elettronica

© Francesco Gennai 2000

C Consiglio Nazionale delle Ricerche

iatIstituto per le Applicazioni Telematiche


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


MIMEMIMEMultipurpose Internet Mail Multipurpose Internet Mail

ExtensionsExtensions


RFC 822 (S)RFC 822 (S)Standard for the format of ARPA Internet Standard for the format of ARPA Internet text messagestext messages

To:From :cc:Subject

Data message

Headers e indirizzi

Normale parte testo caratteri US-ASCII (7bit)lunghezza linea limitata a 80 caratteri


Data message Normale parte testo caratteri US-ASCII (7bit)lunghezza linea limitata a 80 caratteri

Multipurpose Internet Mail Multipurpose Internet Mail Extensions (MIME)Extensions (MIME)

To:From :cc:Subject

Headers e indirizzi

Uno o più “attachment”

Messaggio rispedito (Forward)

Multipart message (attachments) Normale parte testo

Immagine GIF Immagine GIF

Documento MS Word Documento MS Word


Multipurpose Internet Mail Multipurpose Internet Mail ExtensionsExtensions

• rappresentazione e codifica di dati multimediali per trasmissione via e-mail.

• estende la RFC822• semplicità • compatibilità• flessibilità



• 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


Multipurpose Internet Mail ExtensionsMultipurpose 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)



• MIME definisce 8 formati “Content-type”• Nuove definizioni via documenti formali (RFC)• Content-type:

- text - message

- image - multipart

- audio - application

- video - model



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



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



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 MULTIPARTEsempio messaggio MULTIPARTFrom: .....Subject: ....Content-type: multipart/mixed; boundary=AAAconfine--AAAconfineparte contenente testo in US-ASCII infatti non e’ marcata con Content-transfer-encoding--AAAconfineContent-type: multipart/parallel; boundary=XXXsepara

--XXXseparaContent-type: audio/basicContent-transfer-encoding: base64

..... dati audio codificati in base64

--XXXseparaContent-type: image/gifContent-transfer-encoding: base64

... dati per immagine gif codificati in base64

--XXXsepara--

--AAAconfineContent-type: text/plain; charset=ISO-8859-1Content-transfer-encoding: quoted-printable

testo scritto in ISO-8859-1, questo testo =E8 codificato con= =93quoted-printable=94--AAAconfine--



Gli RFC di riferimento:RFC2045 Part I: Format of Internet Message

BodiesRFC2046 Part II: Media TypesRFC2047 Part III: Representation of Non-ASCII

Text in Internet Message HeadersRFC2048 Part IV: Mime Registration ProceduresRFC2049 Part V: Conformance Criteria and

Examples


Alcune note Alcune note sull’organizzazione di un sull’organizzazione di un

servizio di posta elettronicaservizio di posta elettronica


Un servizio SMTP omogeneoUn 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


Un servizio SMTP omogeneoUn 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 FirewallUna 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 Naming Centralizzato e e

Centralizzazione del servizioCentralizzazione del servizio


Il servizio di posta elettronica:Il servizio di posta elettronica:alcune riflessioni.alcune riflessioni.Dal Naming Centralizzato alla Dal Naming Centralizzato alla Centralizzazione del servizioCentralizzazione 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 CentralizzatoNaming 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):[email protected] [email protected] [email protected] [email protected]

• Adottare nomi delle mailbox consistenti con l’uso frequente anche in ambienti diversi (Elenchi telefonici (su carta), biglietti da visita, etc.)[email protected] è meglio di [email protected]

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



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



Server

[email protected] [email protected]@iat.cnr.it [email protected]@iat.cnr.it [email protected]

mail.iat.cnr.it

W

ws1.iat.cnr.it

PC di F. GennaiIAT

Antonio Bianchi e Paolo Rossihanno le proprie mailbox su ws1.iat.cnr.it

Directory serverRouter

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.

Internet


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.

Naming Centralizzato: verso una Naming Centralizzato: verso una centralizzazione del serviziocentralizzazione del servizio

Server

[email protected] [email protected]

Internet mail.iat.cnr.it

W

ws1.iat.cnr.it

PC di Mario RossiIRPEM (Ancona)

PC di F. GennaiIAT (Pisa)

RouterDirectory server


La centralizzazione del servizioLa 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 La delega della gestione amministrativa in un servizio amministrativa in un servizio centralizzatocentralizzato• 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 La delega della gestione amministrativa in un servizio amministrativa in un servizio centralizzatocentralizzato• 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 Naming centralizzato per organizzazioni topologicamente distribuitetopologicamente distribuite

Internet

LDAPdirectory server

Emailserver

cnr.itpi.cnr.itiat.cnr.itict.pi.cnr.it

Emailserver

ge.cnr.itice.ge.cnr.ititd.ge.cnr.it

Emailserver

pa.cnr.it

Rete interna

LDAPdirectory server

From: [email protected]: [email protected]

[email protected]

Mario.Rossi [email protected]


[email protected]

Mario.Rossi [email protected]


Autenticazione client/server Autenticazione client/server nei protocolli nei protocolli

“connection-based”“connection-based”


AutenticazioneAutenticazione(POP, IMAP, SMTP(POP, IMAP, SMTP-draft-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)CRAM-MD5 RFC 2195 (P)IMAP/POP AUTHorize Extension for Simple IMAP/POP AUTHorize Extension for Simple Challenge/ResponseChallenge/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 APOPServer 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 esempioUn esempioCaselle postali “aperte” e caselle postali Caselle postali “aperte” e caselle postali “chiuse”“chiuse”

Firewall

Emailserver

Internet

Terminalserver

Pc1 Pc2 Pcn

qualcosa.itacme.it


YES


NO





Un altro esempioUn altro esempioConfigurazioni anti-relay ed accessi remotiConfigurazioni anti-relay ed accessi remoti

Firewall

Emailserver

Internet

Terminalserver

Pc1 Pc2 Pcn

qualcosa.itacme.it


From: [email protected]: [email protected] From: [email protected]

To: [email protected]


MIME e MTAMIME 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 gatewayMIME gatewayalcuni esempialcuni 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)


MIME e MTAMIME 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 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

cnvtmessaggio da convertire

messaggio convertito

convertitore

UAreflector

UAreflector

messaggio convertito


Header MIME Header MIME (prima e dopo la conversione(prima e dopo la conversione))

Content-type: multipart/mixed; boundary=“x1234y”

--x1234yContent-type: text/plain

Ciao,.....

--x1234yContent-type: application/postscript

%!PS-Adobe-1.0%%Pages%%EndComments%%BeginProlog............ . . . .. . . . . . . . . . . . . .. . ...... . .. ... . . .. .. .. . . . . ......--x1234y--

[email protected]

Content-type: multipart/mixed; boundary=“x1234y”

--x1234yContent-type: text/plain

Ciao,.....

--x1234yContent-type: application/pdf; x-mac-type=50444620; x-mac-creator=4341524f; name=cnvt.pdfContent-disposition: INLINE; FILENAME=cnvt.pdfContent-transfer-encoding: BASE64

JVBERiOxLjFgHHHJKlllsKIjJjWGRLHSTbwKJYWjJH.......... .. . . . .. .. . . . . . . . . . . . . . . . . . .. . .--x1234y--

Posta elettronica

Documents

Transcript of Posta elettronica