Bevezetés
Ezt a kurzust 2023 áprilisában tartottam, reveal.js diák formájában a korábbi blogomon. Most cikként hozom vissza, frissítve, az eredeti diák pedig a cikk végén továbbra is elérhetők.
A program: megérteni, miért sérülékeny csatorna az e-mail, majd beállítani az SPF-et, a DKIM-et, a DMARC-ot és a BIMI-t, végül mindezt letesztelni.
Miért nem biztonságos az e-mail
Az SMTP protokoll abból a korból származik, amikor mindenki megbízott mindenkiben:
- semmi sem hitelesíti a feladót: bárki küldhet e-mailt
From: [email protected]fejléccel; - a szállítási titkosítás (STARTTLS) opportunista, és nem védi végponttól végpontig az üzenetet;
- így könnyű egy identitást meghamisítani adathalászathoz vagy spamhez.
A védekezéshez a fogadó szerverek hírnevet számolnak: a küldő IP-cím, a domain és az üzenet tartalma alapján. Kérhetik azt is, hogy a feladó később próbálkozzon újra (greylisting).
A közvetlen következmény: megfelelő beállítás nélkül az e-mailjeid több percig is utazhatnak, a spamben landolhatnak, vagy meg sem érkeznek.
2024 februárja óta a Gmail és a Yahoo minden feladótól legalább SPF-et vagy DKIM-et követel meg, a tömeges küldőktől (napi 5000-nél több e-mail a Gmail felé) pedig SPF-et, DKIM-et és DMARC-ot. Ez már nem opcionális.
SPF: Sender Policy Framework
Az SPF (RFC 7208) lehetővé teszi, hogy a DNS-ben megadd, mely IP-címek küldhetnek e-mailt a domained nevében. A fogadó szerver ezzel a listával veti össze a feladó IP-címét.
Az SPF rekord egy egyszerű TXT rekord (az SPF DNS típus elavult):
ilogus.dev. IN TXT "v=spf1 include:_spf.google.com ~all"
v=spf1: a verzió;include:: egy másik domain IP-listáját fűzi hozzá (az e-mail szolgáltatódét);ip4:/ip6:/a/mx: konkrét IP-ket, vagy az A és MX rekordok IP-it engedélyezik;~all: minden más softfail (gyanús). A-allszigorú elutasítás, a?allsemleges.
Néhány betartandó szabály:
- Domainenként csak egy SPF rekord lehet: ha kettő van, az SPF hibát ad.
- Összesen legfeljebb 10 DNS lekérdezés (
include,a,mx…), különben az SPF szintén hibát ad. - Vedd számba az összes küldő szolgáltatásodat: levelezés, hírlevélküldő, alkalmazás, CRM…
A rekordot a MxToolbox SPF eszközzel tesztelheted.
DKIM: DomainKeys Identified Mail
A DKIM (RFC 6376) egy privát kulccsal aláírja az e-maileket. A nyilvános kulcs a DNS-ben van közzétéve, és a fogadó szerver ezzel ellenőrzi, hogy az üzenet valóban a domainedről jön, és útközben nem módosították.
A legtöbb szolgáltató (Google Workspace, Microsoft 365, Brevo…) legenerálja helyetted a kulcsot, és megadja a létrehozandó rekordot. Ha saját küldő szervert üzemeltetsz, OpenSSL-lel is generálhatod:
openssl genrsa -out dkim_private.pem 2048
chmod 600 dkim_private.pem
Ezután kinyerjük a nyilvános kulcsot base64 formátumban, a DNS-hez előkészítve:
openssl rsa -in dkim_private.pem -pubout -outform der 2>/dev/null | openssl base64 -A
A kulcs egy szelektor alatt kerül közzétételre, így több kulcsod is lehet (szolgáltatásonként egy, vagy rotációhoz). Például a könyvelési osztály számára:
accounting._domainkey.ilogus.dev. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
v: a verzió;k: a kulcs algoritmusa;p: a nyilvános kulcs base64-ben.
Teszteld a MxToolbox DKIM eszközzel, megadva a domaint és a szelektort.
DMARC: a szabályzat, amely mindent összeköt
A DMARC szabályzat lehetővé teszi a feladónak, hogy jelezze: e-mailjeit SPF és/vagy DKIM védi, és megmondja a címzettnek, mit tegyen, ha ezek az ellenőrzések nem sikerülnek.
A DMARC (RFC 7489) bevezeti az illeszkedés (alignment) fogalmát: nem elég, ha az SPF vagy a DKIM sikeres, az ellenőrzött domainnek egyeznie kell a From fejlécben látható domainnel. Ez akadályozza meg valóban a hamisítást. Ráadásul jelentéseket is kapsz a nevedben küldött e-mailekről.
A rekord a _dmarc aldomainre kerül:
_dmarc.ilogus.dev. IN TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected]"
p: a szabályzat hiba esetén:none(megfigyelés),quarantine(spam),reject(elutasítás);adkim/aspf: DKIM és SPF illeszkedés,r(laza, az aldomainek elfogadottak) vagys(szigorú);rua: az összesített jelentéseket fogadó cím (amailto:kötelező).
A helyes módszer: kezdj p=none beállítással, olvasd a jelentéseket néhány hétig, hogy kiderüljenek az elfelejtett szolgáltatások, majd válts quarantine-ra, végül reject-re. A Cloudflare nagyon jól elmagyarázza a DMARC rekordot.
Ellenőrizd a MxToolbox DMARC eszközzel.
BIMI: a logód a beérkező levelek között
A BIMI (Brand Indicators for Message Identification) megjeleníti a márkád logóját az e-mailjeid mellett a postafiókban. Az elv a tanúsítványokhoz hasonló: a logót egy harmadik fél tanúsíthatja.
Előfeltételek:
- DMARC
p=quarantinevagyp=rejectbeállítással (nemnone); - egy SVG Tiny PS formátumú logó, HTTPS-en kiszolgálva;
- a Gmailhez és az Apple Mailhez egy VMC (Verified Mark Certificate, bejegyzett védjegyet igényel), vagy 2024 óta egy könnyebben megszerezhető CMC (Common Mark Certificate). Évente több száz euróval kell számolni, VMC esetén jóval 1000 euró felett.
Tanúsítvány nélkül is lehetséges egy „önbevallásos” BIMI. Kevesebb levelezőkliens veszi figyelembe, de jó kezdet:
default._bimi.ilogus.dev. IN TXT "v=BIMI1; l=https://ilogus.dev/bimi/logo.svg;"
Az e-mailek tesztelése
Ha minden be van állítva, teszteld az elemeket egyenként, vagy egyszerre:
- a MxToolbox Deliverability az összes rekordot ellenőrzi;
- a mail-tester.com egy tesztcímre küldött valódi e-mailt elemez: a hitelesítést, de a HTML tartalmat, a linkeket és a hírnevet is;
- parancssorból a
digis elég a közzétett rekordok ellenőrzéséhez:
dig +short TXT ilogus.dev
dig +short TXT _dmarc.ilogus.dev
dig +short TXT accounting._domainkey.ilogus.dev
A kurzus diái
Íme a kurzus eredeti diái (angolul). A nyilakkal vagy a szóközzel navigálhatsz, vagy megnyithatod teljes képernyőn.
Összegzés
Az SPF megmondja, ki küldhet, a DKIM bizonyítja, hogy az üzenet hiteles, a DMARC megmondja, mi a teendő hiba esetén, és tájékoztat róla, a BIMI pedig kiemeli a logódat, ha minden más már szilárd. Néhány jól beállított DNS rekord, és az e-mailjeid végre oda érkeznek, ahová kell.