Posta elettronica C Francesco Gennai Marina Buzzi iat

Slides:



Advertisements
Presentazioni simili
Informazioni di base sul funzionamento
Advertisements

VIA GIULIO RATTI, CREMONA – Tel. 0372/27524
Cos’è la posta elettronica
3 ottobre 2000Consiglio Nazionale delle Ricerche Progetto Biblio MIME 1 Consiglio Nazionale delle Ricerche Area di Ricerca di Bologna Istituto per le Applicazioni.
Gli ipertesti del World Wide Web Funzionamento e tecniche di realizzazione a cura di Loris Tissìno (
CORSO DI SICUREZZA SU RETI II PROF. A. DE SANTIS ANNO 2006/07 Informatica granata Gruppo 2 ISP Gruppo 3 ISP.
Tecnologie. Reti locati e reti globali Reti locali (LAN, Local Area Networks) –Nodi su aree limitate (ufficio, piano, dipartimento) Reti globali (reti.
Modulo 5 - posta elettronica
Elaborazione del Book Informatico
Configurare Outlook Express
IL NOSTRO LABORATORIO Di INFORMATICA. Nel nostro laboratorio abbiamo 24 postazioni con dei computer di tipo Desktop con queste caratteristiche: Sistema.
IL NOSTRO LABORATORIO Di INFORMATICA. Presentazione Nel nostro laboratorio abbiamo 24 postazioni con dei computer di tipo Desktop con queste caratteristiche:
Organizzazione di una rete Windows 2003
ING. CARLO MANFUCCI COMUNE DI GROSSETO
Progetto MODA-ML Biella, 30 novembre 2001 Sistema di interscambio messaggi Luca Mainetti HOC - Hypermedia Open Center Dipartimento di Elettronica e Informazione.
Reti di Comunicazione Reti Locali (LAN - Local Area Network) Reti Geografiche (WAN - Wide Area Network) Reti Metropolitane (MAN - Metropolitan Area.
Posta Elettronica in Internet
2-1 Trasferimento di file: ftp Crediti Parte delle slide seguenti sono adattate dalla versione originale di J.F Kurose and K.W. Ross (© All Rights.
Secure Shell Giulia Carboni
Modello del sistema di posta Elettronica
Architettura del World Wide Web
Posta elettronica ( ) chiocciola" comunemente letta at Identificativo dellutente Identificativo del computer centrale sul quale risiede.
Corso di Informatica Corso di Laurea in Conservazione e Restauro dei Beni Culturali Gianluca Torta Dipartimento di Informatica Tel: Mail:
Marco Panella La posta elettronica Marco Panella
Bologna, 24 novembre 2000 Unsolicited Bulk (UBE) (spamming) Francesco Gennai IAT - CNR
C Consiglio Nazionale delle Ricerche DNS e Posta Elettronica: evoluzione dei servizi Francesco Gennai, Marina Buzzi, Laura Abba Francesco Gennai, Marina.
23 novembre 2000IAT-CNR Progetto Biblio MIME 1 Consiglio Nazionale delle Ricerche Area di Ricerca di Bologna Istituto per le Applicazioni Telematiche di.
C Consiglio Nazionale delle Ricerche DNS e Posta Elettronica: evoluzione dei servizi Marina Buzzi Marina Buzzi Istituto per le Applicazioni Telematiche.
IL LIVELLO APPLICAZIONI:
Posta elettronica : per iniziare : per iniziare Primi passi con la posta elettronica Primi passi con la posta elettronica
4 Cosa è una rete? ã Punto di vista logico: sistema di dati ed utenti distribuito ã Punto di vista fisico: insieme di hardware, collegamenti, e protocolli.
Gruppo Directory Services Rapporto dell'attivita' svolta - Marzo 2000.
Corso di Informatica per Giurisprudenza Lezione 7
Modulo 7 – reti informatiche u.d. 2 (syllabus – )
Acer Mnemonick presentazione commerciale
Guida IIS 6 A cura di Nicola Del Re.
Server Web in una rete Windows Sommario Meccanismi di accesso remoto Meccanismi di accesso remoto Introduzione ai Server Web Introduzione ai Server.
Modulo 3 – U.D. 3 – Lez. 1 Ernesto Damiani - Sistemi di elaborazione dell'informazione.
Sistemi di elaborazione dellinformazione Modulo 3 -Protocolli applicativi Unità didattica 3 -Protocolli di posta elettronica Ernesto Damiani Lezione 2.
SERVER DI POSTA ELETTRONICA INTRANET
_________________________________________________________________ Trade System Srl - Viale Gran Sasso Corropoli (TE) Tel: Fax:
Configurazione di una rete Windows
Reti di Calcolatori ed Internet Fabio Massimo Zanzotto.
L’architettura a strati
IPSec Fabrizio Grossi.
prof.ssa Giulia Quaglino
FTP File Transfer Protocol
Creato da Riccardo Nuzzone
Procedure operative di sicurezza di un sistema informatizzato in un dipartimento servizi Corso aggiornamento ASUR10.
1 Storia di Internet Internet non è un’invenzione degli anni ’90….. Nata dagli studi di un’agenzia detta ARPA (Advanced Research Projects Agency) Internet.
InternetInternet Sede: Salvo D’acquisto 2010/2011 Docente: Vito Monno.
1 I protocolli di . 2 Posta elettronica Tre componenti: Tre componenti: user agentsuser agents mail serversmail servers Simple mail transfer protocol.
Sistemi di elaborazione dell’informazione Modulo 3 - Protocolli applicativi Unità didattica 2 - Telnet, FTP e altri Ernesto Damiani Lezione 2 – Da FTP.
Lucia Melotti 1/14 Bologna, 7 luglio 2004 Aspetti di sicurezza nello scambio di messaggi XML tra un partner ebXML ed un Web Service di Lucia Melotti Relatore:
INTRODUZIONE A INTERNET
Servizi Internet Claudia Raibulet
1 Certificati a chiave pubblica strutture dati che legano una chiave pubblica ad alcuni attributi di una persona sono firmati elettronicamente dall’ente.
Sistemi di elaborazione dell’informazione Modulo 3 -Protocolli applicativi Unità didattica 3 -Protocolli di posta elettronica Ernesto Damiani Lezione 3.
UNITA’ 04 Uso Sicuro del Web.
CORSO INTERNET la Posta elettronica
I FIREWALL. COSA SONO I FIREWALL? LAN MONDO ESTERNO UN FIREWALL E’ UN SISTEMA CHE SUPPORTA UNA POLITICA DI CONTROLLO DEGLI ACCESSI FRA DUE RETI (POLITICHE.
La posta elettronica. Posta elettronica Il servizio più usato nella comunicazione in Internet è quello della posta elettronica (o ) che consente.
Postecom B.U. CA e Sicurezza Offerta Sicurezza Scenario di servizi ed integrazioni di “Certificazione”
Applicazione Presentazione Sessione Trasporto Rete Data link Fisico OSI Processo / Applicazione Trasporto Rete- Internet Interfaccia di.
PPT- Postecert PEC – 05/2009 Postecert Posta Elettronica Certificata.
PEC La Posta Elettronica Certificata Ombretta Pinazza Gruppo Mailing Marzo 2008.
INTERNET E INTRANET Classe VA SIA. La Storia di INTERNET ’ – ARPANET 1969 – anno di nascita università Michigan - Wayne 1970 – – INTERNET.
Servizio posta Situazione al 27/09/2012 Marco De Rossi Marco Esposito Antonio Forte.
La gestione della rete e dei server. Lista delle attività  Organizzare la rete  Configurare i servizi di base  Creare gli utenti e i gruppi  Condividere.
Transcript della presentazione:

Posta elettronica C Francesco Gennai Marina Buzzi iat Consiglio Nazionale delle Ricerche iat Istituto per le Applicazioni Telematiche Francesco Gennai Marina Buzzi - IAT (Istituto per le Applicazioni Telematiche) http://www.iat.cnr.it - TERENA ( http://www.terena.org - ISOC (Internet SOCiety) http://www.isoc.org - Registration Authority Italiana www.nic.it Posta elettronica

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

MIME Multipurpose Internet Mail Extensions

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

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

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

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 La limitazione dei 7 bit e’ veramente critica. Due sono gli approcci: uno e’ quello di MIME che ha stabilito una codifica dei dati affinche’ tutto sia rappresentabile con ascii 7 bit. L’altro e’ quello della estenzione dello standard affinche’ siano supportati caratteri a 8-bit. Questo ovviamente comporta l’aggiornamento di tutto il software preesistente. Body multipart server per il trasoprto di dati multimediali, Per esempio una visualizzaaione di immagine in parallelo all’esecuzione di un brano musicale in un Multipart/parallel.

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)

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

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

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

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

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 Content-type: multipart/parallel; boundary=XXXsepara --XXXsepara Content-type: audio/basic Content-transfer-encoding: base64 ..... dati audio codificati in base64 Content-type: image/gif ... dati per immagine gif codificati in base64 --XXXsepara-- 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--

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

Alcune note sull’organizzazione di un servizio di posta elettronica

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

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

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)

Naming Centralizzato e Centralizzazione del servizio

Il servizio di posta elettronica: alcune riflessioni 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

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

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

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.

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

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 ?

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

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à

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

Autenticazione client/server nei protocolli “connection-based”

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)

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

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

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

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)

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)

messaggio da convertire MIME e MTA messaggio convertito messaggio da convertire cnvt 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

Header MIME (prima e dopo la conversione) i2pdf@mailsrv.cnuce.cnr.it Content-type: multipart/mixed; boundary=“x1234y” --x1234y Content-type: text/plain Ciao,..... Content-type: application/postscript %!PS-Adobe-1.0 %%Pages %%EndComments %%BeginProlog ............ . . . .. . . . . . . . . . . . . .. . ...... . .. ... . . .. .. .. . . . . ...... --x1234y-- Content-type: multipart/mixed; boundary=“x1234y” --x1234y Content-type: text/plain Ciao,..... 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--