Capita a volte che nell’invio di una mail si abbia come risultato il mancato invio o la mancata ricezione. del messaggio. Capire in realtà quale dei due casi ci troviamo di fronte non è facile appunto, perchè in entrambi i casi stabilire se ci troviamo di fronte ad un mancato invio o ad una mancata ricezione è difficile e richiede indagini a livello tecnico non sempre possibili da parte dell’utilizzatore finale.
Di chi sarà la colpa dunque ? Del mittente o del destinatario ?
Va premesso che l’invio di una mail e la sua ricezione comporta una serie di operazioni “dietro le quinte” assolutamente non banali che determinano in modo indiscutibile l’esito positivo o meno dell’invio e della ricezione.
Sebbene l’invio di una mail sia alla portata di tutti è anche vero che esistono migliaia di mailserver ognuno col proprio software e ognuno con la propria configurazione che a volte possono non comunicare tra loro per problemi di natura tecnica e di errata configurazione.
Ipotizziamo uno scenario reale
Quando un utente con email tizio@tizio.it ad esempio prova ad inviare una mail a caio@caio.it, ecco cosa succede dietro le quinte :
- Il client di posta di tizio si connette al mailserver delegato a gestire la posta per il dominio tizio.it ad esempio mail.tizio.it
- A sua volta viene fatta una richiesta al mailserver autoritario che è in ascolto sulla porta 25 e chiesto di inviare una mail al destinatario caio@caio.it. Questa richiesta viene fatta seguendo una sintassi per il protocollo SMTP in cui brevemente vengono descritti, mittente (MAIL FROM), destinatario (RCPT TO), oggetto (SUBJECT) e il corpo della mail (DATA).
- Una volta terminata la trasmissione della mail dal client di posta al mailserver, il mailserver (che altro non è che un programma server che rimane in ascolto sulla porta 25, adibito alla ricezione e alla consegna delle mail) fa una query al DNS cercando di ottenere il record MX (Mail eXchanger) per il dominio in oggetto.
- Il DNS per il dominio caio.it risponderà ad esempio che il mail server autoritativo per il dominio caio.it sarà mail.caio.it
- Il mailserver mail.tizio.it allora si collegherà alla porta 25 del mailserver mail.caio.it instaurando una connessione di tipo TCP e girerà la mail che aveva in coda (queue) speditagli dal client di posta (outlook o thunderbird ad esempio) dell’utente tizio@tizio.it
- A questo punto il mailserver del destinatario mail.caio.it avrà in coda la mail destinata ad un utente del suo dominio (caio@caio.it) e dovrà in qualche modo consegnarla in un file dentro una cartella del server, in formato normalmente Maildir o Mailbox.
- A quel punto il ricevente si collegherà tramite il suo client di posta ad un server di posta in entrata pop3 o imap che serve alla ricezione del messaggio precedentemente consegnato dal mailserver.
Questo è quello che avviene in un regime normale, ovvero senza controlli specifici antivirus e antispam.
Già fino ad ora per far funzionare tutto questo meccanismo si ha bisogno dei seguenti requisiti :
- 2 mailserver pienamente funzionanti , uno per il mittente uno per il destinatario
- Le informazioni host ed IP sui mailserver siano pubblicati nelle voci DNS (dette zone) dei domini in questione.
- Effettuare una query DNS implica il fatto di avere un server DNS funzionante con le corrette informazioni pubblicate, in particolar modo il record MX
Configurazioni avanzate con controlli sul mittente e sul contenuto.
In una configurazione avanzata, si ha a che fare inoltre con controlli aggiuntivi, come ad esempio :
Greylisting : si rifiuta di accettare la mail del mittente per alcuni minuti. Nel caso di un mailserver reale e non spammer, sarà rinviata. Nel caso di spam bot spesso non viene rinviata per cui si inizia a fare una selezione di posta buona e posta cattiva. Ciò comporta un ritardo di circa 10, 15 minuti (ma anche più) del primo messaggio di un nuovo mittente per il nuovo mese.
DNSBL : si verifica se un IP del mittente risulti pubblicato in liste mondiali di Spammer tramite richieste di tipo UDP (simili a quelle usate per le query DNS). Se presente, il messaggio viene rifiutato e il mailserver mittente lo rispedirà al mittente, specificando il motivo del rifiuto di consegna.
SPF : è un sistema di validazione delle email progettato per individuare tentativi di email spoofing. Il sistema offre agli amministratori di un dominio e-mail un meccanismo che consente di definire gli host autorizzati a spedire messaggi di quel dominio, consentendo a chi li riceve di controllarne la validità. La lista degli host autorizzati ad inviare email per un determinato dominio è pubblicata nel Domain Name System (DNS) per quel dominio, sotto forma di record TXT appositamente formattati. Il phishing, e talvolta anche lo spam, utilizzano indirizzi del mittente falsi, cosicché la pubblicazione e la verifica di record SPF può essere considerata in parte una tecnica anti-spam.
DKIM : DomainKeys Identified Mail (DKIM) è un metodo di autenticazione delle email, realizzato per prevenire lo spoofing. Consente, a chi riceve un’email, di verificare la provenienza del messaggio, in modo da accertarsi dell’autenticità del mittente. Il DKIM è utilizzato per contrastare il phishing e lo spam delle email.
In termini tecnici, il DKIM consente a un dominio di associare il proprio nome a un’email mediante l’apposizione di una firma digitale. La verifica viene eseguita utilizzando la chiave pubblica del firmatario pubblicata nel DNS del dominio. La firma garantisce che il messaggio dell’email (inclusi gli allegati) non sia stato modificato dal momento in cui è stata apposta la firma. Di solito, le firme DKIM non sono visibili agli utenti poiché sono apposte o verificate dai service provider (SP). Per questo motivo, il DKIM differisce dalla crittografia end-to-end, la quale non prevede interazioni di terze parti.
Antispam/Antivirus : in base al contenuto, parole chiave ed allegati, si darà un punteggio al messaggio. Superato un certo punteggio (normalmente 5) il messaggio sarà etichettato come SPAM e sarà consegnato o nella cartella SPAM o nella posta normale con l’oggetto del messaggio modificato in qualcosa del tipo [SPAM]Oggetto del messaggio , oppure ***SPAM***Oggetto del messaggio.
In questo caso affinchè il messaggio sia ricevuto dall’indirizzo del destintario il mittente deve accertarsi che l’ip del suo mailserver non sia elencato come fonte di SPAM nelle DNSBL, deve avere l’accortezza di seguire delle regole standard per la scrittura di una mail come ad esempio scrivere l’oggetto, inserire un testo nel corpo del messaggio, evitare l’invio di file quasi sempre vietati come gli eseguibili (.exe, .com, .pif, .bat, ecc..).
Va inoltre messo nero su bianco un concetto : quando la mail non arriva o non si riceve la colpa può essere nostra come può essere dell’interlocutore.
Se un nostro fornitore o cliente, ci invia una mail da un indirizzo elencato in DNSBL, la colpa è sua che non invia rispettando le regole, e non nostra che rifiutiamo automaticamente il messaggio perchè appunto è SPAM.
Inoltre va detto che la mail non è uno strumento di comunicazione in tempo reale, la consegna non è garantita e che ogni uso diverso da quella per cui è stata progettata è un uso errato.
Ogni messaggio di errore che ritorna indietro ha un codice di identificazione, nonchè una descrizione del problema.
Leggendo queste informazioni, possiamo sapere senza ombra di dubbio, se il problema siamo noi o l’altro interlocutore.
Basterebbe avere la voglia e prendersi la briga di leggere questi errori per evitare di brancolare nel buio evitando inopportune comunicazioni all’helpdesk aziendale.
