Hoe een e-mail werkt en vooral waarom deze in spam terechtkomt

Hoe een e-mail werkt

en vooral omdat het in spam terecht komt

Aangezien het een complex onderwerp is dat zich leent voor uitgebreide technische discussies, probeer ik het voor het "normale" publiek begrijpelijk te maken. Laten we doen alsof we twee vrienden hebben die elkaar schrijven, de afzender A wordt genoemd ARENA en ontvanger B wordt gebeld BUGO.

Coso schrijft een e-mail aan Bugo. Wat gebeurt er achter de schermen?
Coso's Server A stuurt een e-mail naar Bugo's Server B.
In simpele termen, cosi@vattelapesca.it schrijft naar bugo@nonmissassare.com.

Alles oké voor jou. Waar is het probleem? Zo is het eigenlijk niet helemaal. Het gebeurt veel. Ik laat de details achterwege over hoe de e-mail wordt "verpakt" en verzonden in pakketten voor verschillende routes door het internetuniversum om weer in elkaar te worden gezet door de Bugo-mailserver, omdat het erg lang wordt en we zouden ontsporen.

Laten we teruggaan naar cosi@vattelapesca.it naar wie schrijft bugo@nonmissassare.com.

Coso krijgt geen reactie. Dagen gaan voorbij en krijg nog steeds geen reactie. Toch is het een belangrijke communicatie! Dus belt hij Bugo aan de telefoon en Bugo antwoordt dat hij de e-mail nooit heeft ontvangen!

Meestal belt Bugo dan zijn IT-manager of de hostingmanager en dan begint degene die de mailboxen en de mailserver levert te tieren: “Hier! Geef me mijn geld terug, dief! De e-mails werken niet!!! Ik krijg geen e-mails van cosi@vattelapesca.it.

Jullie hebben allemaal een beetje van dit probleem gehad. Het punt is dat toen alles eenmaal voorbij was, vandaag met de bestaande beveiligingsproblemen de dingen zijn veranderd, ook dankzij jullie die geweldige knoeiers zijn.

Wanneer Coso een e-mail naar Bugo stuurt, checkt de Bugo-mailserer terug, houdt van de zalm en volgt het omgekeerde pad van de ontvangen e-mail. En controleer een paar dingen:

Het eerste dat wordt gecontroleerd, is of de afzender echt is wie hij zegt dat hij is. Het lijkt misschien triviaal voor u, maar dat is het helemaal niet! Het feit dat je bent cosi@vattelapesca.it het betekent helemaal niets.

In feite controleert de Bugo-mailserver dat het IP-adres van de host van de afzender, d.w.z. "vattelapesca.com” komt in dit geval overeen met het IP-adres van de mailserver. Banaal? Nee! Het is vaak het eerste probleem dat men tegenkomt. Interne IT-managers van bedrijven maken vaak de simpele fout om de DNS-zone van het domein verkeerd te configureren en het IP-adres van de mailserver niet correct toe te wijzen. Dit is met name het geval als er meerdere verschillende domeinen op één server staan. In het geval van degenen die hostingdiensten verkopen door de server die ze beheren te partitioneren, hebben ze op dit punt vaak ongelijk. De grote providers pakken dit probleem systematisch aan en daarom komt het probleem bijna nooit voor. Maar in grote/middelgrote bedrijven, met IT-managers die niet helemaal op orde zijn, die hun eigen mailservers intern beheren, komt dit probleem vaak voor.

In feite slaat de Bugo-mailserver de e-mail op als spam omdat hij niet begrijpt wie de afzender eigenlijk is. In deze gevallen wordt zelfs de e-mail volledig verbrand en kan deze niet eens worden hersteld vanuit de spammap.

Laten we er in plaats daarvan voor zorgen dat de configuratie van de mailserver van de afzender correct is en dat de Bugo-mailserver, door het omgekeerde te doen, bevestigt dat het IP-adres correct is en dat de afzender dus is wie hij zegt dat hij is.

Maar de post komt nog steeds niet aan op de plaats van bestemming. Wederom Bugo's telefoontje naar zijn IT-manager enz… De IT-manager controleert en verifieert dat de SPF-markering ontbreekt. Au! Wat is de SPF-markering?

Sender Policy Framework (SPF) is een e-mailvalidatiesysteem dat is ontworpen om pogingen tot e-mailspoofing te detecteren. Het systeem biedt de beheerders van een e-maildomein een mechanisme voor het definiëren van de hosts die gemachtigd zijn om berichten van dat domein te verzenden, zodat de ontvanger hun geldigheid kan controleren.[ De lijst met hosts die gemachtigd zijn om e-mails te verzenden voor een bepaald domein wordt gepubliceerd in het Domain Name System (DNS) voor dat domein, in de vorm van speciaal opgemaakte TXT-records. Phishing, en soms zelfs spam, maakt gebruik van valse afzenderadressen, dus het posten en verifiëren van SPF-records kan gedeeltelijk als een antispamtechniek worden beschouwd.

Vertaald controleert de Bugo-mailserver of de Coso-mailserver de autorisatie heeft om mails te verzenden vanaf de Coso-host, d.w.z. cosi@vattelapesca.it, en verifieert zo de geldigheid van de afzender en de lijst met geautoriseerde hosts. Als de SPF-markering ontbreekt, verbranden veel mailservers, in ieder geval de serieuze tegenwoordig, de mail, vaak vind je deze niet eens meer in de spambox.

Afgerond? Nee!

Laten we doen alsof cosi@vattelapesca.it heeft ook de SPF-markering correct geconfigureerd.

De e-mail komt nog steeds niet aan. Wederom het telefoontje van Bugo naar zijn IT-manager en de IT-manager die regelt. En wat vindt hij?

De DKIM-markering ontbreekt Appero! En wat is dit? Wat is dit voor duivels?

DomainKeys Identified Mail (DKIM): stelt domeinbeheerders in staat om via een privésleutel een digitale handtekening toe te voegen aan e-mailberichten. DKIM voegt daarom nog een tool toe om de correspondentie tussen de afzender en het bijbehorende domein te verifiëren.

Nogmaals, om het te vereenvoudigen, met de e-mail, cosi@vattelapesca.it het stuurt ook een willekeurige privésleutel die is gekoppeld aan een openbare sleutel die zich in de DNS-zone van het domein bevindt vattelapesca.it en de mailserver van de ontvanger controleert of de sleutels gekoppeld zijn. Als dat niet het geval is, komt de e-mail in de spam terecht.

De perfecte controle is gewoon Reverse+SPF+DKIM. Als een e-mail deze controle niet doorstaat, wordt de e-mail verbrand.

Vaak vragen sommige klanten me om bijvoorbeeld het domein op de whitelist te zetten vattelapesca.it maar als je het omgekeerde doet, is het IP-adres nog steeds niet correct, de witte lijst is nutteloos. Bovendien is het om een ​​simpele reden een onjuist verzoek: je kunt niet weten of de afzender in kwestie "te goeder trouw" is, want soms weet zelfs de afzender zelf niet dat hij dat is. Het is alsof je een vriend hebt die in de buurt van een nomadenkamp woont en hem hebt gevraagd de voordeur open te houden, "te goeder trouw".

Maar laten we doorgaan.

Laten we bij de controle doen alsof de DKIM-codering ook in orde is. Of misschien is het niet eens nodig. Maar de e-mail komt niet aan.

Wederom Bugo's telefoontje naar zijn inmiddels uitgeputte IT-manager. De aanvraag is definitief: gezet cosi@vattelapesca.it op de witte lijst gezet.

Maar dat kan niet. Je overtreedt beveiligingsprotocollen en brengt het hele bedrijf in ernstig gevaar. De IT Manager controleert en…

Het vattelapesca-domein bevindt zich in verschillende RBL's/DNSBL's. Ah! Kappertjes! Maar wat zijn ze?

Een op DNS gebaseerde Blackhole List (ook wel DNSBL, Real-time Blackhole List of RBL) is een middel waarmee het mogelijk is om een ​​lijst met IP-adressen te publiceren, in een speciaal formaat dat gemakkelijk kan worden "opgevraagd" via internet. Zoals de naam al doet vermoeden, is het werkingsmechanisme gebaseerd op DNS (Domain Name System). DNSBL's worden voornamelijk gebruikt voor het op de een of andere manier publiceren van IP-adressen die verband houden met spammers. De meeste e-mailservers kunnen worden geconfigureerd om berichten van hosts op een of meer lijsten te weigeren of te markeren.

Maar op dat moment antwoordt de IT-manager van Bugo aan zijn werkgever en zegt: "Jongens, als ze zijn geregistreerd in een RBL, zijn wij het niet die moeten begrijpen waarom en het probleem moeten oplossen, de IT-manager van de afzender moet erover nadenken ”.

En de e-mail belandt in de prullenbak.

Er zou nog veel meer toe te voegen zijn, maar ik wil hier stoppen. Laten we echter zeggen dat dit alles het noodzakelijke minimum is, dat het niet genoeg is om de slechteriken te blokkeren, dat er andere controles worden toegevoegd en ook problemen die inherent zijn aan de DKIM-protocollen die open en interpreteerbare protocollen zijn en daarom is er geen uniformiteit, dus zozeer zelfs dat er vaak problemen zijn met het verzenden/ontvangen van/naar mailboxen op Libero, Virgilio, Gmail etc.... en het zijn zeer moeilijke problemen om op te lossen. Daarbij komen problemen met betrekking tot het gedrag van individuen die vaak in strijd zijn met de netiquette, zoals het onjuist gebruiken van e-mailheaders, het gelijktijdig onversleuteld verzenden naar meerdere verschillende gebruikers, enzovoort.

Er gaat een wereld open waar technici, computerwetenschappers, ingenieurs, wiskundigen, natuurkundigen elkaar confronteren zonder er echter in principe in geslaagd te zijn een oplossing te vinden (en die zullen ze mijns inziens ook nooit vinden).

Wat ik wel kan zeggen, is dat de keuze voor een goede hostingservice door verschillende factoren moet gaan die nooit de prijs zijn en vooral moet beantwoorden aan beveiligingsbehoeften die het ABC zouden moeten zijn van elk bedrijf dat tegenwoordig op internet wordt getoond in de verschillende vormen en op verschillende manieren.