Tartalom

Bevezető

Az elektronikus levelezések lebonyolítása során a levelező kiszolgálók törekednek a kéretlen levelek (spam) minél hatékonyabb kiszűrésére. Időnként megesik, hogy olyan levelek is fennakadnak ezeken a spam szűrési szolgáltatásokon, amik egyáltalán nem tartalmaznak olyan dolgokat, amik ezt indokolttá tennék. Ezért velünk is előfordulhat, hogy nem tudunk email-t küldeni egy címzettnek, vagy éppen a saját szerverünkön nem tudunk leveleket fogadni másoktól. Ebben a leírásban utánajárunk az egyik gyakrabban előforduló szerver oldali "554 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org; Error: open resolver;" típusú hibának.

A hibajelenség

LAMP vagy például ISPConfig-os szerverünkön működő email címekre küldött levelek visszapattannak a feladónak, így például a saját magunk által elküldött teszt levelek is visszapattannak hozzánk. Ilyenkor az alábbi hibaüzetetek valamelyikét láthatjuk:

Visszapattant levél Gmail fiók esetén

Ha egy Gmail-es email címről küldenek levelet a kérdéses fiókunkba, akkor egy ilyen üzenetet kap vissza a feladó a szerverünktől (persze magát a HTML levél sablont a kis ikonnal már a gmail állítja össze a hibaüzenet alapján):

554 5.7.1 Service unavailable; Client host [209.85.128.44] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/172.68.225.58

Visszapattant levél egyéb fiók esetén

Ha pedig nem Gmail-es címről próbálnak levelet küldeni a szerverünkön üzemeltetett valamelyik postafiókba, hanem egyéb fiókból (ebben a példában egy másik sima saját üzemeltetésű címemről), akkor pedig ilyesmi üzenetet kap a feladó a visszapattant levélben:

This is the mail system at host szerver.linuxportal.info.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<címzett email címe>: host mail.cimzett_mailszervere.hu[xxx.xxx.xxx.xxx] said: 554
    5.7.1 Service unavailable; Client host [yyy.yyy.yyy.yyy] blocked using
    zen.spamhaus.org; Error: open resolver;
    https://www.spamhaus.org/returnc/pub/zzz.zzz.zzz.zzz (in reply to RCPT TO
    command)

Ami tartalmazza a címzett email címét, levelező kiszolgálójának IP-címét (azaz a mi szerverünk IP-címét), a kiszolgáló által visszaadott "554.5.7.1 Service unavailable;" hibakódot, a feladó IP-címét, stb.

Tehát ha hasonló levelet dob vissza szerverünk a feladónak, amiben az "554.5.7.1" -es hibakód szerepel, akkor jó helyen járunk, mindjárt meg is nézzük a hiba okát és megoldását.

A hiba oka

A hibát egy nem bonyolult, de annál nyakatekertebb jelenség okozza. Elsőre azt gondolná az ember, hogy a feladó IP-címe felkerült valamilyen spam szűrő szolgáltatás fekete listájára (például véletlenül kifogott egy "balszerencsés" dinamikus IP-címet, stb), ami logikusnak is tűnhet, mivel látszólag a feladó kapja ezt a hibaüzenetet egy visszapattant levélben, amiben valamilyen Spamhaus név szerepel...

Ebben a hibában azonban van egy jókora csavar, mivel a hibaüzenetet konkrétan nem a levél feladója kapja, hanem a levelező kiszolgálónk. Ha egy ilyen levél elküldése idején belenézünk a /var/log/mail.log fájba például a tail paranccsal:

tail -f /var/log/mail.log

Akkor a levél küldésének - illetve a szerverünk szemszögéből nézve a levél fogadásának - pillanatában az alábbihoz hasonlót láthatunk:

Aug  3 10:15:40 mail01 postfix/smtpd[23645]: NOQUEUE: reject: RCPT from sender.example.com[xx.xx.xx.xx]: 554 5.7.1 Service unavailable; Client host [xx.xx.xx.xx] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/162.158.148.77; from=<sender@example.com> to=<recipient@example.com> proto=ESMTP helo=<icinga2.infiniroot.net>

A hibaüzenet jelentése pedig a következő:

Az "open resolver" hiba azt jelzi, hogy a levelező kiszolgálónk egy nyílt DNS kiszolgálót használ névfeloldásra. Az open resolver (nyílt névfeloldó) egy olyan DNS szerver, amely lehetővé teszi a harmadik fél által küldött DNS-kérések átadását más szervereknek, ezáltal az ilyen DNS kiszolgálók növelik a hálózatok biztonsági kockázatát, mert ezeket a kiszolgálókat könnyebben fel tudják használni a DNS forgalom átirányítására, spam levelek küldéséhez, stb.

A Spamhaus.org az egyik legnépszerűbb DNSBL (DNS-based BlackList) szervezet, amelynek a szolgáltatása tartalmazza az összes olyan IP-címet, amelyeket a Spamhaus rendszer egyszer már blokkolt, mert valamilyen spam küldő szolgáltatáshoz kapcsolódott. Az IP-címeket ilyenkor automatikusan fekete listára teszik, ha spam tevékenységet észlelnek velük kapcsolatosan.

Amikor egy levelező kiszolgáló fogad egy levelet, akkor először megvizsgálja a levél feladójának IP-címét, hogy ellenőrizze hitelességét, valamint hogy szerepel-e ezeken a spam listákon, stb. Ennek megfelelően, amikor a levélkiszolgálónkhoz beérkezik egy levél, elküld egy lekérdezést ehhez a Spamhaus.org szervezethez, hogy lekérdezze a feladó IP-címének spam érintettségét. Azonban mivel a kiszolgálónk egy nyílt DNS szolgáltatást használ, ezért a Spamhaus a mi szerverünktől tagadja meg a spam információk kiszolgáltatását, tehát a mi levélkiszolgálónk kapja ezt a hibaüzenetet. Ezek után a levelező kiszolgálónk érvénytelennek minősíti ezt a kapott (hibaüzenet) információt, ezért visszapattintja a levelet a feladónak, benne továbbítva a Spamhaus által kapott hibaüzenettel, mivel nem kapott kielégítő választ a Spamhaus-tól a kért IP-címmel kapcsolatban, így nem tudja megítélni, hogy a feladó IP-címe érintett-e valamilyen korábbi spam tevékenységben.

Tehát lényegében ezt a hibaüzenetet nem a levél feladója kapja, hanem a mi levelező szerverünk, amit aztán a mi szerverünk is hibának tekintve megtagadja a levél kézbesítését, és visszadobja a levelet a feladónak, akinél pedig megjelenik ez a hibaüzenet.

A saját esetünkben ilyenkor a Postfix (Mail Transfer Agent) levélküldő és levéltovábbító kiszolgálónk konfigurációja tartalmazza a Spamhaus.org szolgáltatását, mint spam ellenőrzési implementációt, így tehát a Postfix-nél akadnak el ilyenkor a levelek, mivel a Postfix ebben az esetben úgy van bekonfigurálva, hogy ő fogadja a beérkező leveleket, és csak különböző levélszűrések után továbbítja a leveleket a POP3/IMAP kiszolgálónkhoz - amennyiben nem talált bennük semmi gyanúsat.

Lehetséges megoldások

Erre a problémára többféle lehetséges megoldás is kínálkozik, íme néhány közülük:

Kerüljük a nyílt DNS kiszolgálók használatát

Nyílt DNS kiszolgálót akkor kell igénybe vennünk, ha nem a saját szerverünkön üzemeltetjük a DNS kiszolgálást, hanem például a névszervereket a domain név regisztrátoránál hagytuk beállítva, és a regisztrátor kezelőfelületén állítgatjuk a domain nevünkhöz tartozó DNS zónát, ahonnan "A" rekordokkal irányítjuk át külön a www és egyéb aldomainjeinket, valamint "MX" rekorddal a levelező kiszolgálót. Ilyenkor a levelezés ugyan a saját szerverünkön zajlik, de a névfeloldást a regisztrátor által kínált publikus DNS kiszolgáló biztosítja.

A nyílt DNS kiszolgáló előnye:

Ennek előnye, hogy nem nekünk kell bíbelődnünk az elsődleges és másodlagos névszerverekkel, hanem a szolgáltató biztosítja számunkra ingyenesen.

A nyílt DNS kiszolgáló hátránya:

Mivel rajtunk kívül még rengetegen használják ezeket a DNS kiszolgálókat, ennél fogva a nagy számok törvénye alapján hamar fennakadhat valakinek a levele egy ilyen Spamhaus -féle spam szűrő szolgáltatáson, és akkor az IP-cím tiltólistára kerülésével mindenkinél ugyanez a hiba jelentkezik. Itt tehát az a bizonyos "közös lónak..." effektus van érvényben. Itt elég, ha van egy olyan weboldala valakinek, ami gyengén van levédve, és például az egyik kontakt űrlapján keresztül spammelés történik. De elég annyi is, ha például valakinél egy rosszul összerakott PHP levél megy ki, amiben nem megfelelő a fejléc, és Ilyenkor a DNS kiszolgáló IP-címe a fekete listákra kerül, és mindenkinél leáll a levél fogadás, akiknél hasonlóan van beállítva. Rosszabb esetben ha kifelé szeretnénk küldeni másoknak, akkor még a másik oldalon használt spam szűrő szolgáltatás is letilthatja a leveleinket.

Mi a megoldás erre?

Használjunk saját DNS kiszolgálót a saját szerverünkön! Persze egy LAMP szerver esetén ezt bonyolultabb kézzel bekonfigurálni, így ha nem akarunk ilyesmivel bíbelődni, akkor ugorjunk a következő lehetéséges megoldásra.

Azonban ha például egy ISPConfig-os szerver konfigurációnk van, ahol mindent beállítottunk a telepítéskor, ebben az esetben az alábbi leírásokból megtudhatjuk hogyan használhatjuk a saját névszerverünket és hogyan juthatunk másodlagos névszerverhez:

• Hogyan állítsunk be másodlagos névszervert, ha csak egy IP-címmel rendelkezünk
• Hogyan építhetjük meg és élesíthetjük ISPConfig3 szerverünket ...  - DNS zóna létrehozása és a rekordok beállítása

Ilyenkor minden a saját szerverünkön zajlik, így a levelezés is és a névfeloldás is, valamint a domain nevünk SOA rekordja is nálunk lesz. Ezt a módszert használom én is, még nem volt semmi gondom ezzel.

Iktassuk ki a Spamhaus.org spamszűrő szolgáltatását (nem ajánlott)

Egy másik lehetséges megoldás, amit nem szívesen ajánlok, de ha nem tudjuk másképpen megoldani, akkor ki is iktathatjuk a Postfix-ben a Spamhaus spamszűrő szolgáltatását. Ha ezt választjuk, akkor nem lesz többé spam szűrésünk, így szerverünk jobban ki lesz téve a spammerek támadásából eredő kockázatnak. Tehát tényleg csak akkor tegyünk ilyet, ha a fenti megoldás nem járható út számunkra. Ne feledjük, szerverünk folyamatosan ki van téve többféle támadásnak, amik közül az SMTP kiszolgálót érő támadási fajta a leggyakoribb!

Ehhez nyissuk meg root-ként a /etc/postfix/main.cf fájlt:

nano /etc/postfix/main.cf

Majd keressük meg az alábbi sort:

smtpd_client_restrictions = check_client_access proxy:mysql:/etc/postfix/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org, reject_unauth_pipelining , permit

Ez egy egyszerű értékadás, aminek egy vesszőkkel elválasztott felsorolás van megadva. Ebből a felsorolásból távolítsuk el a pirossal kiemelt részt, majd mentsük le. Itt figyeljünk rá, hogy egy vesszőt is vegyünk ki a kiemelt résszel, tehát ne hagyjunk a fájlban szintaktikai hibát.

Ezután indítsuk újra a postfix-et:

systemctl restart postfix

Spamhaus adatlekérő szolgáltatás MTA-val

Ha semmiképpen nem tudjuk megoldani, hogy ne publikus névszervereket használjunk, akkor a Spamhaus még kínál egy adatlakérő szolgáltatást: "Data Query Service using an MTA".

Ennek lényege, hogy a szerverünkön működő MTA (Mail Transfer Agent), azaz például a Postfix segítségével beállíthatunk egy olyan ingyenes lekérdezési szolgáltatást, ami a publikus DNS kiszolgálók használata esetén is működik. Bár ez a szolgáltatás korlátozott funkcionalitással működik, de mégis biztosítja az alapvető Spamhaus spamszűrő szolgáltatást.

Bevallom őszintén ezt még nem próbáltam, mivel én az első megoldást használom, így csak átfutottam a dokumentációját, ami itt található:

• docs.spamhaus.com/datasets/docs/source/40-real-world-usage/MTAs/000-intro.html

Így esetleg aki nem tudja elkerülni a nyílt DNS kiszolgáló használatát, és kísérletező kedvében van, annak ez a megoldás is megfelelő lehet.

Konklúzió

Ezek lennének tehát a "554 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org; Error: open resolver;" típusú hibára a megoldások, amennyiben pontosan ugyanilyen problémával találnánk szembe magunkat. Összességében célszerű kerülni a publikus DNS kiszolgálók használatát, és helyette törekedjünk arra, hogy lehetőleg minden szolgáltatás a saját szerverünkön működjön, így minimális lesz a kitettségünk a külső tényezőkből eredő hibáknak, mint például egy sokak által közösen használt DNS kiszolgáló esetén. A saját szerverünk IP-címe az mindig egyedi marad, mivel csak mi használjuk, ami így kizárt hogy felkerüljön bármilyen spam szűrő szolgáltatás listájára, amennyiben odafigyelünk szolgáltatásaink optimális és biztonságos működésére.