C
Consiglio Nazionale delle Ricerche
Istituto per le Applicazioni Telematiche
© Francesco Gennai 2000
iat
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).
© Francesco Gennai 2000
MIME
Multipurpose Internet Mail
Extensions
© Francesco Gennai 2000
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
© Francesco Gennai 2000
Multipurpose Internet Mail
Extensions (MIME)
Headers e indirizzi
To:
From :
cc:
Subject
Multipart
Data message
message (attachments)
Normale parte testo
caratteri
(7bit)
Uno
o piùUS-ASCII
“attachment”
lunghezza linea limitata a 80 caratteri
Immagine GIF
Documento MS Word
Messaggio rispedito (Forward)
© Francesco Gennai 2000
Multipurpose Internet Mail
Extensions
• rappresentazione e codifica di dati multimediali per
trasmissione via e-mail.
• estende la RFC822
• semplicità
• compatibilità
• flessibilità
© 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
© Francesco Gennai 2000
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)
© Francesco Gennai 2000
Multipurpose Internet Mail
Extensions
• MIME definisce 8 formati “Content-type”
• Nuove definizioni via documenti formali (RFC)
• Content-type:
- text
- image
- audio
- video
- message
- multipart
- application
- model
© 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
© 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
© 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
- quoted-printable
- 8bit
- 7bit
- binary
- x-nomecodifica
© 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: 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-© Francesco Gennai 2000
Multipurpose Internet Mail
Extensions
Gli RFC di riferimento:
RFC2045
RFC2046
RFC2047
Internet
RFC2048
RFC2049
Part I: Format of Internet Message Bodies
Part II: Media Types
Part III: Representation of Non-ASCII Text in
Message Headers
Part IV: Mime Registration Procedures
Part V: Conformance Criteria and Examples
© Francesco Gennai 2000
Alcune note
sull’organizzazione di un
servizio di posta
elettronica
© 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
mail.qualcosa.edu
mailsrv.cnuce.cnr.it
DSN Richiesta/Risposta
Internet
cnuce.cnr.it MX 10 mailsrv.cnuce.cnr.it
MX 20 mail.xx.cnr.it
mail.xx.cnr.it
fw.qualcosa.edu
= NON supporta DSN
= supporta DSN
© 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 all’interno di una stessa organizzazione
Evitare l’attraversamento di gateway, quando
possibile
© Francesco Gennai 2000
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)
© Francesco Gennai 2000
Naming Centralizzato
e
Centralizzazione del
servizio
© 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
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
© Francesco Gennai 2000
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):
[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...)
© Francesco Gennai 2000
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).
© Francesco Gennai 2000
Naming Centralizzato
Internet
mail.iat.cnr.it
ws1.iat.cnr.it
Server
Router
[email protected]
[email protected]
[email protected]
Server:
Router:
W
Antonio Bianchi e Paolo Rossi
hanno le proprie mailbox
su ws1.iat.cnr.it
Directory server
[email protected]
[email protected]
[email protected]
PC di F. Gennai
IAT
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.
Può impedire connessioni SMTP con host diversi da server.
© Francesco Gennai 2000
Naming Centralizzato: verso una
centralizzazione del servizio
PC di Mario Rossi
IRPEM (Ancona)
Internet
Router
Server:
Router:
[email protected]
mail.iat.cnr.it
ws1.iat.cnr.it
Server
W
Directory server
[email protected]
PC di F. Gennai
IAT (Pisa)
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.
Può impedire connessioni SMTP con host diversi da server.
© 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” 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 ?
© 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 e-mail (alias, forward) nel dominio
creazione/modifica/canc./controllo mailing list nel dominio
controllo attività di logging del sistema
postmaster@dominio
© Francesco Gennai 2000
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à
© Francesco Gennai 2000
Naming centralizzato per
organizzazioni topologicamente
distribuite
From: [email protected]
To: [email protected]
Internet
pa.cnr.it
[email protected]
Email
server
Rete interna
cnr.it
pi.cnr.it
iat.cnr.it
ict.pi.cnr.it
Email
server
LDAP
directory
server
Email
server
ge.cnr.it
ice.ge.cnr.it
itd.ge.cnr.it
From: [email protected]
To: [email protected]
Mario.Rossi
[email protected]
LDAP
directory server
© Francesco Gennai 2000
Autenticazione
client/server
nei protocolli
“connection-based”
© 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_V4
GSSAPI
SKEY
EXTERNAL
CRAM-MD5
ANONYMOUS
RFC 2222
RFC 2195
RFC 2245
Migrazione di tutti i protocolli verso l’utilizzo di autenticazione sicura
EXTERNAL può essere TLS (Transport Layer Security - vari draft)
© Francesco Gennai 2000
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
© Francesco Gennai 2000
Un esempio
Caselle postali “aperte” e caselle postali
“chiuse”
From: [email protected]
To: [email protected]
Internet
Firewall
NO
YES
Email
server
qualcosa.it
acme.it
From: [email protected]
To: [email protected]
Terminal
server
Pc1
Pc2
Pcn
From: [email protected]
To: [email protected]
© Francesco Gennai 2000
Un altro esempio
Configurazioni anti-relay ed accessi remoti
From: [email protected]
To: [email protected]
From: [email protected]
To: [email protected]
Internet
Firewall
Email
server
qualcosa.it
acme.it
From: [email protected]
To: [email protected]
Terminal
server
Pc1
Pc2
Pcn
From: [email protected]
To: [email protected]
© 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 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)
© 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 (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)
© Francesco Gennai 2000
MIME e MTA
messaggio da convertire
cnvt
messaggio
convertito
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
© Francesco Gennai 2000
Header MIME
(prima e dopo la conversione)
[email protected]
Content-type: multipart/mixed;
boundary=“x1234y”
Content-type: multipart/mixed;
boundary=“x1234y”
--x1234y
Content-type: text/plain
--x1234y
Content-type: text/plain
Ciao,.....
Ciao,.....
--x1234y
Content-type: application/postscript
--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
%!PS-Adobe-1.0
%%Pages
%%EndComments
%%BeginProlog
............ . . . .. . . . . . . . . . . . . .. .
...... . .. ... . . .. .. .. . . . . ......
--x1234y--
JVBERiOxLjFgHHHJKlllsKIjJjWGRLHSTbwKJYWjJH....
...... .. . . . .. .. . . . . . . . . . .
. . . . . . . .. . .
--x1234y-© Francesco Gennai 2000