Hosting: posta elettronica e record MX, cosa accade dopo l'invio #TipOfTheDay

13
Hosting: posta elettronica e record MX, cosa accade dopo l’invio

Transcript of Hosting: posta elettronica e record MX, cosa accade dopo l'invio #TipOfTheDay

Hosting: posta elettronica e record MX,

cosa accade dopo l’invio

Cosa accade quando inviamo

la nostra posta elettronica?

E quando non funziona?

Le risposte in un viaggio che segue le email

dal mittente al destinatario

#e-Commerce

Contenuti a cura di HostingTalk

A disposizione, esistono pacchetti hosting completi di servizi di posta elettronica:

illimitate caselle di posta da 1 GB, un numero variabile da 10 a 30 GigaMail

da 5GB e tanti altri servizi inclusi (come la ricezione POP3/IMAP e via discorrendo).

Scegliere un buon hosting, significa anche saper valutare un buon servizio di posta elettronica e, soprattutto, capire cosa accade quando gli altri netizen inviano

a un nostro indirizzo email una missiva elettronica. Solo con la comprensione

approfondita dei meccanismi che regolano la posta elettronica,

c’è l’opportunità di una libera scelta e la capacità di comprendere

perché è importante affidarsi a provider di comprovata esperienza.

Il viaggio di un’email comincia dopo che l’utente ha premuto il pulsante Invio

sulla finestra del suo client di composizione, sia esso un software residente

sul proprio computer o una schermata browser di un servizio webmail.

Nel momento stesso in cui si materializza con un clic il desiderio di invio dell’email

appena composta, entra in gioco il Mail User Agent (MUA),

in parole povere,

il client email che si sta utilizzando per l’invio, che contatta il proprio server

di competenza via SMTP per effettuare il trasferimento del messaggio

dal client verso il server del provider del mittente.

Più esattamente, il messaggio è inviato al server di posta elettronica incaricato

del trasporto (detto MTA per Mail Transport Agent),

fino all’MTA del destinatario che comunica, infine, con il Mail Delivery Agent.

Se il destinatario viene individuato

nella lista di uno dei server di posta elettronica incontrati viene interrotto

il trasferimento e l’MTA passa il messaggio all’MDA.

In caso contrario, l’MTA continua a trasferire il messaggio verso un altro server

di posta elettronica dove l’MTA condurrà il medesimo sondaggio sull’eventuale

presenza in lista del destinatario.

In pratica, il Mail Delivery Agent

(a volte indicato anche esso come Mail Transfer Agent,

anche se non è detto che in alcuni sistemi le due funzioni coincidano)

e l’MTA sono come dei postini che smistano la posta elettronica,

leggendo le informazioni contenute sulla busta della missiva appena inviata

(in gergo tecnico l’header dell’email) e decidendo come la missiva

deve proseguire il suo percorso.

Alla base di tutti i trasferimenti server fra il mittente e il destinatario

c’è il protocollo chiamato SMTP.

SMTP è un acronimo per Simple Mail Transfer Protocol e rappresenta

il modo più semplice che esiste per trasferire un messaggio di posta elettronica

da un server mittente verso il server ricevente.

In pratica, l’SMTP è un protocollo di trasporto basato sul TCP/IP che

permette il trasferimento dei soli messaggi testuali verso uno o più destinatari

del messaggio, i quali vengono verificati e contattati sui rispettivi

server di posta elettronica per permettere alla missiva di giungere a destinazione.

La verifica sui destinatari della missiva e il successivo trasferimento via SMTP

avviene a patto di individuare sulla Rete il server di posta elettronica

corrispondente al nome a dominio dell’indirizzo email del destinatario.

Come in ogni caso in cui ci sia necessità di tradurre un nome a dominio

nel corrispondente indirizzo IP che indica il server su cui viene ospitato,

anche in questa situazione a dare una mano sono i record DNS e,

nello specifico, il record MX.

Il record MX o Mail eXchanger record è una risorsa del sistema DNS che permette di specificare

al server SMTP inviante dove andare a pescare il mail server autorizzato alla ricezione dei

messaggi di posta elettronica per conto del dominio di destinazione.

In pratica, il protocollo SMTP interroga i DNS per individuare il server mail

con cui dialogare e con cui scambiarsi il messaggio che deve transitare

dal mittente al ricevente.

In questo modo, il nome a dominio del destinatario presentato dopo la chiocciola

(del [email protected]) viene tradotto nell’indirizzo IP del server email

pronto a “chiacchierare” con il server che vuole inviargli la mail.

Un record MX è di questo tipo:

esempio.it. 3600 MX 0 mail.esempio.it.

Con questa configurazione, quando il protocollo SMTP dell’MTA del mittente

interroga i DNS, trova che per tutti gli utenti attestati sul dominio esempio.it

(tipo [email protected], [email protected], [email protected], ecc.),

il server di posta elettronica autorizzato alla ricezione

si trova all’indirizzo mail.esempio.it.

Questo indirizzo viene poi risolto nel corrispondente indirizzo IP

attraverso un altro record DNS che può essere di tipo CNAME o A.

Continuando l’esempio precedente, il corrispondente record A sarà:

mail 3600 A 62.123.234.244

dove 62.123.234.244 è l’indirizzo IP del server da contattare.

Se ci si vuole dilettare a interrogare e scoprire i server

del proprio dominio e i corrispondenti indirizzi IP,

è possibile ricorrere allo

strumento online MXToolBox.

In entrambi i record di esempio, il secondo numero corrisponde al TTL (Time-To-Live),

ossia il tempo espresso in secondi (3600 secondi = 1 ora), per cui il record può essere

tenuto in cache dagli altri server DNS (e client) prima di effettuare una nuova interrogazione.

Nel caso del record MX, il secondo numero indica il livello di priorità.

Nell’esempio specifico, il livello di priorità potrebbe anche non essere specificato, ma può accadere (anzi, dovrebbe essere buona norma!) che per un medesimo dominio vengano configurati diversi record MX con diversi server di posta elettronica

pronti a processare le missive in ingresso.

Una configurazione

tipica potrebbe

essere questa:

In una condizione del genere, il secondo numero di ogni record specifica

la priorità del server di posta elettronica con cui il protocollo SMTP dell’MTA deve comunicare.

In questo modo, se la comunicazione con il primo server (priorità 0) dovesse fallire per qualsiasi motivo (server già impegnato, fuori uso, ecc.),

il protocollo SMTP del mittente prova a stabilire una connessione con il secondo server (priorità 10) e poi con il terzo (priorità 20) e via discorrendo.

Nell’esempio, l’ordine dei server interrogati sarebbe:

Una configurazione di questo tipo garantisce che il messaggio di posta elettronica giunga sempre a destinazione,

in quanto anche se uno o più server di posta elettronica dovessero essere irraggiungibili, dovrebbe

essercene sempre uno disponibile ad accogliere la richiesta del mittente.

Anche il servizio di gestione DNS a disposizione, ad esempio, permette di specificare dei record MX esterni

per un determinato dominio e, nello specifico, fino a 7 record differenti,

per una configurazione affidabile e resiliente.

Al di là di questo, anche nel caso di una configurazione meno ridondante o con un unico server, qualora il server di destinazione risulti offline, l’MTA del mittente è, di norma, configurato per riprovare il re-invio del messaggio di posta ogni 4 ore, per i successivi 5 o 7 giorni.

In questo caso, entra in gioco un altro fattore: la ridondanza dei name server per l’accesso ai DNS e la risoluzione dei nomi a dominio.

Nello specifico:

• se il server del provider hosting è in down, ma i suoi name server sono online,

il sistema di invio della missiva elettronica, cerca il dominio,

lo risolve nel corrispondente indirizzo IP, prova a contattarlo e,

non essendo disponibile, mette il messaggio in coda per un successivo tentativo.

Qualora invece

• il provider hosting ha in down tanto il server di posta, quanto i name server,

il sistema di invio cerca il dominio, non lo trova e conclude che il

dominio non esiste, per cui re-invia il messaggio al mittente

senza ulteriori tentativi di invio.

Questi ultimi esempi fanno comprendere come sia importante affidarsi

sempre a provider competenti, con esperienza e con le infrastruttura ridondanti e

delocalizzate, in modo che un guasto a un server di posta elettronica

non comprometta la risolvibilità dei nomi a dominio,

come invece accade con alcune aziende “improvvisate” presenti sul mercato.

Con questa considerazione,

si conclude il focus sul viaggio di un messaggio di posta elettronica,

anche se in realtà, il discorso potrebbe essere reso più complicato dall’analisi

sull’invio degli allegati

(come si diceva il protocollo SMTP supporta solo

i messaggi testuali ed è per questo che è stata introdotto l’estensione MIME),

sui sistemi di firma (SPF, DKIM, ecc.)

o sugli aspetti crittografici (PGP, S/MIME e STARTTLS).