Hogyan működik egy e-mail, és mindenekelőtt miért kerül spambe

Hogyan működik az e-mail

és mindenekelőtt azért, mert spambe kerül

Mivel ez egy összetett téma, amely kiterjedt technikai vitákra alkalmas, megpróbálom leegyszerűsíteni, hogy a "normális" közönség is megértse. Tegyük fel, hogy van két barátunk, akik írnak egymásnak, az A feladót hívják ARÉNA és a B címzettet hívják BUGO.

Coso e-mailt ír Bugónak. Mi történik a színfalak mögött?
A Coso A szervere e-mailt küld a Bugo B szerverének.
Egyszerűen, cosi@vattelapesca.it -nek ír bugo@nonmissassare.com.

Minden oké neked. Hol a probléma? Valójában nem egészen így van. Sokszor megtörténik. Kihagyom annak részleteit, hogy a leveleket hogyan "csomagolják" és csomagokban küldik el több különböző útvonalon az internetes univerzumban, hogy a Bugo levelezőszerver újra összeállítsa őket, mert ez nagyon hosszú dolog lesz, és letérnénk a sínekről.

innen térünk vissza cosi@vattelapesca.it aki ír bugo@nonmissassare.com.

Coso nem kap választ. Telnek a napok, és még mindig nem érkezik válasz. Pedig ez egy fontos kommunikáció! Tehát felhívja Bugót telefonon, és Bugo azt válaszolja, hogy soha nem kapta meg az e-mailt!

Általában Bugo felhívja az IT-menedzserét vagy a tárhely-menedzsert, majd a postafiókokat és a levelezőszervert szállító üvöltözni kezd: „Tessék! Add vissza a pénzem, tolvaj! Az emailek nem működnek!!! Nem kapok e-maileket tőle cosi@vattelapesca.it.

Mindannyian találkoztatok ezzel a problémával. A lényeg az, hogy miután minden elmúlt, ma a létező biztonsági problémákkal a dolgok megváltoztak, köszönhetően nektek is, akik nagy bunkósok vagytok..

Amikor Coso e-mailt küld Bugónak, a Bugo levelező visszanéz, megkedveli a lazacot, és visszakeresi a kapott e-mail fordított útvonalát. És nézz meg pár dolgot:

Először azt ellenőrzi, hogy a küldő valóban az-e, akinek mondják magukat. Lehet, hogy számodra triviálisnak tűnik, de egyáltalán nem az! Az a tény, hogy te vagy cosi@vattelapesca.it egyáltalán nem jelent semmit.

Valójában a Bugo levelezőszerver ellenőrzi, hogy a feladó gazdagépének IP-címe, azazvattelapesca.com” ebben az esetben megegyezik a levelezőszerver IP-jével. Banális? Nem! Gyakran ez az első probléma. A vállalatok belső informatikai vezetői gyakran elkövetik azt az egyszerű hibát, hogy rosszul konfigurálják a tartomány DNS-zónáját, és nem megfelelően osztják ki a levelezőszerver IP-címét. Ez különösen igaz, ha egy szerveren több különböző tartomány található. Azok, akik az általuk kezelt szerver particionálásával adnak el hosting szolgáltatásokat, gyakran tévednek ebben a kérdésben. A nagy szolgáltatók rendszerszinten kezelik ezt a problémát, ezért a problémával szinte soha nem találkozunk. De a nagy/közepes vállalatoknál, ahol az informatikai vezetők nem egészen magas szinten vannak, és akik saját levelezőszervereiket belsőleg kezelik, ez a probléma gyakorivá válik.

Alapvetően a Bugo levelezőszerver spamként tárolja az e-mailt, mert nem érti, hogy valójában ki a feladó. Ilyen esetekben még az e-mailt is teljesen kiégetik, és még a spam mappából sem lehet visszaállítani.

Ehelyett győződjünk meg arról, hogy a feladó levelezőszerverének konfigurációja helyes, és a Bugo levelezőszerver fordítva igazolja, hogy az IP helyes, és ezért a feladó az, akinek mondja magát.

De a levél továbbra sem érkezik meg a célállomásra. Megint Bugo felhívja az IT vezetőjét stb... Az IT menedzser ellenőrzi és ellenőrzi, hogy hiányzik-e az SPF jelölés. Jaj! Mi az SPF jelölés?

A Sender Policy Framework (SPF) egy e-mail-ellenőrző rendszer, amelyet az e-mail-hamisítási kísérletek észlelésére terveztek. A rendszer egy e-mail tartomány adminisztrátorainak egy olyan mechanizmust kínál, amellyel meghatározhatják az adott tartományból üzenetküldésre jogosult gépeket, így a címzett ellenőrizheti azok érvényességét. a domain névrendszerében (DNS) speciálisan formázott TXT rekordok formájában. Az adathalászat és néha még a spam is hamis küldőcímeket használ, így az SPF-rekordok közzététele és ellenőrzése részben levélszemét-ellenes technikának tekinthető.

Lefordítva a Bugo levelezőszerver ellenőrzi, hogy a Coso levelezőszerver rendelkezik-e jogosultsággal leveleket küldeni a Coso gazdagépétől, nevezetesen a cosi@vattelapesca.it, így ellenőrzi a feladó érvényességét és az engedélyezett gazdagépek listáját. Ha hiányzik az SPF jelölés, sok levelezőszerver, legalábbis a mai komolyabbak, elégeti a leveleket, sokszor már a spam dobozban sem találja meg.

Befejezett? Nem!

Tegyünk úgy, mintha cosi@vattelapesca.it az SPF jelölés is megfelelően van konfigurálva.

Az email még mindig nem érkezik meg. Ismét hívás Bugotól az IT-menedzseréhez és az irányító IT-menedzserhez. És mit talál?

A DKIM jelölés hiányzik Appero! És mi ez? Mi ez az ördög?

DomainKeys Identified Mail (DKIM): lehetővé teszi a tartománykezelők számára, hogy privát kulcson keresztül digitális aláírást adjanak az e-mail üzenetekhez. A DKIM ezért egy további eszközt ad a feladó és a hozzá tartozó tartomány közötti megfelelés ellenőrzésére.

Még egyszer, az egyszerűsítés kedvéért: cosi@vattelapesca.it egy véletlenszerű privát kulcsot is küld, amely a tartomány DNS-zónájában található nyilvános kulcshoz kapcsolódik vattelapesca.it és a címzett levelezőszervere ellenőrzi, hogy a kulcsok össze vannak-e kapcsolva. Ha nem, az e-mail spambe kerül.

A tökéletes vezérlés csak a Reverse+SPF+DKIM. Ha egy e-mail nem felel meg az ellenőrzésen, akkor az e-mail égetésre kerül.

Egyes ügyfelek gyakran arra kérnek, hogy tegyem engedélyezőlistára például a domaint vattelapesca.it de ha fordítva, az IP még mindig nem megfelelő, a fehérlista használhatatlan. Ráadásul egy egyszerű okból helytelen kérésről van szó: nem lehet tudni, hogy a szóban forgó feladó "jóhiszemű-e", mert néha még maga a feladó sem tudja, hogy az. Olyan, mintha egy barátod egy nomád tábor közelében élne, és megkérted volna, hogy "jóhiszeműen" tartsa nyitva a bejárati ajtót.

De folytassuk.

Az ellenőrzéskor tegyük fel, hogy a DKIM-titkosítás is rendben van. Vagy talán nem is szükséges. De az email nem érkezik meg.

Ismét Bugo hívása a már kimerült IT-menedzseréhez. A kérés végleges: tedd cosi@vattelapesca.it fehérlistára.

De nem teheted. Ön megszegi a biztonsági protokollokat, ami az egész vállalatot komoly veszélybe sodorja. Az informatikai vezető ellenőrzi és…

A vattelapesca domén több RBL-ben/DNSBL-ben található. Ah! Kapribogyó! De mik azok?

A DNS-alapú Blackhole List (más néven DNSBL, Real-time Blackhole List vagy RBL) egy olyan eszköz, amellyel lehetőség nyílik IP-címek listájának közzétételére, speciális formátumban, amely könnyen "lekérdezhető" az interneten keresztül. Ahogy a neve is sugallja, a működési mechanizmus a DNS-en (Domain Name System) alapul. A DNSBL-eket főként a spamküldőkhöz valamilyen módon kapcsolódó IP-címek közzétételére használják. A legtöbb levelezőszerver beállítható úgy, hogy elutasítsa vagy megjelölje az egy vagy több listán szereplő gazdagépektől küldött üzeneteket.

De ezen a ponton Bugo IT-menedzsere válaszol a munkáltatójának, és azt mondja: "Srácok, ha regisztráltak egy RBL-be, akkor nem nekünk kell megértenünk, miért és megoldanunk a problémát, hanem a küldő IT-menedzserének kell gondolkodnia."

És az e-mail a kukában végzi.

Sokat lehetne még hozzáfűzni, de itt szeretnék megállni. Azonban tegyük fel, hogy mindez a nélkülözhetetlen minimum, hogy nem elég blokkolni a rosszfiúkat, hogy más vezérlők is hozzáadásra kerülnek, és a DKIM protokollokban rejlő problémák is, amelyek nyílt és értelmezhető protokollok, ezért nincs egységesség, tehát olyannyira, hogy gyakran problémák adódnak a Libero, Virgilio, Gmail stb. postafiókokba történő küldés/fogadás során. és nagyon nehezen megoldható problémák. Ehhez járulnak még a netikettel gyakran ellentétes egyének viselkedésével kapcsolatos problémák, mint például az e-mailek fejléceinek helytelen használata, több különböző felhasználónak történő egyidejű küldés titkosítás nélkül és így tovább.

Megnyílik egy világ, ahol technikusok, informatikusok, mérnökök, matematikusok, fizikusok kerülnek szembe egymással anélkül, hogy elvileg sikerült volna megoldást találniuk (és szerintem soha nem is fogják megtalálni).

Azt mondhatom, hogy a jó hosting szolgáltatás kiválasztásának számos tényezőn kell keresztülmennie, amelyek soha nem az ára, és mindenekelőtt a biztonsági igényekre kell válaszolnia, amelyeknek minden olyan vállalat ABC-je kell legyen, amely ma az interneten a különböző formákban és különféle módokon.