Először egy e-mail felhasználói ügynököt vagy MUA-t használ az e-mailek olvasására és küldésére az eszközéről (például a gmail vagy az Apple eszközök levelezőalkalmazása). Ezek a programok csak akkor aktívak, ha Ön használja őket.
Általában egy levélátviteli ügynökkel vagy MTA-val (más néven levélkiszolgáló, MX gazdagép és levélváltó) kommunikálnak, amely az e-mailek fogadására és tárolására szolgál.
Az e-maileket távolról tároljuk, amíg meg nem nyitja a MUA-t, hogy ellenőrizhesse e-mailjeit. Az e-maileket kézbesítő ügynökök (MDA) kézbesítik, amelyeket általában az MTA-val együtt csomagolnak.
A leveleket régebben SMTP vagy Simple Mail Transfer Protocol használatával küldték egy levelezőszervernek. Az SMTP az e-mail kommunikációs protokollja.
Még most is, miközben sok saját tulajdonú rendszer, például a Microsoft Exchange és a webmail programok, például a Gmail belső protokollokat használnak, SMTP-t használnak az üzenetek továbbításához a rendszerükön kívül (például ha egy Gmail felhasználó e-mailt akar küldeni egy Outlook kliensnek).
A leveleket ezután a szerverről a Post Office Protocol (POP3) segítségével töltenék le. A POP3 egy alkalmazásréteg-protokoll, amely hozzáférést biztosít egy IP-hálózaton keresztül a felhasználói alkalmazás számára, hogy kapcsolatba léphessen a levelezőszerveren lévő postafiókkal. Csatlakozhat, visszakeresheti az üzeneteket, tárolhatja azokat az ügyfél számítógépén, és törölheti vagy megtarthatja őket a szerveren.
Úgy tervezték, hogy képes legyen kezelni az ideiglenes internetkapcsolatokat, például a betárcsázást (így csatlakoztatva egyszerűen összekapcsolná és lekérné az e-maileket, és lehetővé tenné az üzenetek megtekintését offline állapotban). Ez akkor volt népszerűbb, amikor a telefonos hozzáférés szélesebb körű volt.
Most az IMAP, az Internet Message Access Protocol váltotta fel leginkább a POP3-at. Az IMAP lehetővé teszi, hogy több kliens kezelje ugyanazt a postafiókot (így elolvashatja az e-maileket asztali számítógépéről, laptopjáról, telefonjáról stb., És az összes üzenete ugyanúgy lesz rendezve).
Végül a webmail mindkettőt felváltotta. A Webmail lehetővé teszi, hogy bejelentkezzen egy webhelyre, és üzeneteket fogadjon bárhonnan vagy bármilyen eszközről (jaj!), Azonban használatakor csatlakoznia kell az internethez. Ha a webhely (például a gmail) az Ön MUA-ja, akkor nem kell ismernie az SMTP vagy IMAP szerver beállításait.
Hogyan biztonságos az e-mail?
Sajnos a biztonság a kezdetektől fogva nem épült be a levelezési protokollokba (mint a legtöbb kezdő internetes protokoll). A kiszolgálók arra számítottak, hogy bárkitől elvesznek bármilyen üzenetet, és továbbítják azokat bármely más szervernek, amely segíthet az üzenet végcéljába (a címzett a: mezőbe) továbbításában.
Nem meglepő, hogy ez akkor vált kérdéssé, amikor az internet néhány kormányzati és kutatócsoportból olyan területre terjeszkedett, amelybe a világ legtöbbje lényegében mindent megtesz. A spam és az adathalász e-mailek hamarosan hatalmas problémává váltak (és maradnak) mindenki számára.
Válaszként együttesen több olyan intézkedést is megpróbáltunk végrehajtani, amelyek megakadályozzák az embereket abban, hogy elolvassák mások üzeneteit (titkosítás), és igazolják, hogy az üzenetek valóban az állítólagos feladótól érkeztek (hitelesítés).
A legtöbb hely a TLS-t (szállítási réteg biztonsága, az SSL helyettesítése, biztonságos socket réteg) használja, egy kriptográfiai protokollt, amely titkosítást biztosít az átvitel során. Védelmet nyújt az üzenet továbbításakor, de nem akkor, amikor az adatok nyugalomban vannak (például a számítógépen tárolódnak).
Ez biztosítja, hogy az üzenetet ne módosítsák vagy ne szaggassák tovább, miközben az MTA-ból az MTA-ba utazik. Ez azonban nem ellenőrzi, hogy az üzenetet az utazás során nem módosították-e.
Például, ha az e-mail több levélkiszolgálón megy keresztül, mielőtt elérné a végső rendeltetési helyet, a TLS használatával biztosíthatja, hogy az a szerverek között legyen titkosítva, de minden szerver megváltoztathatja az üzenet tartalmát. Ennek megoldására létrehoztuk az SPF, a DKIM és a DMARC programokat.
SPF (Sender Policy Framework)
Az SPF lehetővé teszi egy domain (például a google.com) tulajdonosának, hogy TXT rekordot állítson be a DNS-ben, amely meghatározza, hogy mely szerverek küldhetnek levelet ebből a tartományból (a különféle tárhelyszolgáltatók számára ezt lásd itt: webhely).
Hogy működik ez?
Ez a rekord felsorolja azokat az eszközöket (általában IP-alapon), amelyek engedélyezettek, és a következő lehetőségek egyikével zárulhatnak:
-all = Ha az ellenőrzés nem sikerül (az e-mail forrása nem tartozik a felsorolt eszközök közé), az eredmény HardFail. A legtöbb levelezőrendszer ezeket az üzeneteket spamként jelöli meg.
? all = = Ha az ellenőrzés sikertelen (az e-mail forrása nem tartozik a felsorolt eszközök közé), az eredmény semleges. Ezt általában tesztelésre használják, nem a termelési tartományokra.
~ all = Ha az ellenőrzés nem sikerül (az e-mail forrása nem tartozik a felsorolt eszközök közé), az eredmény egy SoftFail. Ez azt jelenti, hogy ez az üzenet gyanús, de nem feltétlenül ismert rossz. Néhány levelezőrendszer ezeket az üzeneteket spamként jelöli meg, de a legtöbb nem.
Az SPF fejlécek maguknak a szervereknek is hasznosak lehetnek, mivel feldolgozzák az üzeneteket. Például, ha egy szerver a hálózat szélén van, tudja, hogy a kapott üzeneteknek a feladó SPF rekordjában szereplő szerverekről kell származniuk. Ez segít a szervereknek gyorsabban megszabadulni a spamtől. Bár ez remekül hangzik, sajnos van néhány fő probléma az SPF-rel.
- Az SPF nem mondja meg a levelező szervernek, hogy mit kell tennie az üzenettel - ez azt jelenti, hogy egy üzenet meghiúsíthatja az SPF-ellenőrzést, és akkor is kézbesíthető.
- Az SPF-rekord nem a felhasználó által látott "feladó" címet, hanem a "visszatérési utat" nézi. Ez alapvetően megegyezik a levélre írt visszaküldési címmel. A levelet kezelő levelezőszervereknek megmondja, hová küldje vissza az üzenetet (és az e-mail fejlécekben tárolódik - lényegében technikai információs szerverek használják az e-mailek feldolgozására).
Ez azt jelenti, hogy bármit beírhatok a from: címbe, és ez nem befolyásolja az SPF-ellenőrzést. Valójában mindkét e-mail címet viszonylag meghamisíthatja egy hacker. Mivel nincs benne titkosítás, az SPF fejléceket nem lehet teljesen megbízni.
- Az SPF nyilvántartásait folyamatosan naprakészen kell tartani, ami nehéz lehet nagy, folyamatosan változó szervezeteknél.
- Továbbítás szünetek SPF. Ez azért van, mert ha a mondjuk a google.com címről küldött e-mailt a [email protected] címre továbbítja, a boríték feladója változatlan marad (a feladó cím továbbra is a google.com címet írja). A fogadó levélkiszolgáló úgy gondolja, hogy azt állítja, hogy a google.com webhelyről származik, de a bobsburgers.com webhelyről származik, így nem sikerül az SPF ellenőrzés (annak ellenére, hogy a levelek valóban a google.com címről érkeznek).
Az SPF-vel kapcsolatos további információkért olvassa el ezeket a cikkeket. Itt ellenőrizheti, hogy egy adott tartományban van-e konfigurálva SPF és DMARC rekord.
DKIM (DomainKeys azonosított levél)
A DKIM hasonló az SPF-hez. A TXT rekordokat használja a küldő tartomány DNS-ében is, és biztosítja az üzenet bizonyos hitelesítését. Megpróbálja ellenőrizni, hogy az üzenetek nem változtak-e szállítás közben.
Hogy működik ez?
A küldő tartomány létrehoz egy nyilvános / privát kulcs párot, és a nyilvános kulcsot a tartomány DNS TXT rekordjába helyezi (ha nem tudja, mi a nyilvános / privát kulcs pár, olvassa el ezt a cikket a rejtjelezésről).
Ezután a tartomány levélkiszolgálói (a külső határon - azok a kiszolgálók, amelyek a tartományon kívül küldenek levelet (pl. A gmail.com-ról az outlook.com-ra)) a privát kulccsal hozzák létre az egész üzenettörzs aláírását, beleértve a fejlécek.
Az aláírás előállításához általában megköveteli a szöveg kivonatolását és titkosítását (a folyamat részleteivel kapcsolatban olvassa el ezt a cikket).
A fogadó levélkiszolgálók a DNS TXT rekord nyilvános kulcsát használják az aláírás visszafejtésére, majd az üzenet és a releváns fejlécek kivonatolására (minden olyan fejlécre, amely akkor jött létre, amikor az e-mail a feladó infrastruktúráján belül volt - például, ha több gmail szerver feldolgozta az e-mailt előtte. külsőleg az outlook.com címre küldték).
A szerver ezt követően ellenőrzi, hogy a két hash egyezik-e. Ha igen, akkor az üzenet valószínűleg nem változik (hacsak valaki nem sérti a feladó privát kulcsát), és jogszerűen az állítólagos küldőtől. Ha a kivonatok nem egyeznek, akkor az üzenet vagy nem az állítólagos küldőtől származik, vagy valamely másik átutazó szerver módosította, vagy mindkettő.
A DKIM nagyon jó munkát végez egy nagyon specifikus feladatnál - megválaszolva a kérdést: "Ezt az e-mailt módosították-e átutazás közben, vagy sem az állítólagos küldő?" Ez azonban csak annyit tesz. Nem árulja el, hogyan kell kezelni azokat az e-maileket, amelyek sikertelenek a teszten, melyik szerver változtathatta meg az üzenetet, vagy milyen módosításokat hajtottak végre.
A DKIM-et néhány internetszolgáltató vagy internetszolgáltató is használja domainje hírnevének megállapítására (sok spam-et küld? Kevés az elkötelezettsége? Milyen gyakran pattognak az e-mailjei?).
Ha többet szeretne megtudni a DKIM-ről, nézze meg ezt a cikket. Itt érvényesíthet egy DKIM rekordot.
DMARC (tartományalapú üzenet-hitelesítés, jelentéskészítés és megfelelőség)
A DMARC lényegében az e-mail szerverekre vonatkozó utasítások az SPF és DKIM rekordok kezelésére. Nem végez önálló teszteket, de megmondja a levelező szervereknek, hogyan kell kezelni az SPF és a DKIM által végzett ellenőrzéseket.
A részt vevő internetszolgáltatók megnézik a közzétett DMARC rekordokat, és felhasználják őket annak meghatározására, hogyan kell kezelni a DKIM vagy az SPF sikertelenségét. Így például egy általánosan hamisított márka közzétehet egy DMARC rekordot, amely szerint ha a DKIM vagy az SPF nem sikerül, dobja el az üzenetet.
Az internetszolgáltatók gyakran jelentéseket küldenek Önnek a domain tevékenységéről, az e-mail forrásával és azzal, hogy az megfelelt-e / nem sikerült-e a DKIM / SPF-n. Ez azt jelenti, hogy látni fogja, hogy az emberek mikor csalják (állítólag küldik) az Ön domainjét vagy módosítják az üzeneteit.
A DMARC megvalósításához létre kell hoznia egy DMARC rekordot, az Ön igényei alapján (az e-mail forgalom ellenőrzésétől kezdve az összes e-mail forrás megismerésén át a tevékenységek kéréséig, például a DKIM vagy az SPF sikertelen e-mailek elutasításáig). Itt és itt többet megtudhat ennek végrehajtásáról.
Ha többet szeretnél olvasni a DMARC-ról, nézd meg ezt a cikket. Itt ellenőrizheti, hogy egy adott tartományban van-e konfigurálva SPF és DMARC rekord.
Tekerje be
Ezen biztonsági intézkedések egyike sem tökéletes, de együttesen tisztességes munkát végeznek az e-mail rendszerek biztonságának javításában világszerte.
Minél több szervezet fogadja el ezeket az intézkedéseket (akár nyílt forráskódú megvalósításokat használ, akár fizet egy termékért), annál jobb lesz mindenki számára. A protokoll vagy termék kifejlesztése után hozzáadott biztonság általában drágább, kevésbé hatékony és nehezebben megvalósítható, mint a termékbe épített biztonság.
A legtöbb protokoll, amelyre a jelenlegi internet támaszkodik, azonban a korai internethez készült - egy rajongók, tudósok és kormányzati személyek kis csoportjának -, nem pedig egy olyan világméretű hálózat, amelyen épületeket, intelligens eszközöket, tömegközlekedést, atomerőműveket működtetünk (!), stb.
Így, amint az internet folyamatosan bővül, tovább kell alkalmazkodnunk és új módszereket kell kidolgoznunk az általunk támaszkodó rendszerek biztonsága érdekében.