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 mal configurazione.
Cerchiamo dunque di ipotizzare uno scenario.
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 cialis prices il fatto di avere un server DNS funzionante con le corrette informazioni pubblicate, in particolar modo il record MX
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.
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è a breve 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.
