Posta Elettronica Internet

La posta elettronica nell'architettura TCP/IP

Politecnico di Torino Dip. Automatica e Informatica Applicazioni di rete

 indirizzi logici (applicativi)  per identificare gli utenti del servizio applicativo  protocollo applicativo (sopra TCP/UDP e IP)  L7, ossia tra i due end-point applicativi  formato dati  dati significativi per l'applicazione  per ciascun punto occorre definire:  lessico = i caratteri ammissibili  sintassi = composizione di richieste e risposte  semantica (parziale) = significato

 l’indirizzo RFC-822 è:

casella-postale @ dominio-postale

 la casella postale può essere:  un nome di utente (es. login)  un identificativo virtuale (es. "casella funzionale")  il dominio postale può essere:  un nome (FQDN) o indirizzo del server di posta  un dominio di posta virtuale

 tre possibilità:  indirizzo  commento < indirizzo >  indirizzo ( commento )  esempio:  [email protected]  Antonio Lioy  [email protected] (Antonio Lioy)  occhio alle fregature!  "Prof. Antonio Lioy "

 il dominio postale è un concetto logico ma per trasmettere la posta con SMTP occorre identificare un host fisico con un indirizzo IP preciso  il dominio è virtuale ed ha quindi un mail exchanger?  nslookup -q=MX dominio-postale  posta inviata ad uno degli MX host (contattati in ordine di preferenza)  se non esiste un MX, il dominio coincide forse con un host?  nslookup -q=A dominio-postale  posta inviata all’host  se non esiste né MX né A allora è impossibile consegnare la posta al destinatario (dominio di posta errato)

nslookup –q=MX polito.it. Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: polito.it mail exchanger = 10 mx.polito.it. nslookup –q=A polito.it. Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: *** Can't find polito.it: No answer

© A.Lioy (Politecnico di Torino, 2013-2020) 6 Dai domini postali agli host: esempio nslookup –q=MX cisco.com. Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: cisco.com mail exchanger = 30 aer-mx-01.cisco.com. cisco.com mail exchanger = 20 rcdn-mx-01.cisco.com. cisco.com mail exchanger = 10 alln-mx-01.cisco.com. nslookup –q=A cisco.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: cisco.com Address: 72.163.4.185 © A.Lioy (Politecnico di Torino, 2013-2020) 7 MHS (Message Handling System)

MTA MTA MTA chain MSA MSA

MS MS

MUA MUA

 MUA (Message User Agent)  MSA (Message Submission Agent)  MTA (Message Transfer Agent)  MS (Message Store)

 RFC-5598 "Internet Mail Architecture"  in alcuni casi, oltre a MUA, MSA, MTA e MS, si distinguono altri server lato ricevente:  MDA (Mail Delivery Agent)  l'ultimo MTA della catena che ha l'incarico di consegnare la posta al MS  MRA (Mail Retrieval Agent)  elemento incaricato di prelevare la posta dal MS e metterla in un deposito locale accessibile al MUA  in pratica un MUA senza interfaccia utente, da usarsi con un MUA incapace di prelevare la posta dal MS

SMTP Mailserver SMTP MTA ... ( MSA )

MUA (es. Thunderbird, Outlook Express)

Post Office ... MTA POP, IMAP ( MS ) SMTP

Mailserver SMTP MTA ... ( MSA )

SMTP HTTP web server HTML HTTP virtual engine MUA web browser POP / IMAP

Post Office ... MTA ( MS ) SMTP

 SMTP (Simple Mail Transfer Protocol)  25/tcp (MTA)  587/tcp (MSA)  POP (Post Office Protocol)  110/tcp  IMAP (Internet Message Access Protocol)  143/tcp  sono protocolli di basso livello (si occupano solo di trasportare i messaggi, non entrano in merito al loro contenuto)

 “RFC-822”  formato di un messaggio (header + body)  body di puro testo  contenuti non testuali (es. immagini) devono essere trasformati in testo (es. uuencode, binhex)  MIME  estensione multimediale di RFC-822  body può includere anche dati non di testo  trasformati automaticamente in testo da MIME  alcuni campi aggiuntivi nell’header

 RFC-5322 (ex RFC-822)  solo caratteri US-ASCII a 7 bit  righe terminate da  messaggi composti da header + body  header  parole chiave a inizio riga  righe di continuazione iniziano con uno spazio  body  separato dall’header da una riga vuota  contiene il messaggio

 From: mittente (logico) Sender: mittente (operativo)  Organization: organizzazione del mittente  To: destinatario  Subject: argomento  Date: data e ora di spedizione  Received: passaggi intermedi  Message-Id: ID di spedizione  CC: in copia a Bcc: in copia (nascosta) a  Return-Receipt-To: ricevuta di ritorno a

 collegata all’header Return-Receipt-To:  non standard e deprecata ma usata da molti MUA  risposta dipende da MS e/o MUA del destinatario:  può non offrirla  può offrirla alla ricezione o alla lettura  lo standard preferisce:  RCPT TO con DSN (Delivery Status Notification, che però copre solo la consegna ma non la lettura)  l'header MDN (Message Disposition Notification, che però può essere ignorato dal MUA)

 minimo due MTA  concettualmente MSA e MS sono diversi dagli MTA  un MTA in uscita dalla rete del mittente (con tanti MSA alle spalle per distribuire il carico in ingresso)  un MTA in ingresso nella rete del destinatario (con tanti MS per distribuire il carico di memorizzazione e lettura dei messaggi).  in passato molti altri MTA intermedi  rete non tutta TCP/IP e/o posta non RFC-822  MTA = gateway (traduzione protocollo di rete e/o formato di posta)  guardare i "Received:" per vedere gli MTA attuali:  "from" e "by" indicano MTA mittente e ricevente di un passo

Received: from [130.192.180.16] (HELO antispam.polito.it) by polito.it (CommuniGate Pro SMTP 6.2.5) for [email protected]; Fri, 14 Dec 2018 18:11:50 +0100 Received: from mail-it1-f177.google.com [209.85.166.177] by antispam.polito.it for ; Fri, 14 Dec 2018 18:11:48 +0100 Received: by mail-it1-f177.google.com for ; Fri, 14 Dec 2018 09:11:48 -0800 (PST) Received: from 131-193-184-17.east.wireless.uic.edu. [131.193.184.17] by smtp.gmail.com; Fri, 14 Dec 2018 09:11:37 -0800 (PST)

 devono essere codificati come testo tramite appositi programmi:  uuencode / uudecode in Unix  binhex in MacOS  esempio:  uuencode photo.gif photo.gif | mail –s "my pic" ucl!ucb!john  problema poi affrontato e risolto in modo più automatico, completo e strutturato dal formato MIME

 specifica base in RFC-5321 (ex RFC-821)  protocollo ASCII a 7 bit  il MSB del byte può essere forzato a zero o usato per la parità (semplice controllo di errore)  alfabeto US-ASCII  comandi case-insensitive  righe terminate da

 HELO hostname identifica l’host mittente  MAIL FROM: return-path identifica il mittente  RCPT TO: forward-path identifica il destinatario  DATA tutte le righe successive contengono un messaggio RFC-822 sino alla riga (esclusa) che contiene “.”  QUIT termine della trasmissione SMTP

 ogni risposta inizia con un codice di stato numerico a tre cifre XYZ  la prima cifra (X) fornisce il major status dell’azione richiesta:  X=1 : positive preliminary  X=2 : positive completion  X=3 : positive intermediate  X=4 : transient negative completion  X=5 : permanent negative completion

 la seconda cifra (Y) indica la tipologia  Y=0 : syntax  Y=1 : information  Y=2 : connections  Y=5 : mail system  la terza cifra (Z) fornisce un modo per distinguere codici di risposta appartenenti alla stessa classe  risposta su più righe se lo stato è XYZ– (l’ultima riga ha solo XYZ)

 mailbox ≤ 64 caratteri  domain ≤ 64 caratteri  reverse / forward-path ≤ 256 caratteri  comando / risposta ≤ 512 caratteri  linea di testo ≤ 1000 caratteri (MUST)  linea di testo ≤ 80 caratteri (SHOULD) molti MTA forzano un CRLF dopo 78 caratteri  numero di destinatari ≤ 100

© A.Lioy (Politecnico di Torino, 2013-2020) 33 Un esempio SMTP / RFC-822 telnet duke.colorado.edu 25 Trying ..... Connected to duke.colorado.edu Escape character is ‘^]’ 220 duke.colorado.edu ... HELO leonardo.polito.it 250 Hello leonardo.polito.it ... Nice to meet you! MAIL FROM: [email protected] 250 cat ... Sender ok RCPT TO: [email protected] 250 franz ... Recipient ok DATA 354 Enter mail, end with “.” on a line by itself © A.Lioy (Politecnico di Torino, 2013-2020) 34 From: [email protected] (Antonio Lioy) To: [email protected] Subject: vacanze Ciao Francesco, ti rinnovo l’invito a venirmi a trovare nelle tue prossime vacanze in Italia. Fammi sapere quando arrivi. Antonio . 250 Ok QUIT 221 duke.colorado.edu closing connection connection closed by foreign host

 Extended SMTP, definito in RFC-1869 e quindi incorporato (con SMTP) in RFC-5321  non cambia il protocollo base ed il canale  i client ESMTP devono presentarsi con: EHLO hostname  se il server ricevente parla ESMTP, deve dichiarare le estensioni che supporta, una per riga, nella sua risposta all’EHLO

 8BITMIME  (RFC-1652) nel corpo del comando DATA può ricevere dati codificati su 8 bit  rischioso! gli MTA intermedi potrebbero non supportare questa opzione  SIZE dimensione MAIL FROM: address SIZE=dimensione  (RFC-1870) dichiara la massima dimensione accettabile dal server o la dimensione del messaggio da inviare  PIPELINING  (RFC-1854) invio di più comandi senza attendere risposta per ognuno di essi (eccezione: quelli che fanno cambiare stato)

 estende il comando RCPT con:  NOTIFY=notify-list valori possibili: NEVER, SUCCESS, FAILURE, DELAY  ORCPT=original-recipient specifica il destinatario originale  estende il comando MAIL con:  RET=returned-message valori possibili: FULL, HDRS  ENVID=sender-id identificativo creato dal mittente

 mailer ESMTP senza estensioni:

220 mail.polito.it - SMTP service ready EHLO mailer.x.com 250 Hello mailer.x.com - nice to meet you!

 mailer ESMTP con estensioni: 220 mail.polito.it - SMTP service ready EHLO mailer.x.com 250-Hello mailer.x.com - nice to meet you! 250-SIZE 26214400 250 8BITMIME

 il mailer non conosce il protocollo ESMTP:

220 mail.polito.it - SMTP service ready EHLO mailer.x.com 500 Command not recognized: EHLO

 estensione di ESMTP definita in RFC-4954  comando AUTH + opzioni di MAIL FROM  per autenticare un client …  … prima di accettarne i messaggi!!!  utile contro lo spamming:  dopo il comando EHLO il server invia i meccanismi di autenticazione supportati  il client ne sceglie uno  viene eseguito il protocollo di autenticazione  se l'autenticazione ha successo, il server accetta i comandi SMTP del client  se l’autenticazione fallisce, il canale viene immediatamente chiuso

 il mailer non conosce (o non accetta) la modalità di autenticazione proposta dal client:

220 example.polito.it - SMTP service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH PLAIN 504 Unrecognized authentication type

220 example.polito.it - SMTP service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH LOGIN 334 VXNlcm5hbWU6 Username: bGlveQ== lioy 334 UGFzc3dvcmQ6 Password: YW50b25pbw== antonio 235 authenticated

 sintassi (RFC-2595): AUTH PLAIN id_pwdBASE64  id_pwd è definito come: [ authorize_id ] \0 authentication_id \0 pwd

220 example.polito.it - SMTP service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN PLAIN AUTH PLAIN bGlveQBsaW95AGFudG9uaW8=

235 authenticated lioy \0 lioy \0 antonio

 una volta era diffuso anche POP-2 (109/tcp) oggi è usato solo POP-3 (RFC-1725, 110/tcp)  realizza il collegamento tra MUA e MS, quindi serve solo a leggere la posta dall’ufficio postale  talvolta usato (impropriamente) in assenza di SMTP-auth per autenticare l’utente prima di spedire posta (es. Pegasus Mail)

 protocollo ASCII (ma è 8-bit clean)  comandi case-insensitive  righe terminate da  codici di errore del server +OK -ERR  risposte multi-linea terminate da una riga contenente solo: .  separatore: un solo carattere di spazio

 QUIT  STAT +OK nmsg totalmsgsize  LIST [ msgid ] msgid msgsize  RETR msgid  DELE msgid  NOOP  RSET

 USER mailbox PASS password  APOP mailbox digest  AUTH mechanism (KERBEROS_V4, GSSAPI, SKEY)  TOP msgid nline  UIDL [ msgid ] msgid umsgid fornisce stringhe di identificazione univoche per tutte le sessioni

© A.Lioy (Politecnico di Torino, 2013-2020) 49 Un esempio POP-3 telnet pop.polito.it 110 +OK POP3 server ready <[email protected]> USER lioy +OK password required for lioy PASS antonio +OK lioy mailbox locked and ready STAT +OK 2 320 LIST +OK 2 messages (320 octets) 1 120 2 200

RETR 1 +OK 120 octets ( messaggio n. 1 ) . DELE 1 +OK message 1 deleted RETR 2 +OK 200 octets ( messaggio n.2 ) . QUIT +OK POP3 server signing off

 Internet Message Access Protocol  varie versioni, la più recente e diffusa è IMAP4  porta 143/tcp  vantaggi rispetto a POP:  possibile modo connesso (canale sempre aperto)  accesso simultaneo da più client  fetch parziale (es. solo header) ed accesso a singole parti MIME  stato dei messaggi (es. letto, cancellato, inoltrato)  uso di cartelle (folder) per organizzare i messaggi  ricerche lato server (meno carico su rete e client)