„Persiųsti į Gmail“: kaip viena patogi varnelė paverčia įmonės paštą šlamšto siuntėju

Spalio pabaigoje paskambino klientas, nedidelė prekybos įmonė: „Mūsų laiškai grįžta.“ Įprastas komercinis pasiūlymas partneriui po kelių sekundžių sugrįžo su žyma „Client host blocked using Spamhaus“. Įmonės pašto serveris buvo juodajame sąraše, nors niekas joje šlamšto nesiuntė. Ieškodamas priežasties radau ne įsilaužimą ir ne virusą, o vieną patogią varnelę pašto nustatymuose, kurią, drįstu teigti, turi įsijungusi gera dalis Lietuvos smulkiųjų įmonių.

Ši istorija ne apie vieną įmonę. Ji apie tai, kaip paprasčiausias „persiųsti laiškus į Gmail“ paverčia jūsų serverį šlamšto šaltiniu, kaip tai pajunta visai nekalti žmonės kitoje Europos pusėje ir kodėl apie tai sužinote tik tada, kai jūsų pačių laiškai klientams pradeda grįžti atgal.

Kaip atrodo patogumas

Įprasta Lietuvos įmonės schema atrodo taip. Yra domenas, tarkime, jusuimone.lt. Pas prieglobos paslaugų teikėją sukurta dėžutė [email protected], nes solidžiai atrodo ant vizitinės. Bet tikrinti dar vieną dėžutę niekas nenori, todėl valdymo skydelyje įjungiamas persiuntimas: visa, kas ateina į info@, automatiškai keliauja į savininko asmeninį Gmail. Paspaudėte vieną mygtuką, ir paštas skaitomas telefone kartu su visu kitu.

Tai daroma visur. „Hostinger“ lietuviškame pagalbos centre tai vadinama persiuntimo paskyra: „Persiuntimo funkcija leidžia automatiškai persiųsti visus gaunamus el. laiškus iš vieno jūsų adreso“ į kitą. Tokią pat funkciją turi DirectAdmin, cPanel, ISPmanager ir praktiškai kiekvienas prieglobos skydelis, su kuriuo susiduriame tvarkydami klientų svetaines. Pas klientus šią schemą matome nuolat: dėžutė serveryje, skaitoma Gmail'e. Pati Google problemą laiko tokia paplitusia, kad išleido atskirą lietuvišką pagalbos puslapį „El. laiškų persiuntimo į „Gmail“ geriausia praktika“.

Pavyzdys: taip persiuntimas atrodo prieglobos skydelyje. Viena eilutė, vienas jungiklis, ir dėžutė pradeda dirbti pašto kurjeriu.

Pats persiuntimas nėra nusikaltimas. Problema prasideda tada, kai į info@ pradeda rašyti ne klientai, o šlamšto siuntėjai. O jie rašo visiems: adresas info@ yra pirmas, kurį bando bet kuris robotas, nes jis yra ant jūsų svetainės.

Ką iš tiesų daro jūsų serveris

Pasekime vieną šlamšto laišką nuo pradžios iki galo. Pavadinsiu dalyvius vardais, kad būtų lengviau.

Schema: šeši žingsniai, kurių metu jūsų serveris, nieko blogo nenorėdamas, išsiunčia šlamštą žmogui, kuris jums nieko nerašė.

1. 1
   Šlamšto siuntėjas iš kur nors Azijoje ar Lotynų Amerikoje siunčia laišką į [email protected]. Siuntėjo adresą jis įrašo svetimą, tikrą ir egzistuojantį, tarkime, [email protected]. Taip daroma specialiai: laiškas su tikru adresu atrodo patikimiau, o visos pasekmės krenta ne siuntėjui, o Rimui.
2. 2
   Jūsų serveris laišką priima. Jis juk skirtas info@, kuris egzistuoja. Serveris atsako siuntėjui „gavau, ačiū“ ir nuo šios akimirkos atsakomybė už laišką jau jo.
3. 3
   Persiuntimas suveikia: serveris tą patį laišką išsiunčia į jūsų Gmail. Dabar, Google akimis, laišką siunčia nebe šlamšto siuntėjas, o jūsų serveris su jūsų IP adresu.
4. 4
   Gmail laišką apžiūri ir atmeta. Jis mato, kad tai šlamštas, kad siuntėjo domenas kitaimone.lt neleido jūsų serveriui siųsti laiškų jo vardu, kad parašo nėra. Atsakymas skamba taip: „550-5.7.26 Your email has been blocked because the sender is unauthenticated“ arba „550-5.7.1 Gmail has detected that this message is likely unsolicited mail“. Google čia elgiasi visiškai teisingai.
5. 5
   Jūsų serveris dabar turi laišką, kurio nepavyko pristatyti. Pagal pašto taisykles jis privalo informuoti siuntėją. Siuntėjas, kaip prisimename, yra [email protected]. Serveris sukuria pranešimą „Mail delivery failed: returning message to sender“, prideda visą šlamšto laišką ir išsiunčia Rimui.
6. 6
   Rimas gauna iš jūsų serverio šlamštą su jūsų domenu antraštėje. Jis nieko jums nerašė. Jo pašto tarnyba mato, kad jūsų IP adresas siuntinėja atmestus šlamšto laiškus svetimiems žmonėms, ir praneša apie tai ten, kur tokie pranešimai renkami.

Šis reiškinys turi pavadinimą: atgalinis šlamštas (angl. backscatter). „Microsoft“ jį apibrėžia paprastai: tai pranešimai apie nepristatytus laiškus, kuriuos gaunate už laiškus, kurių niekada nesiuntėte, nes šlamšto siuntėjai dažnai įrašo tikrus svetimus adresus. Pasaulyje veikia atskiras sąrašas Backscatterer.org, kuriame registruojami tik tokie serveriai; šios savaitės duomenimis, jame yra 12 115 IP adresų, ir kiekvienas lieka ten keturias savaites.

Kaip galima įrašyti svetimą „nuo“

Įprastam žmogui tai sunkiausia įsivaizduoti. Jis rašo laiškus iš savo dėžutės, laukelis „Nuo“ užsipildo pats, ir atrodo, kad kitaip būti negali. Bet laukelis „Nuo“ yra tik eilutė laiško antraštėje, kaip siuntėjo adresas, ranka užrašytas ant voko. Paštininkas jo netikrina, jis tik neša voką ten, kur parašyta „Kam“. Šlamšto siuntėjai nesinaudoja nei Gmail, nei Outlook: jie turi programas, kurios jungiasi tiesiai prie gavėjo pašto serverio ir diktuoja laišką eilutė po eilutės, įskaitant tai, kas bus „nuo“. Vienu paleidimu tokia programa išsiunčia milijoną laiškų su milijonu skirtingų, tikrų, iš nutekėjusių duomenų bazių paimtų adresų.

Pavyzdys: taip šlamšto siuntėjo programa „kalbasi“ su įmonės pašto serveriu. Eilutėje MAIL FROM ji įrašo svetimą adresą, serveris atsako „250 OK“ ir laišką priima.

Beje, net paprastoje pašto programoje, tokioje kaip „Thunderbird“ ar „Outlook“, paskyros nustatymuose galima įrašyti bet kokį adresą, ir programa paklus. Apsauga nuo to yra ne gavėjo, o adreso savininko rankose: SPF, DKIM ir DMARC įrašai jo domene pasako pasauliui, kurie serveriai turi teisę siųsti laiškus jo vardu, ir ką daryti su kitais. Rimo domenas tokius įrašus turėjo, todėl Gmail laišką ir atmetė. Bėda ta, kad atmetė jau po to, kai įmonės serveris laišką buvo priėmęs ir pasirašęs po juo savo IP adresu.

Ką radome kliento serveryje

Vienas dalykas yra teorija, kitas – savo akimis matyti, kaip tai vyksta. Kliento pašto serveris aptarnauja kelis jo domenus, ir dviejuose iš jų info@ buvo persiunčiamas į Gmail. Štai ištraukos iš serverio žurnalų už vieną savaitę; adresus ir IP paslėpiau, klientas sutiko, kad istorija būtų papasakota.

Ekrano kopija: tikras įrašas kliento serverio žurnale. Gmail atmeta persiųstą laišką, nes siuntėjas „neautentifikuotas“: nei SPF, nei DKIM parašo nėra, o serveris prisistato vardu, kurio niekas nepažįsta.

• Spalio 20 d. Šlamšto laiškas į info@ persiųstas į Gmail, Gmail atmetė kaip „likely unsolicited mail“. Serveris per sekundę išsiuntė pranešimą apie nepristatymą adresu no-reply@ vienos Ispanijos kosmetikos įmonės domene.
• Spalio 21 ir 26 d. Du pranešimai apie nepristatymą išsiųsti į kinišką 163.com dėžutę.
• Spalio 22 d. Tas pats, pranešimas iškeliavo į užsienio įmonės „noreply“ adresą, iš kurio niekas niekada neatsako.
• Spalio 23 d. Gmail atmetė su kodu 5.7.26 ir paaiškinimu, kad SPF patikra neišlaikyta, o serveris prisistato techniniu vardu, kuris baigiasi „.local“.
• Spalio 27 d. Gmail atmetė dėl „very low reputation of the sending domain“. Pranešimas iškeliavo į serverį Vokietijoje.

Keturi svetimi adresatai, nuo Ispanijos iki Kinijos, per savaitę gavo iš šios įmonės laiškus, kurių neprašė, ir kiekviename buvo jos domeno vardas. O žurnalai saugomi tik dešimt dienų; kiek tokių laiškų išėjo anksčiau, nežinome. Pagal „Spamhaus“ duomenis, IP adresas į sąrašą buvo įtrauktas mažiausiai spalio 17 d., dešimt dienų iki tol, kol įmonė tai pastebėjo.

Čia reikia pasakyti sąžiningai: persiuntimas buvo ne vienintelė priežastis. Serveris dar ir prisistatydavo kitiems serveriams techniniu vardu, kurį prieglobos skydelis sugeneravo automatiškai, vietoj tikro pašto vardo. „Spamhaus“ savo DUK tiesiai rašo, kad į CSS sąrašą patenka adresai, siunčiantys „blogą paštą dėl įsilaužimo, nesaugaus įdiegimo arba neteisingai sukonfigūruoto serverio“, ir kad tipiniai klaidingi prisistatymai yra „localhost.localdomain“, „WIN-XYZPDQ01“ arba „mail“. Abi klaidos yra iš tos pačios lentynos: prieglobos skydelis viską sukonfigūravo „kad veiktų“, o ne „kad veiktų teisingai“. Ir abi tylios: paštas ateina, paštas išeina, niekas nesiskundžia. Iki tam tikros dienos.

Kas nukenčia

Nukenčia trys pusės, ir tik viena iš jų esate jūs.

Nekaltas žmogus, kurio adresą pasiskolino šlamšto siuntėjas. Jis gauna dešimtis ar šimtus „jūsų laiškas nepristatytas“ pranešimų iš viso pasaulio serverių, kuriuose įjungtas toks pat persiuntimas. Kiekviename yra šlamšto turinys, dažnai su kenkėjiškomis nuorodomis. Jei tai įmonė, jos darbuotojai praleidžia dieną aiškindamiesi, ar jų paštas nulaužtas. Nenulaužtas. Tik tūkstantis serverių, įskaitant jūsų, elgiasi kaip paštininkas, kuris grąžina svetimą laišką adresu, užrašytu pieštuku ant voko.

Pavyzdys: taip atrodo laiškas, kurį gauna Rimas. Viršuje – svetimo serverio pranešimas, kad „jo“ laiškas nepristatytas, žemiau – pats šlamštas, kurio jis niekada nerašė.

Visi, kas dalijasi su jumis serveriu. Bendrojoje priegloboje vienas IP adresas aptarnauja dešimtis ar šimtus svetainių ir jų pašto dėžučių. Juodieji sąrašai veikia pagal IP adresą, ne pagal domeną. Vadinasi, vienos įmonės varnelė „persiųsti į Gmail“ gali sustabdyti paštą visai kaimynystei: buhalterijai, kuri siunčia sąskaitas, klinikai, kuri siunčia priminimus apie vizitą, parduotuvei, kuri siunčia užsakymų patvirtinimus. Jie niekada nesužinos, kas kaltas. „Spamhaus“ apie tai rašo tiesiai: kaip elgtis su sąraše esančiu IP, sprendžia kiekviena pašto tarnyba savo nuožiūra.

Jūs patys. Tai pajuntate paskutinis, bet skaudžiausiai. Kliento atveju grįžo laiškas partneriui, kurio paštą tvarko „Microsoft“. „Outlook“ serveris atmetė jį dar nepradėjęs skaityti, vien pagal IP adresą.

Ekrano kopija: tikras pranešimas, kurį klientas gavo spalio 27 d. Gavėjo pusėje stovintis „Microsoft“ serveris atsisakė priimti laišką dėl IP adreso reputacijos; adresai ir IP paslėpti.

Pagalvokite, kiek laiškų grįžta ne į jūsų dėžutę, o tyliai nugula gavėjo šlamšto aplanke. Komercinis pasiūlymas, kurio klientas „nematė“. Sąskaita, kuri „neatėjo“. Atsakymas kandidatui, kuris nuėjo pas konkurentus. Nė vienas iš jų nepraneš jums, kad jūsų laiškas atrodė kaip šlamštas. Tai ir yra pavojingiausia šios problemos savybė: ji neturi simptomų iki tol, kol praradimai jau įvykę.

Pavyzdys: įmonės pasiūlymas gavėjo Gmail šlamšto aplanke. Gmail paaiškina priežastį vienu sakiniu, bet gavėjas šio aplanko paprastai neatidaro.

Kodėl Gmail čia ne kaltas

Norisi pykti ant Google, bet Gmail šioje istorijoje daro tiksliai tai, ko norėtume: atpažįsta šlamštą ir jo nepriima. Nuo 2024 m. Google reikalauja, kad kiekvienas laiškas būtų autentifikuotas bent vienu iš dviejų būdų: SPF (domeno savininko paskelbtas sąrašas serverių, kurie turi teisę siųsti jo vardu) arba DKIM (skaitmeninis parašas). Persiunčiamas šlamšto laiškas negali išlaikyti SPF, nes jūsų serverio nėra svetimo domeno sąraše, o DKIM parašo šlamšto siuntėjas dažniausiai neturi. Lietuviškame Google pagalbos puslapyje administratoriams tai pasakyta aiškiai: Gmail automatiškai nepasitiki tuo, kad laiškas jau buvo patikrintas anksčiau, ir persiųstą laišką tikrina iš naujo.

Kaltas yra serveris, kuris pirmiausia laišką priėmė, o paskui apsigalvojo. Pašto protokolas numato du sąžiningus kelius: atsisakyti laiško iš karto, dar pokalbio su siuntėju metu (tada pranešimą rašo siuntėjo serveris, o ne jūsų), arba priimti ir pristatyti. Trečias kelias, priimti ir po to grąžinti neva siuntėjui, yra būtent atgalinis šlamštas.

Tai ne Google išradimas, tai dešimtmečius žinoma pašto administratorių klaida. Tik anksčiau ją darė didelių įmonių IT skyriai, o dabar kiekvienas, kas prieglobos skydelyje paspaudė „Persiuntimas“.

Kaip pasitikrinti per penkiolika minučių

Nereikia būti IT specialistu, kad atsakytumėte į keturis klausimus.

1. 1
   Kur keliauja jūsų info@? Įeikite į prieglobos valdymo skydelį, raskite pašto skiltį ir pažiūrėkite, ar prie jūsų dėžučių yra persiuntimas (gali vadintis „Persiuntimas“, „Peradresavimas“, „Forwarders“) į gmail.com, outlook.com ar kitą išorinį adresą. Jei nežinote, kaip įeiti, parašykite teikėjui vieną sakinį: „Ar kuri nors mūsų dėžutė persiunčia laiškus į išorinį adresą?“
2. 2
   Ar jūsų serveris juodajame sąraše? Atsidarykite check.spamhaus.org ir įveskite savo domeną. Jei nežinote IP adreso, puslapis parodys pats. Žalia reiškia tvarka, raudona reiškia, kad dalis jūsų laiškų šiuo metu negrįžta.
3. 3
   Ar į jūsų dėžutę ateina pranešimų apie nepristatymą už laiškus, kurių nesiuntėte? Paieškokite „Mail delivery failed“ arba „Undeliverable“. Jei tokių yra, o laiškų nesiuntėte, jūsų adresą kažkas naudoja kaip Rimo. Tai dar ne jūsų serverio kaltė, bet rodo, kiek tokių serverių kaip jūsiškis yra pasaulyje.
4. 4
   Ar klientai sako, kad jūsų laiškai patenka į šlamštą? Paprašykite pažįstamo su Gmail dėžute: nusiųskite jam laišką ir paprašykite pažiūrėti, kur jis nukrito. Vienas testas pasako daugiau nei bet kokie tikrinimo įrankiai.

Dalį šių dalykų galima patikrinti automatiškai: mūsų nemokama svetainės patikra aguard.lt/patikra parodo, ar jūsų pašto serverio IP adresas yra Spamhaus ar Backscatterer sąrašuose, kokiu vardu serveris prisistato kitiems serveriams, ar sutampa jo DNS įrašai ir ar domenas turi SPF, DKIM bei DMARC įrašus. Persiuntimo nustatymų iš išorės nematyti, todėl pirmą klausimą vis tiek teks užduoti skydeliui arba teikėjui.

Ką daryti

Teisingiausias sprendimas yra pats paprasčiausias: nepersiųsti. Dėžutę info@ pridėkite prie pašto programos kaip atskirą paskyrą, ir laiškai bus ten pat, kur visi kiti.

Telefone tai daroma per dvi minutes: „Gmail“ programoje pasirenkate „Pridėti kitą paskyrą“, tada „Kita“, įvedate info@ adresą ir slaptažodį, ir programa prisijungia prie jūsų serverio IMAP ryšiu. Tą patį moka „Apple Mail“, „Outlook“ ir „Thunderbird“ kompiuteryje. Rezultatas jums tas pats: info@ skaitote ir atsakote iš to paties telefono. Skirtumas esminis: laiškai lieka jūsų serveryje, programa juos tik skaito, o serveris niekam nieko nesiunčia ir nieko negrąžina.

Įspėjimas tiems, kas ieškos senojo būdo. Gmail žiniatinklio versijoje buvo funkcija „Pašto iš kitų paskyrų tikrinimas“: Gmail pats periodiškai parsinešdavo laiškus iš svetimos dėžutės. Google ją uždaro: naujiems naudotojams ji nebeįjungiama nuo 2026 m. antrojo ketvirčio, esamiems veiks iki 2027 m. sausio. Ironiška, bet kaip pakaitalą žiniatinklyje Google siūlo būtent automatinį persiuntimą iš kito teikėjo, tą patį nustatymą, apie kurio pasekmes šis straipsnis. Todėl rinktis reikia ne tarp persiuntimo ir Gmail funkcijos, o tarp persiuntimo ir pašto programos su IMAP.

Pavyzdys: „Gmail“ programa telefone, „Pridėti kitą paskyrą“, tada „Kita“. Dėžutė info@ prijungiama tiesiogiai, be jokio persiuntimo.

Jei persiuntimas tikrai būtinas (pavyzdžiui, bendra dėžutė keliems darbuotojams skirtingose tarnybose), reikia, kad jis būtų padarytas teisingai, ir čia darbas gula ant prieglobos teikėjo. Trys klausimai, kuriuos verta jam užduoti raštu:

• Ar jūsų serveris filtruoja šlamštą prieš persiuntimą, o ne po jo? Google savo rekomendacijose administratoriams tiesiai siūlo šlamštą atpažinti dar prieš persiunčiant.
• Ką daro serveris, kai persiųsto laiško nepriima gavėjas? Teisingas atsakymas: pranešimas lieka dėžutės savininkui arba tyliai išmetamas, bet niekada nekeliauja į pradinio siuntėjo adresą.
• Ar serveris prisistato savo tikru vardu, turi atvirkštinį DNS įrašą ir pasirašo mūsų domeno laiškus DKIM parašu?

Jei teikėjas į šiuos klausimus negali atsakyti arba atsako „pas mus viskas veikia“, tai jau atsakymas.

Kaip tai sutvarkėme

Pasakoju tam, kad būtų aišku, kiek tai trunka. Tą pačią dieną iki pietų išjungėme persiuntimą abiejuose domenuose; dabar įmonė info@ skaito tiesiai iš serverio per pašto programą. Serveris pradėjo prisistatyti tikru pašto vardu. Visiems serverio domenams įjungėme DKIM parašus, o nepavykusio pristatymo pranešimai, jei tokių atsirastų, nukreipti į pačią dėžutę, o ne į laiško siuntėją. Po pietų pateikėme prašymą „Spamhaus“; po dviejų dienų gavome atsakymą, kad įrašas pašalintas, su perspėjimu, kad problemai pasikartojus adresas bus įtrauktas vėl. Dvi dienos, per kurias dalis įmonės laiškų nepasiekė adresatų. Kiek jų nepasiekė per dešimt dienų iki tol, galima tik spėlioti.

Paprasčiausia pamoka iš visos istorijos: paštas yra vienintelė infrastruktūros dalis, kurioje jūsų klaidas pirmiausia pajunta svetimi, o jūs patys sužinote paskutinis.

Atidarykite savo prieglobos skydelį ir pažiūrėkite, kur keliauja jūsų info@. Tai užtruks mažiau nei perskaityti šį tekstą.

Dažnai užduodami klausimai

Šaltiniai

• Spamhaus, „FAQs on Combined Spam Sources (CSS) Blocklists“: https://www.spamhaus.org/faq/section/Spamhaus%20CSS
• Google, „El. laiškų persiuntimo į „Gmail“ geriausia praktika“: https://support.google.com/mail/answer/175365?hl=lt
• Google, „El. laiškų siuntėjų gairės“ (autentifikacijos reikalavimai, klaida 5.7.26): https://support.google.com/mail/answer/81126
• Google Workspace, „Gmail SMTP errors and codes“: https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes
• Google, „Informacija apie būsimus „Gmailify“ ir POP prieigos pakeitimus sistemoje „Gmail““: https://support.google.com/mail/answer/16604719?hl=lt
• Microsoft, „Backscatter in Microsoft 365“: https://learn.microsoft.com/en-us/defender-office-365/anti-spam-backscatter-about
• Backscatterer.org (UCEPROTECT), sąrašo aprašymas: https://www.backscatterer.org/
• Hostinger, „Kuo skiriasi el. laiškų peradresavimo bei persiuntimo paskyros ir el. pašto pseudonimai“: https://www.hostinger.com/lt/support/?p=264
• VLKK Terminų bankas: brukalas (šlamštas), automatinis persiuntimas: https://terminai.vlkk.lt/
• Kliento pašto serverio žurnalai, 2026 m. spalio 20–29 d. (skelbiama su kliento sutikimu, identifikuojantys duomenys pašalinti).

Pastebėjote klaidą ar pasenusį skaičių? Parašykite, pataisysiu ir pažymėsiu. Kaip rašomi šie straipsniai