Sok kéretlen e-mailt kapok saját domainemről, tudok valamit ez ellen tenni?

3 esetet szükséges különválasztanunk.

Az 1. esetben fiókunk jelszava illetéktelen kezekbe került

E-mail fiókunk jelszavával bejelentkezve a levélküldő szerverre küldenek ki levelet a spam küldők, mi pedig megkapjuk a sikertelen kézbesítések miatti visszapattanó üzeneteket.
Ilyen esetben az első szükséges teendő e-mail fiókunk jelszavának megváltoztatása a cpanelen, ezután fokozatosan levelező klienseinkben is.
Amennyiben valamelyik eszközünkhöz szereztek hozzáférést és annak jelszavát olvassák el a támadók, az eszközben ismét helyes jelszó megadása után ismételten spameket fognak küldeni e-mail címünkkel, ezért célszerű azokat az eszközöket, amelyekben kisebb bizalmunk van a jelszó frissítési sor végére hagyni.
Fontos, hogy azok az eszközök, amelyek nem rendelkeznek a frissített jelszóval, ne próbáljanak meg a fiókhoz kapcsolódni, a cpaneles szerverek védelmi rendszere kitilthatja a sokszor hibás jelszóval belépni szándékozókat.

A 2. esetben weboldalunk kompromittálódott

Tárhelyünk valamelyik mappájába feltöltött fájl küldi ki az e-maileket, a sikertelen kézbesítésről szóló e-mailek visszapattannak.
Ilyen esetben gyűjtő e-mail fiókunkba érkeznek (várhatóan). Ezt az esetek többségében a szerverek üzemeltetői észlelik, a feltört oldal működését felfüggesztik, ilyenkor az ajánlott megoldás az oldal tiszta forrásból való újratelepítése.

Erről az alábbi oldalakon írtunk:
http://tudasbazis.hostit.hu/fertozott-a-joomladrupalwordpress-weboldalam-mit-tehetek/
http://tudasbazis.hostit.hu/megtortek-a-joomla-oldalamat-hogyan-fordulhatott-ez-elo/

A kompromittálódott weboldalak közé soroljuk azokat a weboldalakat is, amelyeket ugyan nem törnek fel, de az oldal kódja olyan, hogy egy a támadó által megfelelően összeállított kérés segítségével kiküldik a támadó által elküldeni kívánt e-mailt.

Például: sok korai joomla verzióban mindenféle hitelesítés és ellenőrzés nélkül lehetett contact_form üzeneteket kiküldeni, ezeket gyakran használták és esetenként még ma is használják, amennyiben tudják spam küldésre. Itt egy példa 2019-ből, amikor a letiltott form segítségével is tudtak a támadók spamet küldeni: CVE-2019-15028

Gyakori továbbá a felhasználói regisztrációval kiküldött spam. Ebben az esetben is arról van szó, hogy az oldalon bárki regisztrálhat ellenőrzés nélkül, a regisztrációnál beküldött adatokkal együtt a spam küldést is megteszi a támadó.

Ez a keretrendszer nem ellenőrzi a megadott felhasználónevet megfelelően. A regisztrációkor a támadó megadja a spam üzenetet és a kártékony oldal linkjét. A regisztrációhoz pedig annak az e-mail címét, akinek ki akarja küldeni. Így a keretrendszer a példában egy prestashop elvégzi helyette a spam küldést.

Javasoljuk ezért minden olyan e-mail küldési funkció védelmét az oldalon legalább captcha kóddal, amit produktívan kívánunk használni,
továbbá a nem használt funkciók és formok eltávolítását!

A 3. eset, nem mi küldjük ki az e-mailt, hanem egy harmadik fél szerverén keresztül kerül kiküldésre az e-mail a mi domain nevünkkel

 Ekkor nem tudjuk közvetlenül befolyásolni a kiküldendő leveleket, az alábbiakat tehetjük:

• azt meg lehet adni, hogy a domain alapértelmezett e-mail címének beállításainál a nem létező e-mail címhez választ küldjön a szerverünk: „nem létezik ilyen felhasználó”. Azért jó ez, mert azok a küldő szerverek, amik a feladót visszaellenőrzik, nem fogják elküldeni az e-mailt, mert látják, hogy nem létező feladótól lett kiküldve.
  http://tudasbazis.hostit.hu/cpanel-alapertelmezett-gyujto-e-mail-fiok-javasolt-hasznalata/
• Be lehet továbbá állítani az SPF és DKIM rekordokat is az e-mail/email hitelesítés menüpontban a cpanelen.
  http://tudasbazis.hostit.hu/fix-ip-cimet-vasaroltam-hogyan-allitsam-be-az-spf-rekordot/
  Ez azért lehet hatásos, mert megadhatjuk az SPF rekordban azt, hogy kizárólag az általunk használt szerverről küldött e-mail származik tőlünk, a többi nem. Példa spf rekord:
  azendomainem. 3600 IN TXT „v=spf1 mx -all”
  Engedélyezi az MX -ről vagyis a bejövő levelek kiszolgálójáról küldést és tilt minden mást.
• Adott esetben, ha van egy vagy több ismétlődő  kulcsszó az e-mailben, akkor a spamassassin -t is meg lehet tanítani azoknak a kiszűrésére.
  http://tudasbazis.hostit.hu/spamassassin-beallitas-cpanelen/

Roundcube webmail – forrás megtekintése

Melyik eset?

Azt, hogy melyik esetről szó,  célszerű szakember segítségével megítélnünk. Felderítéséhez a visszapattant üzenetek valamelyike szükséges. Azok általában jelzik a probléma pontos okát. Néhány példa:

• Amennyiben cpaneles webtárhely szerverünk segítségével kerül kiküldésre az e-mail, a belépéshez használt e-mail fiók neve megtalálható az e-mailben az authenticated_id: rész után, amelyet a levél forrásának megtekintésével kereshetünk ki. Ha ott e-mail címünk szerepel, vélhetően az első esetről van szó és aszerint szükséges eljárnunk.
• Abban az esetben, ha a levél forrásában cpaneles felhasználónevünk/public_html/index.php vagy más elérési úttal vagy más .php végződésű fájt látunk , akkor vélhetően a második esetről van szó.
  Célszerű teljes mentést készíteni weboldalunkról, letölteni azt számítógépünkre és ezután vagy kérni a szolgáltatónk segítségét vagy letörölni a weboldalt és tiszta forrásból újratelepíteni és ezután egyeztetni szolgáltatónkkal.
• Ha a felsoroltak egyike sem látható az e-mail forrásában, kérhetjük szolgáltatónk segítségét, aki vélhetően meg fogja tudni mondani, hogyan került kiküldésre az e-mail, érintett-e benne webtárhelyünk vagy e-mail fiókunk, illetve legalább spf rekordunk megfelelően van-e beállítva.  Ez utóbbit ellenőrizhetjük itt is.
  Remélhetőleg a harmadik esetről van szó és közvetlenül nem vagyunk érintettek spam küldésben.