Consiglio Nazionale delle Ricerche Posta...

Acireale 2001 Francesco GennaiIAT - CNR

1

C o n s i g l i o N a z i o n a l e d e l l e R i c e r c h e

Posta Elettronica

Francesco GennaiFrancesco Gennai

Istituto per le Applicazioni Telematiche [email protected]

AcirealeAcireale, , 22--7 Luglio 20017 Luglio 2001

Posta elettronicaPosta elettronica


2


Posta Elettronica

Indirizzato a:• Referenti CNR per i servizi di rete

Contenuti:• Aggiornamento sulle evoluzioni in corso

• Case study

• Modello di servizio: gestione centralizzata e amministrazione distribuita

• Presentazione interfaccia MailboxManager


3


Posta Elettronica

Canali• SMTP

– trasferimento “store and forward”

– Indirizzi e messaggi

• POP/IMAP– accesso remoto alle mailbox

(modalità client/server)

Oggetti• RFC2822

– struttura degli “header”

– indirizzamento

• MIME– struttura del contenuto di un

messaggio

– codice dei caratteri

– dati multimediali

– codifica del messaggio


4


Posta Elettronica

SMTP (Simple Mail Transfer Protocol)

• RFC 2821 (Aprile 2001)– Sostituisce: RFC 821, RFC 974, RFC 1869

– Aggiorna: RFC 1123

Internet Message Format

• RFC 2822 (Aprile 2001)– Sostituisce: RFC 822 (Standard for the format of ARPA Internet text messages)


5


Posta ElettronicaUA = User AgentOriginator = nodo che immette il messaggioin reteRelay = nodo di transito da Internet a InternetDelivery = nodo che consegna il messaggio all’utente finaleG/W = nodo di transito verso altre architettureMS = Message Store (contiene mailbox)MTA = Message Transfer Agent

UA = User AgentOriginator = nodo che immette il messaggioin reteRelay = nodo di transito da Internet a InternetDelivery = nodo che consegna il messaggio all’utente finaleG/W = nodo di transito verso altre architettureMS = Message Store (contiene mailbox)MTA = Message Transfer Agent

MHS = Message Handling SystemMHS = Message Handling System

UAUAUA UAUAUAMSMSMS

Submission Relay Delivery

G/WG/W . . .

Access

RelayRelay DeliveryDeliveryOriginatorOriginator

Relay

MTA MTA

MTA

MTA


6


Posta Elettronica

Posta elettronica InternetPosta elettronica Internet

SMTP POP o IMAPFile I/OSMTP

Messaggio:RFC2822MIME

UAUAUA UAUAUAMSMSMS

. . .

RelayRelay DeliveryDeliveryOriginatorOriginator

SMTP


7


Posta Elettronica

• RFC 2821 e RFC 2822 per….. chiarire (non modificare!)

• RFC 2821: – local-part max 64 caratteri

– domain-part max 255 caratteri

– path (forward o reverse) max 256 caratteri

• RFC 2822– campo date: anno 4 cifre, time zone solo numerica (Es.: +0001)

– proibiti indirizzi con informazioni di instradamento “routes” (Es.: @mail.iat.cnr.it:[email protected])

– nessun obbligo di presenza campi destinazione (to:, cc: e bcc:)


8


Posta Elettronica

• Verso un nuovo sistema di messaggistica

Unified Messaging– Electronic Messaging Association (EMA)

– VPIM EMA Work Group• Voice Profile for Internet Mail (1996 VPIM1) – (1998 VPIM2)

Profilo per utilizzo di SMTP e MIME tra sistemi di messagistica vocale

– IETF-VPIM Working Group• IVM – Internet Voice Mail (lavori in corso per VPIM3)

Profilo per interoperabilità tra sistemi di messaggistica integrata(voce, email, fax) utilizzando l’infrastruttura esistente SMTP/MIME


9


Posta Elettronica

• IETF-FAX– Interoperabilità tra sistemi di posta elettronica e sistemi fax.– Trasporto di fax utilizzando l’architettura (store/forward) Internet esistente

(SMTP/MIME)– Trasporto di fax in modalità “session” o “real-time”

– Caratteristiche del sistema fax tradizionale:• Consegna immediata• Conferma (ricevuta) dell’avvenuta consegna• Semplicità d’uso

– Caratteristiche del sistema email tradizionale:• Consegna differita• Nessuna (ricevuta) dell’avvenuta consegna è garantita • Possibilità di rispondere (reply) al mittente• Possibilità di spedire a più destinatari


10


Posta Elettronica

Problematiche comuni • Limitare introduzione di nuovi protocolli• Modifiche ai protocolli esistenti compatibili alle attuali specifiche• Modifiche indipendenti dal particolare problema: fruibilità da parte di

altri gruppi per scopi analoghi• Conoscenza delle “capability” del ricevente

– Nei sistemi “session-oriented” (es.: fax tradizionale, sistemi vocali) è prevista una fase di “content negotiation” dal protocollo di comunicazione

– Nel sistema “posta elettronica” tradizionale non vi sono meccanismi per riconoscere le “capability” del/dei ricevente/i

• Si assumono “capability” di base che devono essere accettate per conformità alle specifiche IETF

• In discussione soluzioni per il “content negotian” via posta elettronica


11


Posta Elettronica

• Alcuni esempi di problematiche in discussione– “Content negotiation” è tipicamente una funzione a “loop chiuso”.

Come definirla sopra l’infrastruttura di email che è di tipo“loop aperto” (send-and-pray) ?

• Proposte in discussione (WG IETF-FAX): – estensioni a MDN (Message Disposition Notification – RFC 2298)

– estensioni a MIME (Content-alternative)

– Estensioni a RFC 2822 (Original-Message-ID)


12


Posta Elettronica

• Alcuni esempi di problematiche in discussione– Il ricevente deve inviare una notifica (DSN – Delivery Service

Notification) al mittente nel caso non sia capace di “presentare” il contenuto del messaggio

– Si possono utilizzare strutture MIME Multipart per trasmettere più formati di uno stesso dato

– Gateway: impossibilità di rappresentare tutte le parti di un messaggio nell’ambiente di destinazione. Problema: il messaggio è rifiutato anche se alcune parti erano rappresentabili -> riconoscere importanza della singola parte

• Proposte in discussione (WG IETF-VPIM):– Estensioni a MIME: Critical-content– Partial non-delivery notification


13


Posta Elettronica

• Message Tracking (IETF-MSGTRK)– Localizzare un messaggio all’interno di Internet

– Fornire una soluzione che sia multivendor• In discussione:

– Estensioni SMTP per trasporto della richiesta di tracking

– Definizione di un formato per MSTN (Message Tracking Status Notification) (molto simile a DSN)

– Definizione di un protocollo per interrogare i “tracking server” (MTQP -Message Tracking Query Protocol)


14


Posta Elettronica

SIEVE


15


Posta Elettronica

SIEVE (RFC 3028)

• Linguaggio “script” con cui è possibile creare filtri per messaggi di posta elettronica

• Applicabile sia a livello client che server

• Possiede elementi per facilmente identificare le parti standard di un messaggio: header, indirizzi, parti MIME

• Progettato anche per creazione “script” via GUI


16


Posta Elettronica

SIEVE (RFC 3028)

• Vantaggi di un linguaggio standard:– Condivisione dei filtri (Es.: distribuiti via directory server)

– Trasportabilità tra piattaforme diverse

– Applicabile alle diverse fasi di consegna di un messaggio• MTA -> MS

• MS -> UA

• MS -> MS (IMAP server)


17


Posta Elettronica

Filtro SIEVE per “cancellare” messaggi provenienti da [email protected] header :contains ["return-path","from"] [“[email protected]"] {

discard;

}

Filtro SIEVE per limitare la dimensione di un messaggio.require ["reject"];

if size :over 2m {

reject "Your message has exceeded the max size imposed by the system administrator";

}

Il sistema genererà una DSN riportando la frase presente nel comando “reject”.


18


Posta Elettronica

Case study


19


Posta Elettronica

• Casi di spamming (involontario – causati da virus email) possono efficacemente essere filtrati con SIEVE

if allof (header :contains [“From”] “[email protected]”,

header :contains [“subject”] “Nota trimestrale”) {

discard;

}


20


Posta Elettronica

• PMDF può utilizzare filtri SIEVE a livello:– Globale, sistema (Esempio: livello in cui definire il precedente filtro)– Singolo canale (ingresso e/o uscita)– Singolo utente

• PMDF ha una interfaccia web per la creazione di semplici filtri SIEVE (campi source, destination e subject).– Accesso sistemista per filtri di sistema e di canale– Accesso utente per filtri personali

• Filtri più complessi possono essere creati manualmente.• MULBERRY (client IMAP/POP) ha interfaccia per creazione

filtri SIEVE.


21


Posta Elettronica

Configurazione di un ambiente HelpDesk

Ingredienti:• IMAP (Internet Message Access Protocol)

• accesso e gestione messaggi sul server

• flag sui messaggi (new, seen, replied, forwarded, etc)

• SIEVE (Linguaggio per la creazione di filtri su posta elettronica)

• SubAddressing



22


Posta Elettronica

• IMAP server che supporta estensione IMAP per le Access Control List (IMAP4 ACL extension – RFC 2086)– Metodi di accesso definiti per una mailbox IMAP sono:

• l – listing della mailbox

• r – lettura dei messaggi nella mailbox (copia, ricerca, etc..)

• s – gestione flag “seen”

• w – gestione flag diversi da “seen” e “deleted”

• i – aggiungi un nuovo messaggio alla mailbox (Append/Copy)

• c – creazione di sub-mailbox

• d – cancellazione messaggio (flag “deleted”, abilita a Expugne)

• a – amminstratore (gestione ACL)

I flag IMAP sono:Answered, Deleted, Draft, Flagged, Seen, Recent


23


Posta Elettronica

• Casella di helpdesk corrispondente a [email protected]– Struttura di helpdesk composta da 8 operatori. Ogni operatore ha

proprio accesso al server (oper1, oper2, …)– Gli operatori possono solo leggere, rispondere, spostare i

messaggi. Non possono cancellare i messaggi. (problema 1)– Esiste un accesso privilegiato (operpriv) per la cancellazione dei

messaggi.– Le risposte di ciascun operatore devono essere condivise dagli

altri. (problema 2)– All’indirizzo dell’helpdesk giunge una notevole quantità di

messaggi “spuri”. Tipicamente DSN provenienti da host malconfigurati. Sono di notevole disturbo per le normali attività di helpdesk. (problema 3)


24


Posta Elettronica

HUserINBOX

hostmaster

FromHostMaster

ErrorNotifications Messaggi con From o [email protected]

Messaggi con [email protected]

Messaggi provenienti da [email protected](sono le risposte degli 8 operatori)

Tutti gli altri messaggi in arrivo

La struttura delle mailbox da condividere sul server è la seguente(Nota: in IMAP il concetto di folder è assimilato a quello di mailbox)


25


Posta Elettronica

• Problema 1. Gli operatori possono solo leggere, rispondere, muovere i messaggi tra le diverse mailbox.Non possono cancellare i messaggi.– Utilizzo delle ACL per definire tale politica di accesso alle

mailbox condivise.• Oper1, … oper8 avranno accesso del tipo lrswi a tutte le mailbox

sotto Huser (hostmaster, FromHostMaster, ErrorNotifications)

• Operpriv avrà accesso totale su tutte le mailbox


26


Posta Elettronica

• Problema 2. Le risposte di ciascun operatore devono essere condivise dagli altri. – Si utilizza il subaddressing.

• Esempio: [email protected]

– Il subaddressing è molto utile (diversi casi)

– Nel caso di mailbox IMAP:• indirizzo [email protected] corrisponde alla mailbox gennai

• messaggio indirizzato a [email protected] sarà inserito direttamente nella mailbox gennai/tech-ref

• Soluzione problema 2: tutti i client sono configurati per spedire in bcc: a [email protected]. Messaggi inviati a [email protected] sono salvati nella mailboxHUser/FromHostMaster


27


Posta Elettronica• Problema 3. Eliminazione messaggi “spuri” (automaticamente salvati nel folder

ErrorNotifications) mediante filtro SIEVE

require ["fileinto"];if header :contains ["return-path","from"] ["[email protected]"] {fileinto "ErrorNotifications";}elsif header :contains ["to"] ["[email protected]"] {fileinto "ErrorNotifications";}elsif header :contains ["return-path","from","sender","resent-from","resent-sender"] ["[email protected]"] {fileinto "FromHostMaster";}else {fileinto "hostmaster";}


28


Posta Elettronica

HUserINBOX

hostmaster

FromHostMaster

ErrorNotificationsMessaggi con From o Return-path

[email protected] con To

[email protected](filtro SIEVE)

Messaggi provenienti da [email protected](sono le risposte degli 8 operatori)

(Subaddressing)

Tutti gli altri messaggi in arrivo(filtro SIEVE)

Riassunto


29


Posta Elettronica

Il progetto

Biblio MIME


30


Posta Elettronica

• Realizzazione di un gateway tra posta elettronica e web a supporto del servizio di Documet Delivery tra bibliotechedel CNR

• Studio e sviluppo in collaborazione tra: – Area di Ricerca CNR-Bologna

– Istituto per le Applicazioni Telematiche CNR-Pisa

• Finanziato dalla Commissione di Studio per lo Sviluppo dell’Infrastruttura di Rete Telematica del CNR


31


Posta Elettronica

Trasmissione del documento:personal computerscannerclient posta elettronica

Trasmesso come “ATTACHMENT”di un messaggio di posta elettronica

Ricezione del documento:personal computerclient posta elettronicaweb browser

Ricevuto mediante“DOWNLOAD” via sessione HTTP da sitoweb


32


Posta Elettronica

Data message

Normale parte testo caratteri US-ASCII (7bit)lunghezza linea limitata a 80 caratteriUno o più “attachment”

Messaggio rispedito (Forward)

Multipart message (attachments)

Normale parte testo

Immagine Immagine GIF GIF

Documento Documento MS Word MS Word

Multipurpose Internet Mail Extensions (MIME)

To:From :cc:Subject

Headers e indirizzi


33


Posta Elettronica

Server Biblio MIMEe-mail - web

Messaggio MIME con uno o piùattachment

image/tiffapplication/pdf

text/plain

intestazione

Biblioteca A

Biblioteca B

Biblioteca X

To: [email protected]

Messaggio MIME con parte text/htmlcontenente URL del documento

text/plain

text/html

intestazioneDestinazione remota

To: [email protected]

UAUAUA OriginatorOriginatorOriginator

MTA

UAUAUAMSMSMSRelayRelayRelay DeliveryDeliveryDelivery

MTA MTA


34


Posta Elettronica Esempio messaggio MULTIPART

1.1 TESTO

1.2PDF

1.3JPEG

From: .....Subject: ....Conthent-type: multipart/mixed; boundary=AAAconfine--AAAconfineCaro collega,ti trasmettiamo due allegati contenenti il documento richiesto. Per tua convenienza il primo è in formato PDF, il secondo in formato JPEG.Cordiali saluti,Servizio Biblioteca blah blah --AAAconfineContent-type: application/pdfContent-transfer-encoding: base64... dati PDF codificati in base64

--AAAconfineContent-type: image/jpgContent-transfer-encoding: base64… dati JPEG codificati in base64--AAAconfine--


35


Posta Elettronica

• Sviluppi in corso:– Upload del documento via web

– Realizzazione di un sistema distribuito BiblioMime:• Gestione dinamica di una lista dei server attivi

• Ogni server può essere backup di un altro

• Esclusione automatica di un server in caso di “server failure”– Le connessioni dei client saranno automaticamente indirizzate ad un

server attivo di backup

– Mantenimento della consistenza delle configurazioni, dati di log, etc tra i vari server

– Trasmissione via fax (sperimentale e solo per autorizzati).


36


Posta Elettronica

Modelli per l’organizzazione di un servizio di rete

Applicazione al servizio diposta elettronica


37


Posta Elettronica

Soluzione distribuitapro

• flessibile

• minimizza i tempi di risposta (per richieste utenti)

contro

• maggiori risorse hw/sw e umane

• aumenta costi


38


Posta Elettronica

à ’


39


Posta Elettronica


40


Posta Elettronica

Soluzione centralizzata

pro

• riduce i costi

• semplifica il controllo e la gestione del servizio

contro

• single point of failure

• limita la flessibilità e autonomia delle unità periferiche


41


Posta Elettronica


Centralized management with delegated administration (CMDA)

• gestione centralizzata (maintenance, monitoraggio, etc.)

• delega dell’amministrazione alle singole unità dell’organizzazione


42


Posta Elettronica


Vantaggi del CMDA• riduce il numero dei server al minimo numero tecnicamente

richiesto

• semplifica il controllo e la gestione del servizio (Il maggior controllo tecnico facilita l’introduzione di nuovi servizi come per esempio LDAP)

• riduce i costi

• flessibile (max autonomia amministratori locali)

• minimizza i tempi di risposta (per gli utenti)


43


Posta Elettronica


Limitazioni del CMDA• single point of failure (adozione di cluster)

• banda garantita (se si adotta su scala geografica)– Infrastrutture sono affidabili, le distanze sono “virtuali”

– Traffico di PE incide per una “piccola parte” rispetto al web

– Valutare cosa costa meno: aumentare la velocità delle linee (trend -> i costi diminuiscono) o mantenere più server


44


Posta Elettronica


Ulteriori vantaggi del modello• Riduce gli errori umani

• Non richiede personale specializzato

• Organizzazione hosting dei servizi di PE non gestisce la parte di amministrazione

aumento dei domini non aumenta i compiti per l’organizzazione che gestisce e controlla il servizio


45


Posta Elettronica

Affidabilità del servizio

• SCSI cluster costituito da due sistemi che condividono un RAID disk array ed effettuano DNS load balancing

• Questo ci abilita ad effettuare maintenance su un nodo, senza alcuna interruzione del servizio

• Il degrado di pestazioni su un nodo (esempio eccessivo utilizzo di risorse CPU o I/O) è riconosciuto dall’algoritmo di load balancing che indirizzerà le successive connessioni al nodo più efficiente


46


Posta Elettronica

Name server di iat.cnr.it

pop.iat.cnr.it NS mx1.iat.cnr.itmx2.iat.cnr.it

smtp.iat.cnr.it NS mx1.iat.cnr.itmx2.iat.cnr.it

mx1.iat.cnr.it A 146.48.65.88mx2.iat.cnr.it A 146.48.65.89iat.cnr.it MX 10 mx1.iat.cnr.it

MX 10 mx2.iat.cnr.it

pop.iat.cnr.it TTL=0 146.48.65.89 146.48.65.88

mx2.iat.cnr.it146.48.65.89

mx1.iat.cnr.it146.48.65.88

Cluster OpenVMS con DNS load balancing

Client pop/imap/smtp

Raidarray

ClusterOpenVMS

iat.cnr.it MX 10 mx1.iat.cnr.itMX 10 mx2.iat.cnr.itInternetInternet

Chiede record A per pop.iat.cnr.it

Ottiene NS

BusSCSI

BusSCSI


47


Posta Elettronica

MailboxManager


48


Posta Elettronica

Mailboxmanager: interfaccia di amministrazione• Gestione caselle POP e/o IMAP

– Creazione/cancellazione

– Possibilità di impostare informazioni utili alla gestione mailbox (owner, flag, data scadenza)

– Controllo sull’attività della mailbox:• Numero messaggi

• Spazio disco occupato

• Data/ora ultima connessione

• ……..


49


Posta Elettronica

Mailboxmanager: interfaccia di amministrazione

• Propone uno schema di indirizzamento. Ma non obbliga alla sua adozione.

• Creazione automatica dell’indirizzo ufficiale (derivato da Nome e Cognome):

• nome.cognome@dominio

e degli alias: • iniziale-nome.cognome@dominio

• cognome@dominio



50


Posta Elettronica

• RFC 2821 – differenza tra alias con destinazioni multiple e lista di distribuzione.– Alias: il sistema MTA agisce a livello di envelope sostituendo:

• all’indirizzo di destinazione “alias” la lista di indirizzi risultante dalla sua espansione.

• Il messaggio è spedito a ciascun destinatario non cambiando niente altro nell’envelope e nel body del messaggio.

– Lista: il sistema MTA agisce a livello envelope sostituendo:• all’indirizzo di destinazione “list” la lista di indirizzi risultante dalla sua

espansione e sostituisce il

• al “return address” l’indirizzo dell’amministratore della lista (owner), in modo che successivi messaggi di notifica vadano all’amministratore della lista e non al mittente “message originator” del messaggio.

• Il messaggio è spedito a ciascun destinatario.


51


Posta Elettronica


• Gestione alias:– Per ogni mailbox può essere aggiunto un numero indefinito di alias:

direttore@dominio-istituto segreteria@dominio-istituto

– Si possono creare alias a destinazione multipla. Esempio:

segreteria@dominio-istituto alias di:Maria.Rossi@dominio-istituto , [email protected] ….


52


Posta Elettronica


• Gestione della lista di distribuzione d’Istituto dist@dominio-istituto– Creazione come lista moderata o non moderata

– Definizione owner della lista

– Controllo su massima dimensione messaggi

– Estrazione automatica e salvataggio attachment per accesso via HTTP

– Controllo via web: tutti gli indirizzi (ufficiali e alias) possono essere automaticamente inseriti/rimossi dalla mailing list di istituto: dist@dominio-istituto tramite un semplice click

– Controllo totale da parte dell’owner via messaggi e-mail inviati a: dist-request@dominio-istituto


53


Posta Elettronica


• Controlli relativi al traffico e-mail per dominio– attivazione/disattivazione antivirus

– attivazione/disattivazione controlli su Relay Blocking List (RBL)

• Prossima release – controllo definizione indirizzo postmaster@dominio

– gestione filtri SIEVE

– gestione liste di distribuzione

– attivazione/disattivazione controlli su Relay Blocking List (RBL) per singolo utente.


54


Posta Elettronica

• Accesso a demo MailboxManager

http://mail.iat.cnr.it:8080/mailboxmanager/demo

Consiglio Nazionale delle Ricerche Posta...

Documents

Transcript of Consiglio Nazionale delle Ricerche Posta...