Enhancing Email Security: A feladói csalások megállítása SPF, DKIM és DMARC segítségével

Az igazságot nem lehet kiszűrni: meg kell védenie vállalata e-mailjeit.

2013-ban naponta több mint 100 milliárd üzleti e-mailt küldtek és fogadtak. A 2013-ban küldött e-maileknek csupán minden ötödik volt jogszerű, és a jogszerűtlen e-mailek 92%-a tartalmazott potenciálisan rosszindulatú tartalmakra mutató linkeket.

A javulás jelei azonban mutatkoznak: az elmúlt 12 évben ez volt az első olyan hónap, amikor a Symantec ügyfeleinek kevesebb mint fele volt spam.

A spamek számának csökkenését három e-mail biztonsági szabványnak (és más kezdeményezéseknek) köszönheti: SPF, DKIM és DMARC. A biztonsági kockázatok azonban még mindig elterjedtek. Nemrég hallottam egy történetet egy pénzügyi igazgatóról, aki adathalász kísérletnek volt kitéve. A kísérlet sikertelen volt, de ha sikerrel járt volna, az 50 000 dollárjába került volna a szervezetnek.

Az e-mail szabványok körül még mindig nagy a zűrzavar. Remélem, hogy ezzel a bejegyzéssel sikerül némi tisztázást nyújtanom, valamint végigvezetem Önt az SPF, a DKIM és a DMARC implementálásán.

Sender Policy Framework (RFC 4408)

A feladói irányelvek keretrendszere, vagyis az SPF az öregúr az email-hitelesítési partin. Az SPF egy nyílt szabvány, amely az openspf.org szerint a feladói címek hamisításának megakadályozására szolgáló módszert határoz meg. Nem a spamek megállításáról szól, hanem a feladóhamisítási kísérletek ellenőrzéséről és megállításáról.

Az SPF lehetővé teszi, hogy azonosítsa tartománya legitim levélforrásait, és megakadályozza, hogy az illetéktelen források több ezer – vagy akár több millió – tiltott e-mailt küldjenek a tartományából.

Az e-mail küldőhamisítással általában négyféle e-mail visszaélés fordul elő:

• Spam (kéretlen tömeges e-mail & kéretlen kereskedelmi e-mail)
• Csalók (419-es csalások)
• Malware (adware, zero days, vírusok, trójaiak stb.)
• Hamisítók (spear-phishing)

Nyilvánvaló okokból nem szeretné, ha szervezetének domainjét ezek bármelyikével kapcsolatba hoznák. Az SPF segít megbizonyosodni arról, hogy szervezetének e-mailjei valóban Öntől származnak.

DomainKeys Identified Mail (RFC 6376, az elavult RFC 4871 és RFC 5672 helyébe lép)

DKIM, vagy DomainKeys Identified Mail, egy TXT rekord, amelyet a Domain Name System (DNS) rendszerben tesznek közzé. Ez olyasvalamit foglal magában, amit minden IT-adminisztrátornak meg kell tanulnia szeretni: a kulcsokat – pontosabban a nyilvános kulcsokat.

Mielőtt belemerülnénk a DKIM-be, fontos, hogy megértsük, mik azok a kulcsok és hogyan működnek. A kulcsok, ebben az esetben a nyilvános kulcsú kriptográfia, nyilvános (mindenki által ismert) és titkos (gyakran titkosnak nevezett) kulcsokból áll. A nyilvános és a titkos kulcsok matematikailag kapcsolódnak egymáshoz, lehetővé téve a nyilvános csatornákon keresztüli biztonságos kommunikációt.

Ezek a kulcsok olyanok, mint a hamisíthatatlan pecsét egy átlátszó borítékon. Nem feltétlenül rejtik el az üzenetet, csupán 100%-os bizonyossággal hitelesítik mind a feladót, mind az üzenetet.

most, vissza a DKIM-hez.

“Technikailag a DKIM egy módszert biztosít az üzenethez kapcsolódó domainnév-azonosság érvényesítésére kriptográfiai hitelesítéssel” – olvasható a dkim.org oldalon. Más szóval, a DKIM kulcsokat használ, hogy megbizonyosodjon arról, hogy az e-mail feladó valóban az, akinek mondja magát.

A DKIM segítségével nyilvános és privát kulcspárokat generálnak a levelezőszerverek és a kommunikáció hitelesítéséhez. Minden kimenő Simple Mail Transfer Protocol (SMTP) kiszolgálónak szüksége van a megfelelő privát kulcsra és előtagra ahhoz, hogy megfeleljen egy nyilvános DNS-rekordnak, amelyet a fogadó levelezőszerver ellenőriz.

Gondolkozott már azon, hogy miért jelenik meg a zár ikon a Gmailben, amikor az eBay, a Paypal vagy a bankja üzeneteit kapja? Ez a DKIM és egy kis DMARC (amivel rövidesen foglalkozunk). Az alábbiakban a mailed-by az SPF egyezést, a signed-by pedig a DKIM egyezést mutatja. A DKIM és a DMARC egyelőre nem nélkülözhetetlen, de az IPv6-hoz hasonlóan ez is gyorsan halad a tesztlaborból a jobb használat felé.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

A DMARC, azaz a Domain-based Message Authentication, Reporting, and Conformance (Domain-alapú üzenethitelesítés, jelentés és megfelelőség) segít a küldő és a fogadó fél együttműködésében a biztonságosabb e-mail kommunikáció érdekében. A DMARC-ot szervezetek egy csoportja hozta létre, hogy korlátozza az e-mail alapú visszaéléseket “az e-mail hitelesítési protokollokkal kapcsolatos néhány régóta fennálló működési, telepítési és jelentési probléma megoldásával”, a dmarc.org.

DMARC lehetővé teszi az üzenet feladójának, hogy jelezze, hogy üzenetei SPF és/vagy DKIM védelemmel vannak ellátva. A DMARC-házirend egyértelmű utasításokat ad az üzenet címzettjének, amelyeket követnie kell, ha egy e-mail nem felel meg az SPF- vagy DKIM-hitelesítésnek – például elutasítja vagy kidobja.

A DMARC továbbá jelentést küld a feladónak a DMARC-értékelést PASS és/vagy FAIL DMARC-értékelésen átesett üzenetekről.

Hogyan kell megvalósítani az SPF, DKIM és DMARC szabványokat

Most, hogy jobban megértettük mindhárom szabványt (és hogy miért fontosak), nézzük meg, hogyan javíthatja az e-mail biztonságát ezek megvalósításával.

Megjegyzés: A lépésről lépésre történő bemutatás kedvéért tegyük fel, hogy Ön a 301 Moved, egy Google Apps-t használó kis webdesign cég informatikai vezetője.

A közelmúltban gondjai akadtak az orosz spamrobotokkal. A végfelhasználók arról panaszkodtak, hogy olyan címekről kapnak visszapattanó e-maileket, amelyeket soha nem láttak, és nem is küldtek nekik üzenetet. Rájött, hogy valaki nyilvánvalóan csalárd e-maileket küld a domainjéről.

Hogyan állíthatja meg őket?

Megjegyzés: mellékelem a szabványos BIND formátumot egyszerű szövegben és egy képernyőképet arról, hogyan néz ki a bejegyzés a GoDaddy DNS-ben. A GoDaddyben a 301Moved.com legfelső szintű tartomány minden rekordja a “@” hosztot használja, az Ön hosztja valószínűleg más lesz. A gyakorlat során csak a kimenő levelekről fogok beszélni, arról nem, hogy hogyan kezeljük ezeket a szabványokat a külső feladóktól érkező bejövő levelekkel kapcsolatban.

Az SPF implementálása

Első lépés: A Google útmutatója az SPF rekordok konfigurálásához a Google Apps alkalmazással való működéshez jó kiindulópont. Ezen utasításokat követve hozzáadunk egy új TXT rekordot a nyilvános DNS-ünkhöz.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 A Moved is használja a Zendesket, egy jegykezelő rendszert, amely közvetlenül a domainről küld e-maileket. Meg kell győződnie arról, hogy onnan sem küldenek spameket.

Kettedik lépés: Keresse meg és adja hozzá a Zendesk SPF rekordját.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Fontos megjegyezni, hogy nem adunk hozzá egy második SPF rekordot, az tönkretenné a dolgokat; ehelyett egyetlen rekordba egyesítjük őket, így hosszabb lesz, ahogy több feladó kerül hozzá.

Figyelem: Tartományonként vagy altartományonként csak egy SPF rekordot adhatunk hozzá.

Azt is tudjuk, hogy a 301 Movednek van egy régi e-mail átjárója, amely néhány régi dolgot kezel, ezért adjuk hozzá az ő IP blokkjukat is. A 301 Moved az “IP4” mechanizmust használja az általa birtokolt IP-blokk meghatározására-198.51.100.0/24 (192.51.100.0-254).

A Dmarcian SPF Surveyor segítségével megtekintheti SPF rekordjait.

Harmadik lépés: Adja hozzá az egyes IPv4-címeket önmagukban, és a hálóblokkokat Classless Inter-Domain Routing (CIDR) jelöléssel. 198.51.100.0 egyetlen IP-címhez (nem kell /32) és 198.51.100.0/24 alhálózatokhoz.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

A régi e-mail átjáró hozzáadása biztosítja, hogy az átjáróról kimenő levelek SPF-engedélyezettek legyenek.

A fenti mechanizmusok a leggyakrabban használtak, de összesen nyolc van – beleértve a furcsa és elavultakat is. Ezek a mechanizmusok csak az egyezés hatókörét határozzák meg, magukat az akciókat nem.

A következő szakaszban található minősítőkben a PASS, SOFTFAIL és FAIL lehet definiálni – egy egyezés a három (PASS, SOFTFAIL és FAIL) akció egyikének kiváltását eredményezi.

• ALL:
• A: Ha a tartománynév rendelkezik olyan címrekorddal (A vagy AAAA), amely feloldható a feladó címére, akkor az megfelel.
• IP4: Ha a feladó egy adott IPv4-címtartományban van, akkor az megfelel.
• IP6: Ha a feladó egy adott IPv6-címtartományban van, akkor az megfelel.
• MX: Ha a tartománynév rendelkezik a feladó címére feloldó MX rekorddal, akkor egyezni fog (azaz a levél a tartomány egyik bejövő levelező szerveréről érkezik).
• PTR: Ha az ügyfél címének tartományneve (PTR rekord) az adott tartományban van, és a tartománynév feloldódik az ügyfél címére (forward-confirmed reverse DNS), akkor egyezni fog. Ez a mechanizmus elavult, és a továbbiakban nem használható.
• EXISTS: Ha az adott tartománynév bármilyen címre feloldódik, akkor egyezni fog (függetlenül attól, hogy milyen címre oldódik fel). Ezt ritkán használják. Az SPF makrónyelvvel együtt összetettebb egyezéseket kínál, mint például a DNSBL-lekérdezések.
• INCLUDE: Ha az included (téves elnevezés) házirend átmegy a teszten, akkor ez a mechanizmus megfelel. Ezt általában egynél több ISP házirendjének bevonására használják.

A következő a minősítők. Ezeket millióféleképpen lehet kombinálni egy feketelista és/vagy egy fehérlista modellel, de a mi céljainkra itt csak a fent említett három keresési mechanizmust fogjuk felvenni egyetlen minősítővel a végén, hogy fehérlistát készítsünk. A négy minősítőnk a következő:

• + a PASS eredményhez. Ez elhagyható; pl. +mx ugyanaz, mint mx.
• ? a NEUTRAL eredményhez, amit úgy értelmezünk, mint NONE (nincs irányelv).
• ~ (tilde) a SOFTFAIL-hez, ami a NEUTRAL és a FAIL közötti hibakeresést segíti. Általában a SOFTFAIL-t visszaadó üzeneteket elfogadják, de megjelölik őket.
• – (mínusz) a FAIL esetén, a levelet el kell utasítani (lásd alább).

Negyedik lépés: Alkalmazza a SOFTFAIL házirendet.

Egyelőre a 301 Moved a tilde-ot használja a SOFTFAIL-hez. A tilde használatával minden olyan levél, amely nem felel meg a Google, a Zendesk vagy az említett IP-blokknak, SOFTFAIL lesz. A levelek továbbra is kézbesítésre kerülnek, de valószínűleg a Spam vagy a Junk mappába kerülnek. Ez azonban teljes mértékben a címzett levelezőszerverén múlik. Ezt semmilyen szabvány nem határozza meg.

A “-” (mínusz) ebben a helyzetben a nem megfelelő levelek teljes mértékben SIKERESNEK (és valószínűleg visszapattannak). Ezt akkor kapcsolhatod be, ha egyszer elkezded jobban átlátni a kimenő leveleidet (várj a DMARC-ra), és ha már jobban megbarátkoztál a levelezési infrastruktúráddal.

Az SPF azért nagyszerű, mert nem kell módosítani magukat a levelezőszervereket. A fejlécek ugyanazok maradnak. Csak egy egyszerű TXT rekord (a tényleges, dedikált SPF rekordtípus sosem volt annyira népszerű, és ma már elavult), és utasíthatja a világ legtöbb levelezőszerverét, hogy ki villogtassa a nevét.

A nap végén a fogadó SMTP szerver ellenőrzi a feladó IP címét az Ön SPF rekordjával, amelyet lekérdezett, majd az Ön utasításai alapján alkalmazza a házirendet. Más szóval, Ön felhatalmazza magát és a szolgáltatóit, hogy (többnyire) megbízható leveleket küldjenek, mivel nyilvánosságra hoz egy hozzáférés-vezérlési listát (ACL).

Az üzenetek azonban még mindig módosulhatnak útközben, és a ravasz hamisítók és adathalászok néhány érdekes módon megkerülhetik az SPF-et (ez talán egy másik nap témája). Ez az SMTP: a végponttól végpontig tartó TLS nem garantált, ezért mindig tiszta szövegű üzenetet kell feltételeznünk. Az üzeneteket meg lehet hamisítani vagy meghamisítani.

De lépj be a színpadra jobbra…

Implementing DomainKeys Identified Mail

A levelek küldésekor a 301Moved.com aláírja (titkosítás nélkül) a leveleket a privát kulccsal. Mostantól kezdve az üzenet bármilyen módosítása, beleértve a testet, a fejléceket vagy a csatolmányokat, megtöri az aláírást és érvénytelenné teszi az üzenetet. Ismét a Google-t keressük, az ő cikküket használva Email hitelesítése DKIM

Ötödik lépés: Adjuk hozzá a nyilvános kulcsot a DNS rekordhoz.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Minden DKIM rekordnak egyedi szelektor előtagja van, ami azt jelenti, hogy egynél többet is közzétehetünk. Ahelyett, hogy egyetlen rekordba kombinálnánk őket, mint az SPF esetében tettük, használhatunk egyedi szelektorokat, és annyi nyilvános kulcsot tehetünk közzé, amennyire szükségünk van. Ez lehetővé teszi számunkra, hogy nagyszámú DKIM-engedélyezett kiszolgálót adjunk hozzá felső korlátok nélkül.

Láthatja, hogy a fenti előtag a “google”, az alapértelmezett, amelyet a Google Apps használ, amikor DKIM rekordot generál a közzétételhez. Ezt megváltoztathatja a Google-ban, és a legtöbb más beállításban is, így ha a “dkimawesome” előtagot szeretné, semmi sem akadályozza meg.

Egyes felhőszolgáltatók másképp csinálják. Ahelyett, hogy egyedi kulcspárokat generálnának minden egyes felhőbérlő számára, az összes kimenő levelet az összes tartomány számára ugyanazzal a kulccsal írják alá – miközben a kulcsuk helyett egy kanonikus nevet (CNAME) kell közzétenned.

A Zendesk ezt csinálja, mi két különböző kulcsot CNAME-zünk a DNS-ünkön az ő DNS-ükre. A Zendesknek van egy nagyszerű súgócikke- Digitally signing your email with DKIM or DMARC (Plus and Enterprise)

Schatodik lépés (ha alkalmazható): CNAME a kulcsokat a DNS-ünkön az ő DNS-ükre. Minden DNS-lekérdezést, amely a zendesk1._domainkey.301Moved.com címet keresi, a DNS átirányítja a zendesk1._domainkey.zendesk.com címre. A Zendesk ezután közvetlenül kiszolgálja a DKIM-kulcsokat.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Az nslookup eszköz (Unix vagy Windows esetén) helyi használatával megnézhetjük, hogyan néz ez ki más szerverek számára.

Nem minden kimenő feladó támogatja a DKIM-et. A Google Apps nyilvánvalóan támogatja, de a régi levelezőszerverek esetleg nem.

Tartományalapú üzenethitelesítés, jelentéskészítés és megfelelőség megvalósítása

ADMARC, vagyis a tartományalapú üzenethitelesítés, jelentéskészítés és megfelelőség az utolsó eszközünk a rosszindulatú e-mailek elleni küzdelemben. A figyelő levelezőszerverek számára a DMARC, továbbítja az SPF és a DKIM kezelését, valamint azt, hogy hogyan számoljon be Önnek, így a kézbesítési arányok és a rekordok megfelelőségének nagyon szükséges átláthatóságát biztosítja.

És igen, a DMARC egy újabb TXT rekord.

Hetedik lépés: Állítson be egy DMARC-házirendet, azonosítsa a mailto címet, állítsa be az igazítási módot, és határozza meg az üzenetek azon százalékát, amelyekre a házirendet alkalmazni kell (ne aggódjon, ez egyszerűbb, mint amilyennek hangzik).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

A fenti házirendet p=none néven jelöltük. Egyelőre egyáltalán nem módosítjuk a levéláramlást – egyszerűen csak beállítjuk a házirendet és a hozzá tartozó jelentést. A cím, amelyre a DMARC-státuszról szóló XML-jelentéseket küldjük, a rua= jelöli.

A fogadó levelezőszerverek XML-mellékleteket küldenek, amelyek megmutatják, hogy az Ön tartományából érkező – és a magát annak valló – üzenetek hogyan teljesítették a legtöbb modern levelezőszerver által előírt SPF-, DKIM- és DMARC-követelményeket.

E jelentések borítékonként mutatják, hogy az SPF megfelelt, nem felelt meg vagy nem felelt meg. Megmutatják, hogy a DKIM sikertelen, sikertelen igazítású vagy sikeres volt-e – és hogy a fenti irányelveket hogyan alkalmazták.

Végül ezek a jelentések mutatják az üzenet végső kézbesítési rendeltetését. Létezik néhány nagyszerű eszköz, amely segíthet ezek elemzésében. Még ha nem is alkalmazunk irányelveket az üzenetekre, ez olyan, mint a tűzfal, a DNS és az IDS/IPS naplók – mindig jó, ha van valami, amit vissza tudunk nézni.

Az adkim=r a DKIM relaxed igazítási módját adja meg, az “r” a relaxed, az “s” a strict módot jelenti. A laza mód lehetővé teszi a hitelesített DKIM d= tartományok számára, hogy egy közös szervezeti tartományon belül a levél fejléc-From: címben a DMARC-ellenőrzést átmenjenek. A szigorú mód megköveteli a DKIM d= tartomány és az e-mail fejléc-From címe közötti tökéletes egyezést. Gondoljon az aldomainekre, ha használja őket.

aspf=r pontosan ugyanezt teszi, kivéve az SPF-ellenőrzéseket.

A pct=100 az üzenetek százalékos aránya, amelyeket ténylegesen a DKIM-házirend szerint kezelnek. A véletlenszerűen kiválasztott fogadó levelezőkiszolgáló az Ön tartományából érkező üzeneteknek erre a százalékára érvényesíti a házirendet. Egyelőre 100-at használunk, mert egyelőre nem alkalmazunk házirendet.

A házirend alkalmazása előtt ezt ötre csökkentjük, hogy 20 üzenetből csak egynél alkalmazzák a házirendet, mivel a p= házirendjelzőt karanténba vagy elutasításra állítjuk. Így, ha teljesen elszúrjuk, az e-mailek 95%-a még mindig kézbesítve lesz, ahelyett, hogy 0% lenne, ha pct=100-nál kezdenénk.

A DMARC-ellenőrzést vagy a fent beállított adkim= és aspf= igazítási módokat nem teljesítő üzeneteket a fentiekhez hasonlóan karantén házirend esetén puhán visszautasítjuk, vagy teljesen visszautasítjuk, ha elutasításra állítjuk.

Nagyon fontos megjegyezni, hogy a DMARC akkor PASSolja az üzenetet, ha az SPF vagy a DKIM megfelel, és csak akkor FAILolja az üzenetet, ha az SPF és a DKIM is FAIL. Így a csak SPF és a csak DKIM üzenetek átmehetnek a DMARC-on, de az SPF/DKIM nélküli üzenetek mindig meghiúsulnak. Ez nagyszerű hír, ha olyan levelezőrendszere van, amely csak SPF-et vagy csak DKIM-et támogat.

A Dmarcian DMARC Inspector segítségével megtekintheti a DMARC rekordjait.

A Dmarcian egy fizetős eszköz, amely lehetővé teszi a DMARC-jelentések egyszerű kezelését, sok más is van, de a Dmarcian történetesen az én kedvencem.

Frissítés: Kaptunk néhány (DMARC-kompatibilis!) e-mailt, amelyekben az aldomain policy sp=none-ról kérdeztek. Az sp=none-t tartalmazó házirenddel nem adsz meg DMARC-házirendet egyetlen aldomainre sem. Ezt manuálisan kell megtenni egy megfelelő DMARC rekord beállításával minden egyes aldomainhez, vagy a fő DMARC rekordban egy sp=quarantine vagy sp=reject kapcsolóval.

Minimális konfiguráció

Ha ki akarja próbálni, azt javaslom, hogy kezdje nagyon nyíltan, és maradjon egyszerű, amíg nincs elég DMARC-jelentés ahhoz, hogy elkezdjen bármit is érvényesíteni.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

A nagy szolgáltatókat “include:”-vel, az IP-blokkokat pedig “IP4”-el vagy “IP6”-al határozza meg, ahonnan levelet küldhet. Használja az “MX”-et a bejövő levelező szerverek engedélyezéséhez. És hacsak nem közvetlenül ugyanarról a dobozról/szerverről küldesz levelet, amelyik a weboldaladnak ad otthont (egyébként rossz, rossz gyakorlat), akkor kihagyhatod a fent említett “A” mechanizmust. A “?” nem alkalmaz semmilyen irányelvet az üzeneteidre, de kiadja az SPF rekordodat, hogy a DMARC felismerje azt.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Kérd a megfelelő szelektor, ebben az esetben a “google”, és a megfelelő kulcsot. Ne feledje, több kulcsot is közzétehet.

Megjegyzés: Kérjük, ne tegye közzé ezt a tényleges kulcsot, különben képes leszek DKIM-jelezni a leveleit.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

A DMARC esetében nem alkalmazunk házirendet, laza üzemmódban vagyunk, de kérjük, hogy az XML-jelentéseket egy olyan postafiókba küldjék, amelyhez hozzáférhetünk. Innen a DMARC meglehetősen gyors (nem valós idejű) visszajelzést ad arról, hogy hogyan szigoríthatjuk a különböző házirendeket mindhárom rekordban.

De várj, mi van a TLS-szel?

A Transport Layer Security vagy TLS nem része a DMARC-szabványnak, és nem is DNS-rekord.

Ehelyett a TLS csak egy felnőtt Secure Socket Layer (SSL), amelyet a levelezőszerverek nyilvános kapcsolatokon keresztül használhatnak az üzenetek egymásnak történő továbbítására. Ez az SMTP TLS-be csomagolva, ahogyan sok más dolgot is meg lehet csinálni TLS-en belül/felül – a SNMP TLS-en keresztül és az FTP TLS-en keresztül gyakori példák. A TLS csak útközben titkosítja az üzeneteket, nyugalmi állapotban nem.

Ha egy DKIM-jelzett üzenetet TLS-en keresztül küldünk, az egész életében alá van írva, de csak akkor titkosítva, amikor a Google Apps-tól a Cisco Ironportig, vagy bárhol is haladjon át a levelünk. A TLS egészen biztosan nem védi a nyugalmi állapotban lévő üzeneteket, bár a webmailhez való HTTPS:// munkamenethez is használják, amikor ugyanazt az üzenetet olvassa, de ez is csak átvitel közben történik.

A TLS-t mindenhol érdemes használni, ahol csak lehetséges, de arra is készen kell állnia, hogy más nyilvános levelezőrendszerekkel tiszta szövegben beszéljen. Egyes levelezőszerverek még 2015-ben sem támogatják a STARTTLS-t (a TLS kézfogás megkezdésének szervernyelvén).

A Google Appsban egy egyszerű konfigurációs módosítással kikényszerítheti a TLS használatát bizonyos külső tartományok esetében. Jó dolog bekapcsolni a kapcsolódó külső vállalkozások, partnerek és más szervezetek számára, de csak akkor érvényesítse a TLS-t, ha biztos benne, hogy megbízható és az adott tartomány összes levelezőkiszolgálója támogatja.

Az e-mail biztonság fontossága és a feladói csalások elkerülése

Függetlenül attól, hogy Ön veterán informatikai rendszergazda vagy csak most kezdte, ez a három szabvány ugyanolyan fontos. Kétségtelen, hogy az egyes szabványok mi a dolguk, és hogyan működnek együtt, kissé zavaros lehet, de a bevezetésük viszonylag egyszerű – és az előnyök megérik az idejét.