Kuidas meil töötab

ja eelkõige sellepärast, et see jõuab rämpsposti

Kuna tegemist on keeruka teemaga, mis sobib ulatuslikeks tehnilisteks aruteludeks, püüan seda lihtsustada, et see "tavalisele" avalikkusele arusaadav oleks. Oletame, et meil on kaks sõpra, kes kirjutavad üksteisele, kutsutakse saatjat A COSO ja adressaat B kutsutakse BUGO.

Coso kirjutab Bugole meili. Mis toimub kulisside taga?
Coso server A saadab Bugo serverile B meili.
Lihtsamalt öeldes cosi@vattelapesca.it kirjutab aadressile bugo@nonmissassare.com.

Sinu jaoks kõik ok. Kus on probleem? Tegelikult pole see päris nii. Seda juhtub palju. Jätan välja üksikasjad selle kohta, kuidas e-kirjad "pakendatakse" ja saadetakse pakettidena mitmel erineval marsruudil mööda Interneti-universumit, et need Bugo meiliserveris uuesti kokku panna, sest see muutub väga pikaks ja me läheme rööpast välja.

Me pöördume tagasi cosi@vattelapesca.it kes kirjutab bugo@nonmissassare.com.

Coso ei saa vastust. Mööduvad päevad ja ikka ei reageerita. Ometi on see oluline suhtlus! Nii et ta helistab Bugole telefoni teel ja Bugo vastab, et ta pole kunagi meili saanud!

Üldjuhul helistab Bugo siis oma IT-juhile või hostimishaldurile ja siis hakkab postkastide ja meiliserveri varustaja nurisema: „Siin! Anna mulle raha tagasi, varas! Meilid ei tööta!!! Ma ei saa e-kirju cosi@vattelapesca.it.

Teil kõigil on natuke seda probleemi olnud. Asi on selles, et kui kõik möödas, siis täna koos olemasolevate turvaprobleemidega on asjad muutunud, tänu ka teile, kes olete suured segajad.

Kui Coso saadab Bugole e-kirja, kontrollib Bugo kirjasaatja tagasi, talle meeldib lõhe ja otsib vastuvõetud meili vastupidist teed. Ja kontrollige paari asja:

Esimese asjana kontrollib see, kas saatja on tõesti see, kes ta end ütleb. See võib teile tunduda triviaalne, kuid see pole sugugi! See, et sa oled cosi@vattelapesca.it see ei tähenda üldse mitte midagi.

Tegelikult kontrollib Bugo meiliserver, et saatja hosti IP, st.vattelapesca.com” vastab sel juhul meiliserveri IP-le. Banaalne? Ei! Sageli on see esimene probleem. Ettevõtete sisemised IT-juhid teevad sageli selle lihtsa vea, et konfigureerivad domeeni DNS-tsooni valesti ja ei määra meiliserveri IP-d õigesti. See kehtib eriti siis, kui ühes serveris on mitu erinevat domeeni. Sageli eksivad need, kes müüvad hostimisteenuseid nende hallatava serveri partitsioonide kaudu. Suured pakkujad tegelevad selle probleemiga süsteemselt ja seetõttu ei teki probleemi peaaegu kunagi. Kuid suurtes/keskmistes ettevõtetes, kus IT-juhid ei ole päris tasemel ja kes haldavad oma meiliservereid sisemiselt, muutub see probleem sagedaseks.

Põhimõtteliselt failib Bugo meiliserver meili rämpspostiks, kuna ei saa aru, kes saatja tegelikult on. Sellistel juhtudel põletatakse isegi e-kiri täielikult ja seda ei saa isegi rämpsposti kaustast taastada.

Selle asemel veendugem, et saatja meiliserveri konfiguratsioon oleks õige ja et Bugo meiliserver, toimides vastupidiselt, tõendaks, et IP on õige ja seega on saatja see, kelleks ta end ütleb.

Kuid post ei jõua ikka veel sihtkohta. Jälle Bugo kõne IT-juhile jne… IT-juht kontrollib ja kontrollib, et SPF-märgis puudub. Oeh! Mis on SPF-märgis?

Sender Policy Framework (SPF) on meilikontrollisüsteem, mis on loodud e-kirjade võltsimise katsete tuvastamiseks. Süsteem pakub e-posti domeeni administraatoritele mehhanismi, mille abil saab määratleda hostid, kellel on õigus sellest domeenist sõnumeid saata, võimaldades adressaadil kontrollida nende kehtivust. selle domeeni domeeninimesüsteemis (DNS) spetsiaalselt vormindatud TXT-kirjete kujul. Andmepüük ja mõnikord isegi rämpspost kasutavad saatja valeaadresse, seega võib SPF-kirjete postitamist ja kontrollimist pidada osaliselt rämpspostivastaseks tehnikaks.

Tõlgitud, Bugo meiliserver kontrollib, kas Coso meiliserveril on õigus saata kirju Coso hostilt, st cosi@vattelapesca.it, kontrollides nii saatja ja volitatud hostide loendi kehtivust. Kui SPF-märgis puudub, põletavad paljud meiliserverid, vähemalt tänapäeval tõsised, kirjad, sageli ei leia seda enam isegi spämmikastist.

Kas valmis? Ei!

Teeskleme seda cosi@vattelapesca.it ka SPF-märgistus on õigesti konfigureeritud.

Meili ikka ei jõua. Jälle kõne Bugolt oma IT-juhile ja IT-juhile, kes kontrollib. Ja mida ta leiab?

DKIM-märgis puudub Appero! Ja mis see on? Mis see saatan on?

DomainKeys Identified Mail (DKIM): võimaldab domeenihalduritel lisada e-kirjadele privaatvõtme kaudu digitaalallkirja. Seetõttu lisab DKIM täiendava tööriista saatja ja talle kuuluva domeeni vahelise kirjavahetuse kontrollimiseks.

Jällegi, et lihtsustada seda e-kirjaga, cosi@vattelapesca.it see saadab ka juhusliku privaatvõtme, mis on seotud avaliku võtmega, mis asub domeeni DNS-tsoonis vattelapesca.it ja adressaadi meiliserver kontrollib, et võtmed on lingitud. Kui neid ei ole, satub e-kiri rämpsposti.

Täiuslik juhtimine on lihtsalt Reverse+SPF+DKIM. Kui e-kiri seda kontrolli ei läbi, e-kiri põletatakse.

Sageli paluvad mõned kliendid mul lisada näiteks domeeni lubatud loendisse vattelapesca.it aga kui teete vastupidist, pole IP ikkagi õige, valge nimekiri on kasutu. Pealegi on see vale taotlus lihtsal põhjusel: te ei saa teada, kas kõnealune saatja on "heas usus", sest mõnikord ei tea isegi saatja ise, et ta on. Tundub, nagu oleks sul sõber, kes elab nomaadide laagri lähedal ja sa palusid tal välisuks lahti hoida, "heas usus".

Aga jätkame.

Kontrollimisel teeskleme, et ka DKIM-i krüptimine on korras. Või pole see isegi vajalik. Aga meili ei jõua.

Jälle Bugo kõne tema praeguseks kurnatud IT-juhile. Taotlus on lõplik: pane cosi@vattelapesca.it lubatud nimekirja.

Aga sa ei saa. Te rikute turvaprotokolle, seades kogu ettevõtte tõsisesse ohtu. IT-juht kontrollib ja…

Vatelapesca domeen on mitmes RBL-is/DNSBL-is. Ah! Kapparid! Aga mis need on?

DNS-põhine Blackhole List (ka DNSBL, Real-time Blackhole List või RBL) on vahend, mille abil on võimalik avaldada IP-aadresside loendit spetsiaalses vormingus, mida saab hõlpsalt Interneti kaudu "päringuid teha". Nagu nimigi ütleb, põhineb töömehhanism DNS-il (domeeninimede süsteem). DNSBL-e kasutatakse peamiselt rämpspostitajatega mingil moel seotud IP-aadresside avaldamiseks. Enamiku meiliservereid saab konfigureerida ühe või mitme loendi hostidelt saadetud sõnumite tagasilükkamiseks või märgistamiseks.

Kuid sel hetkel vastab Bugo IT-juht oma tööandjale ja ütleb: "Poisid, kui nad on RBL-is registreeritud, siis mitte meie ei pea aru saama ja probleemi lahendama, vaid saatja IT-juht peab sellele mõtlema."

Ja e-kiri jõuab prügikasti.

Lisada oleks veel palju, aga ma tahan siinkohal peatuda. Ütleme aga, et see kõik on hädavajalik miinimum, et pahalaste blokeerimisest ei piisa, lisanduvad muud juhtelemendid ja ka DKIM-i protokollidele omased probleemid, mis on avatud ja tõlgendatavad protokollid ning seetõttu puudub ühtlus, nii et nii palju, et Libero, Virgilio, Gmaili jne postkastidesse saatmisel/vastuvõtmisel on sageli probleeme. ja neid on väga raske lahendada. Sellele lisanduvad probleemid, mis on seotud netiketiga sageli vastuolus olevate isikute käitumisega, näiteks e-kirjade päiste vale kasutamine, krüptimata sõnumite saatmine korraga mitmele erinevale kasutajale ja nii edasi.

Avaneb maailm, kus tehnikud, arvutiteadlased, insenerid, matemaatikud, füüsikud vastanduvad, ilma et neil oleks siiski põhimõtteliselt õnnestunud lahendust leida (ja minu arvates ei leia nad seda kunagi).

Võin öelda, et hea hostimisteenuse valimine peab toimuma läbi erinevate tegurite, mis ei ole kunagi hind, ja eelkõige peab see vastama turvavajadustele, mis peaksid olema iga ettevõtte ABC, mis tänapäeval Internetis erinevates erinevates valdkondades kokku puutub. vormides ja mitmel viisil.