Álnevek, átirányítás és catch-all: hasznos, de kockázatos

Modul 3: A postafiókja kezelése · Olvasási idő: 11 perc

Tanulási cél: Ennek a leckének a végén tudni fogja, mikor válasszon postafiókot, álnevet, átirányítást vagy catch-all beállítást, és el tudja magyarázni, miért árthat a levelei kézbesítésének a külső címre történő átirányítás és a catch-all beállítás.

Kulcsfogalmak: postafiók, álnév, forwarder (átirányítás), belső és külső átirányítás, az SPF megszakad átirányításnál, SRS (Sender Rewriting Scheme), DKIM átirányításnál, ARC (RFC 8617), catch-all, szótáralapú támadás, backscatter, levélküldés más cím nevében

Négyféle módon működtethető egy cím

Ha szeretné, hogy az offerte@example.com cím működjön, négy lehetőség közül választhat:

Egyes vezérlőpultokban az álnév technikailag ugyanaz, mint egy, ugyanazon a szerveren lévő címre mutató átirányítás. A lényegi különbség a következő: a levél ugyanazon a szerveren marad, vagy kifelé megy?

Átirányítás a saját domainjén belül: nem probléma

Ha az offerte@example.com címet átirányítja az info@example.com címre, és mindkettő ugyanazon a szerveren van, a szerver egyszerűen kézbesíti a levelet az info@ postafiókjába. Semmi nem megy ki az interneten, semmit nem ellenőriznek újra. Ez biztonságos és megbízható.

Átirányítás kifelé: itt romlik el

Más a helyzet, ha egy másik szolgáltatónál lévő címre irányít át, például egy Gmail- vagy Outlook.com-os magánemail-címre. Ilyenkor az Ön szervere újra elküldi a levelet, most már a Gmailnek. A Gmail pedig úgy ellenőrzi a levelet, mintha az Ön szerveréről érkezne.

Tegyük fel: a klant@example.net cím levelet küld az info@example.com címre. Az Ön szervere továbbítja a Gmailnek. Mit lát a Gmail?

• Feladó (From): klant@example.net.
• Boríték szerinti feladó (envelope-from): továbbra is klant@example.net, kivéve, ha az Ön szervere átírja azt.
• Küldő szerver: az Ön szervere, például 192.0.2.25.

A Gmail megnézi az example.net SPF-rekordját. Ott természetesen nem szerepel az Ön szervere. Az SPF elbukik. Ha az example.net domainnek p=reject DMARC-szabálya van, és a levélen nincs érvényes DKIM-aláírás, a Gmail elutasítja a levelet. Az Ön szervere bounce-üzenetet kap vissza, amely... az eredeti feladóhoz kerül, aki most az Ön szerverétől kap hibaüzenetet.

Három mechanizmus enyhíti ezt a problémát:

1. A DKIM (általában) túléli

A DKIM-aláírás (lecke 4.3) magában a levélben található. Ha az Ön szervere változtatás nélkül továbbítja a levelet, az example.net aláírása továbbra is helyes marad. A DMARC ekkor a DKIM alapján sikeresnek minősül, még akkor is, ha az SPF elbukik. Ezért olyan fontos a DKIM: ez az egyetlen, ami túléli az átirányítást.

De elromlik, ha az átirányító szerver módosítja a levelet: szöveget fűz hozzá alul ("továbbítva...."), módosítja a tárgyat ([SPAM] előtaggal), vagy átalakítja a formázást. Ilyenkor az aláírás már nem egyezik.

2. Az SRS átírja a boríték szerinti feladót

Az SRS (Sender Rewriting Scheme) segítségével az átirányító szerver a boríték szerinti feladót a saját domainjén lévő címre változtatja, például:

SRS0=HHH=TT=example.net=klant@example.com

Most a Gmail az example.com SPF-rekordját nézi meg, amelyben az Ön szervere valóban szerepel. Az SPF sikeres lesz. Ha bounce érkezik, az Ön szervere vissza tudja alakítani a címet, és el tudja küldeni a bounce-üzenetet a valódi feladónak.

Figyelem: az SRS megoldja az SPF-et, de a DMARC-ot nem. Az igazodás (alignment, lecke 4.4) a boríték szerinti feladó domainjét hasonlítja össze a From-címmel. Ez most example.com az example.net-tel szemben: nincs igazodás. A DMARC-nak tehát továbbra is a DKIM alapján kell sikeresnek lennie.

3. ARC: a közvetítő nyilatkozata

Az ARC (Authenticated Received Chain, RFC 8617, kísérleti jellegű) lehetővé teszi, hogy egy közvetítő rögzítse, mit látott: "amikor ez a levél hozzám megérkezett, az SPF, a DKIM és a DMARC is sikeres volt". Az átirányító szerver aláírja ezt a nyilatkozatot. A végső fogadó dönthet úgy, hogy megbízik ebben a nyilatkozatban, ha megbízik a közvetítőben. A nagy fogadók, mint a Gmail és a Microsoft, használják az ARC-ot, de nem lehet rá biztosan számítani: ez egy szívesség, nem egy jog.

És a spam?

Van még egy probléma, és ez gyakran a legnagyobb. Az Ön spamszűrője nem minden levelet szűr ki. Minden spam, amely átjut rajta, az Ön szervere most továbbküldi a Gmailnek. A Gmail szemszögéből úgy tűnik, mintha az Ön szervere küldene spamet. Ez súlyosan árt a szervere reputációjának (osztott tárhely esetén pedig az adott szerveren lévő összes ügyfél reputációjának). A Gmail ezután az Ön valódi leveleit is hamarabb sorolja a spam közé.

Mi a jobb megoldás?

Szeretné a céges leveleit a Gmail- vagy az Outlook-alkalmazásban olvasni? Adja hozzá a postafiókot IMAP-fiókként (2. modul). Az alkalmazás közvetlenül az Ön szerveréről tölti le a leveleket. Semmi nem kerül átirányításra, semmi nem bukik el, és nem jut ki spam. Ha mégis át kell irányítania, állítsa be szigorúra a spamszűrőt az átirányítás előtt.

Catch-all: miért szinte soha nem ajánlott

A catch-all minden nem létező címre érkező levelet elfog. Egy elgépelés, mint az inof@example.com, ilyenkor mégis megérkezik. Ez hasznosnak hangzik, de:

• Spam. A spammerek tömegesen küldenek leveleket kitalált címekre a meglévő domaineken (a.jansen@, sales2@, xkq7@). Ezt nevezik szótáralapú támadásnak. Catch-all nélkül a szervere ezeket azonnal elutasítja. Catch-all beállítással viszont minden megérkezik, gyakran napi több száz levél is.
• Nincs többé hibaüzenet. Aki eltéveszti a címét, nem kap bounce-üzenetet, és azt hiszi, hogy a levele megérkezett. Catch-all nélkül azonnal tudja, hogy a cím hibás.
• Az átirányítás tovább rontja a helyzetet. Egy Gmailre átirányító catch-all az összes ilyen spamet továbbküldi a Gmailnek.
• Backscatter. Egy szerver, amely előbb mindent elfogad, és csak később derül ki, hogy egy cím nem létezik, bounce-üzenetet küld a (hamisított) feladónak. Ezt nevezik backscatternek: hibaüzenetek ártatlan embereknek, és ez egy oka lehet annak, hogy letiltólistára kerüljön.

Szeretne elfogni néhány extra címet, például egy gyakori elgépelést vagy egy régi címet? Ehhez hozzon létre külön álneveket vagy átirányításokat. Ha weboldalanként vagy webáruházanként külön címet használ (webshop-x@), hogy lássa, ki adja tovább a címét? Hozza létre ezt a címet álnévként akkor, amikor használni kezdi.

Küldés álnévről

Egy álnév feladóként is használható. Előfordulhat, hogy offerte@example.com néven szeretne válaszolni, miközben info@ néven van bejelentkezve. Ez lehetséges, de:

• Számos levelezőszerver manapság ellenőrzi, hogy melyik feladói cím melyik bejelentkezéshez tartozik. Ilyenkor csak a saját címéről, valamint a postafiókjára mutató álnevekről vagy átirányításokról küldhet levelet. Egy tetszőleges másik cím elutasításra kerül ("account can not send emails from ..."). Ez védelmet nyújt a visszaélések ellen.
• A levelezőprogramban az álnevet további identitásként adja hozzá (Thunderbird: Azonosságok kezelése; Apple Mail: a fiókhoz tartozó további címek, vesszővel elválasztva; Outlook: a Feladó mező megjelenítése és a cím beírása).
• Az SPF, a DKIM és a DMARC rendben működik, amíg az álnév ugyanazon a domainen van, és Ön a saját szerverén keresztül küld levelet.

A gyakorlatban: így néz ki egy vezérlőpulton

A DirectAdmin felületen az átirányításokat az E-mail kezelés menüpont Forwarders részén hozhatja létre. A catch-all a Haladó tulajdonságok menüpont Catch-All E-mail részén található; itt a "catch-all kikapcsolása" az ajánlott beállítás (a nem létező címekre érkező leveleket a rendszer elutasítja). Ha csak domainnévvel rendelkezik, csomag nélkül, az átirányítások a Fiókom felületen, a Domainjeim menüpont Átirányítások részén találhatók. Más vezérlőpultok (cPanel, Plesk, Microsoft 365, Google Workspace) hasonló funkciókkal rendelkeznek, néha "álnevek", "átirányítás" vagy "csoportok" elnevezés alatt.

Összefoglalás

• Az ugyanazon a szerveren belüli álnév vagy átirányítás biztonságos.
• A kifelé irányuló átirányítás megszakítja az SPF-et. Az SRS helyreállítja az SPF-et, de nem a DMARC igazodását; csak az érintetlen DKIM-aláírás mentheti meg a levelet, és az ARC segíthet.
• A továbbított spam árt a szervere reputációjának. A külső leveleket inkább IMAP-on keresztül olvassa az alkalmazásban.
• A catch-all vonzza a spamet, elrejti az elgépeléseket, és backscattert okozhat. Használjon inkább külön álneveket.
• Álnévről való küldés lehetséges, a szervere szabályain belül.

Kvíz

Feladat

O3.3 feladat: A címei leltára. Készítsen listát a domainjéhez tartozó összes címről: postafiókok, álnevek, átirányítások, és hogy van-e beállítva catch-all. Jelölje meg minden átirányításnál, hogy az a saját domainjén belül marad-e, vagy kifelé irányul-e (Gmail, Outlook.com, egy másik vállalat). Ezután válaszolja meg: melyik kifelé irányuló átirányítást lehetne lecserélni egy IMAP-fiókra az alkalmazásban, és van-e olyan catch-all beállítás, amelyet ki lehetne kapcsolni? Töltse ki az ellenőrzőlistát.

Továbbolvasás

Az ezekben a cikkekben leírt lépések a WebOké vezérlőpultjaira vonatkoznak; más szolgáltatóknál hasonlóan működik.

• DirectAdmin útmutató 7.5: E-mail átirányítások: levelek továbbítása másik címre
• DirectAdmin útmutató 7.6: Catch-all E-mail: levelek nem létező címekre
• E-mail továbbítása egy másik címre (forwarders, catch-all nem ajánlott)
• Levélküldés több aliasról, hibaüzenet: Account xxx can not send emails from
• WebOké útmutató 5.9: E-mail- és domain-továbbítások
• Ingyenes DNS-tanfolyam 4.3: SPF: ki küldhet levelet a domainje nevében?
• RFC 8617 (ARC), RFC 7208 D. függelék (SPF és közvetítők, mint az átirányítók)