E-mail kézbesítés biztosítása

A CloudERP az ügyfelek (azaz a CloudERP-t használó cégek) nevében kimenő e-maileket az ügyfél saját SMTP kiszolgálóján keresztül küldi. Ennek következtében a feladó domain kézbesítését, hitelesítését (pl. SPF, DKIM, DMARC) az ügyfél DNS-beállításai határozzák meg.

Ha nincs SPF vagy DMARC rekordunk, illetve DKIM aláírásunk, akkor elsőként egyeztessünk a levelezőrendszerünk üzemeltetőjével, vagy tekintsük át a szolgáltató dokumentációját – és ugyanezt tegyük minden olyan rendszerrel kapcsolatban, amely e-mailt küldhet a nevünkben –, annak érdekében, hogy biztosítsuk a levelek hitelesítését és megbízható kézbesítését.

DKIM aláírás a CloudERP esetében

A CloudERP alapértelmezetten DKIM aláírást helyez el a kimenő leveleken. Ennek hiteleségéhez az ügyfél DNS-zónájában egy CNAME rekordot kell létrehozni, amely a CloudERP DKIM kulcsára mutat.

Szükséges DNS rekord:

app._domainkey.[sajat-domain].    IN    CNAME    app._domainkey.clouderp.hu.

A [sajat-domain] helyett a saját domain neved kerül (pl. example.com esetén):

app._domainkey.example.com.    IN    CNAME    app._domainkey.clouderp.hu.

Ez lehetővé teszi, hogy a fogadó szerverek az app._domainkey.clouderp.hu alatt tárolt nyilvános kulccsal ellenőrizzék a DKIM aláírást, amit a CloudERP ad az e-mailekhez.

Mivel az e-mailek a saját SMTP kiszolgálón keresztül kerülnek kiküldésre, a CloudERP-t nem kell szerepeltetni az SPF rekordban.

DKIM aláírás letiltása

Ha az SMTP szerver valamilyen művelet (pl. vírusellenőrzés) során módosítja a levél tartalmát, az a DKIM aláírást érvénytelenné teheti. Ilyen esetben javasolt a CloudERP-ben az adott üzenetküldési szabálynál a "DKIM aláírás kikapcsolása" opció bekapcsolása.

Ellenőrzés és tesztelés

Az e-mail hitelesítési beállításainkat (SPF, DKIM, DMARC) könnyen ellenőrizhetjük, ha küldünk egy teszt e-mailt a ping@tools.mxtoolbox.com címre. A rendszer automatikusan válaszol egy részletes elemzéssel, amely tartalmazza többek között:

• az SPF és DKIM rekord ellenőrzésének eredményét,
• a DMARC állapotot,
• a feladói fejlécek és aláírások elemzését,

---

SPF

Sender Policy Framework

Az SPF (Sender Policy Framework) egy e-mail hitelesítési módszer, amely azt határozza meg, mely szerverek küldhetnek e-mailt egy adott domain nevében.

Célja, hogy megakadályozza, hogy illetéktelenek az adott domain nevében küldjenek hamis leveleket, illetve rendelkezik arról, hogy a nem jogosult küldők leveleivel mi történjen.

Az SPF úgy működik, hogy amikor egy e-mailt fogadó szerver megkap egy levelet, megnézi, melyik IP-címről érkezett, majd lekérdezi a feladó domainjének DNS-éből az SPF rekordot. Ebben a rekordban szerepel, hogy mely szerverek küldhetnek érvényesen e-mailt az adott domain nevében. Ha a küldő IP-címe szerepel ebben a listában, az SPF ellenőrzés sikeres, különben sikertelen, és a levél könnyen spamként végzi.

RFC 7208 datatracker.ietf.org/doc/html/rfc7208

Használat

Ha azt szeretnénk, hogy csak az MX, valamint az A (és/vagy AAAA) rekordokban megadott szerverek küldhessenek e-mailt (általános eset), akkor azt így adhatjuk meg:

@   IN  TXT  "v=spf1 a mx -all"

Mechanizmusok

a[:aldomain]

Az adott domain A és/vagy AAAA rekordjaiban lévő IP-címek (kiszolgálók). Opcionálisan megadható egy aldomain is. Pl.: a:srv2.example.com

mx

Az adott domain MX rekordjában megadott kiszolgálók (IP-címük).

ip4:<ip>

Egy konkrét IPv4-cím, vagy IP-tartomány CIDR formátumban. Pl.: ip4:1.1.1.1

ip6:<ip>

Egy konkrét IPV6 cím vagy IP tartomány CIDR formátumban Pl.: ip6:2606:4700:4700::1111

include:<domain>

Egy másik domain SPF rekordjának beemelése. Pl.: include:spf.example.net

redirect=<domain>

Átirányítás egy másik domain SPF rekordjára. Csak önállóan használható, más mechanizmus nem lehet mellette. pl.: redirect=example.com

all

Minden más forrás, amelyet nem említettünk külön. Elé kerül egy kvalifikátor, amely meghatározza az elbírálást. pl.: ~all

Kvalifikátorok: + Pass Elfogadás (alapértelmezett, nem szükséges használni) - Fail Elutasítás – biztosan nem megbízható küldő ~ SoftFail “lágy” elutsítás, általában SPAM-ként van kezelve ? Neutral – a fogadó szerver dönti el

Ha nem csak a saját levelezőrendszerünk küld e-maileket a nevünkben, hanem például hírlevélküldőt, CRM rendszert, vagy más szolgáltatást használunk, akkor jellemzően ezek SPF rekordját is bele kell foglalnunk a saját rekordunkba – include: segítségével, vagy ha ismert az IP-cím, akkor ip4:/ip6: megadásával.

Korlátozások

Egy SPF rekordban legfeljebb 10 DNS-lekérdezés történhet (például include, a, mx, exists, ptr, redirect). Ez a korlátozás nem vonatkozik a ip4:, ip6:, és all mechanizmusokra, mivel ezek nem igényelnek DNS-feloldást.

Egy domainnévhez csak egy SPF TXT rekord lehet. Ha több van, az eredmény nem meghatározott (várhatóan hiba).

Az aldomainek rendelkezhetnek saját SPF rekorddal, vagy átirányíthatók a fő domain SPF rekordjára:

srv1.example.com.   IN  TXT  "v=spf1 redirect=example.com"

---

DKIM

DomainKeys Identified Mail

A DKIM (DomainKeys Identified Mail) egy e-mail hitelesítési technológia, amely digitálisan aláírja az e-mailt a küldő domain nevében.

Célja, hogy biztosítja, hogy a levél nem lett módosítva útközben, és valóban a megadott domain küldte.

A DKIM úgy működik, hogy a küldő szerver egy privát kulccsal digitálisan aláírja az e-mail bizonyos részeit, például a fejlécet és a tartalmat. A címzett szerver ezután a domain DNS-ében található publikus kulcs segítségével ellenőrzi az aláírás érvényességét, így megbizonyosodhat arról, hogy az üzenet valóban a megadott domaintől származik, és nem módosították útközben.

RFC 6376 datatracker.ietf.org/doc/html/rfc6376

Használat

A DKIM működéséhez a domain DNS-zónájába egy TXT rekordot kell felvenni, amely a publikus kulcsot tartalmazza. A rekord neve a DKIM aláírásban megadott szelektor és a domain alapján épül fel:

selector._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

Egy domain több DKIM szelektort is használhat egyszerre, például különböző aláírásokat különböző rendszerekhez (hírlevél, CRM, stb.), ilyen esetben a külső rendszer DKIM mezőjére mutataó CNAME-rekordot hozunk létre általában.

selector._domainkey.example.com.	3600	IN	CNAME	selector._domainkey.example.net.	

DNS rekord

v=DKIM1

A DKIM rekord verziója. Jelenleg mindig DKIM1.

k=<key_type>

A használt kulcstípus. A legtöbb esetben rsa, újabb eseteknél lehet ed25519 is (RFC 8463).

p=<public_key>

A publikus kulcs Base64 formátumban. A fogadó szerver ezt használja az aláírás ellenőrzésére.

Aláírás

A küldő szerver az e-mail fejlécébe beszúr egy DKIM-Signature: sort, amely tartalmazza az aláíráshoz szükséges paramétereket. A fogadó szerver ezt használja az aláírás ellenőrzéséhez.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail1;
 c=relaxed/simple; q=dns/txt; t=1648579200;
 h=from:to:subject:date;
 bh=X9QfbLE...;
 b=IvYWLqPyz...;

v=1

A DKIM szabvány verziója (jelenleg mindig 1)

a=<algorithm>

Az aláíráshoz használt algoritmus (általában rsa-sha256)

d=<domain>

A domain, amely nevében az aláírás történt

s=<selector>

A szelektor, amely meghatározza, hogy a mail1._domainkey.example.com rekordban kell keresni a publikus kulcsot

c=<canonicalization>/<canonicalization>

A kaninizálási szabály, a fejléchez és a törzsszöveghez, hogy hogyan kezelje a szóközöket, sortöréseket aláírás előtt. Pl.: relaxed/simple

s=<selector>

A szelektor, például mailamely meghatározza, hogy a mail1._domainkey.example.com rekordban kell keresni a publikus kulcsot.

t=<timestamp>

Az aláírás UNIX időbélyege Pl.: t=1648579200

h=<headers>

Az aláírt fejlécek listája, Pl.: h=from:to:subject:date

bh=<hash>

A törzsszöveg (body) hash-e, Base64 formátumban

b=<signature>

Az üzenethez tartozó digitális aláírás

Kanonizáció – c= mező

A kanonizációs szabályok azt határozzák meg, hogyan kezelje az aláírás a szóközöket, sortöréseket és más formázási eltéréseket az e-mail fejlécében és törzsében. A c= mező két értéket tartalmazhat: az első a fejlécre, a második a törzsszövegre vonatkozik:

c=relaxed/simple

simple

Szigorú mód – bármilyen formázásváltozás (extra szóköz, sortörés) megtöri az aláírást.

relaxed

Megengedő mód – több szóköz egységesítése, kis- és nagybetűk figyelmen kívül hagyása a fejlécnevekben, sorvégi szóközök eltávolítása.

Fejléc	Törzs	Beállítás	Megjegyzés
simple	simple	c=simple/simple	Teljesen szigorú – nem tűr formázást
relaxed	simple	c=relaxed/simple	Ajánlott – jó kompromisszum
relaxed	relaxed	c=relaxed/relaxed	Engedékeny – ha a body-t is módosíthatják

---

DMARC

Domain-based Message Authentication, Reporting and Conformance

A DMARC (Domain-based Message Authentication, Reporting and Conformance) egy e-mail hitelesítési szabvány, amely az SPF és DKIM eredményeire épül.

Célja, hogy megakadályozza, hogy mások a domain nevében küldjenek hamis (pl. adathalász) e-maileket, és lehetőséget ad arra, hogy a domain tulajdonosa jelentéseket kapjon a kézbesítési és hitelesítési problémákról.

A DMARC (Domain-based Message Authentication, Reporting and Conformance) úgy működik, hogy a fogadó szerver az e-mail feladó domainjének DNS-éből lekér egy DMARC rekordot, amely meghatározza, hogy az SPF és/vagy DKIM hitelesítések sikeressége esetén hogyan kell eljárnia. A DMARC előírja, hogy az e-mail csak akkor legyen elfogadott, ha legalább az egyik hitelesítés sikeres, és az e-mail címből származó domain egyezik a hitelesítést végző domainnel (ez az úgynevezett “alignment”). Emellett a DMARC lehetőséget ad arra is, hogy a domain tulajdonosa visszajelzést (riportokat) kapjon a sikertelen hitelesítési kísérletekről.

RFC 7489 datatracker.ietf.org/doc/html/rfc7489

Használat

A DMARC rekordot a domain DNS zónájába kell felvenni, TXT típusként, a következő néven:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s; adkim=s; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"

Kötelező mezők

v=DMARC1

A DMARC verzió (jelenleg mindig DMARC1)

p=none|quarantine|reject

A házirend, amely meghatározza, mit tegyen a fogadó fél a sikertelen levelekkel:

• none – ne tegyen semmit, csak jelentést küldjön
• quarantine – helyezze karanténba (pl. spam mappába)
• reject – utasítsa el a levelet kézbesítés előtt

Gyakori, opcionális mezők

rua=mailto:...

Aggregate report (összesített jelentés) fogadási címe. Napi jelentések az SPF/DKIM/DMARC eredményekről.

ruf=mailto:...

Forensic report (eseti jelentés) címe. Részletes jelentést kér minden egyes hibás levélről. (Nem minden rendszer támogatja.)

pct=100

A házirend érvényesítése a levelek hány százalékára vonatkozzon (pl. pct=50 → 50%-ban alkalmazza a szabályt).

aspf=s|r

SPF domain illesztési szigorúság:

• s – strict (csak teljes egyezés)
• r – relaxed (aldomain is elfogadott)

adkim=s|r

DKIM domain illesztési szigorúság:

• s – strict (csak teljes egyezés)
• r – relaxed (aldomain is elfogadott)

sp=none|quarantine|reject

Aldomain-ekre vonatkozó külön házirend. Ha nincs megadva, az alapértelmezett p= érték lesz érvényes az aldomainekre is.

fo=0

Ez határozza meg, hogy milyen esetben küldjön a levelezőszerver eseti, részletes (RUF) jelentést: 0 Csak akkor küld jelentést, ha SPF és DKIM is megbukik 1 Ha akár az SPF, akár a DKIM megbukik d DKIM aláírás hiba esetén (pl. aláírás nem ellenőrizhető) s SPF hiba esetén (pl. SPF fail vagy alignment hiba)

rf=afrf

Ez határozza meg, hogy a forenzikus jelentés (amit a ruf= mezőbe küld) milyen formátumban érkezzen.

• afrf Authentication Failure Reporting Format – ez az alapértelmezett, gépileg feldolgozható formátum (RFC 6591)
• iodef Incident Object Description Exchange Format – ritkábban használt, bonyolultabb biztonsági riportformátum (XML)

ri=86400

86400 másodperc = 1 nap, tehát a jelentéseket napi rendszerességgel kéred. Elméletben beállíthatnál rövidebb időt is (pl. 3600 = 1 óra), de:

• A legtöbb szolgáltató naponta egyszer küld összesítést (ri=86400);

• Ezt figyelmen kívül hagyhatják, ha túl sok adat gyűlik össze.

Az ri= mezőben megadható hosszabb időintervallum is, de ezt a szolgáltatók nem minden esetben veszik figyelembe.