Dotaz: Vrací se pošta kterou server neodeslal

[Bohuslav Novak]

Mám server s Postfixem a v poslední době se mi na server vrací hodně nedoručitelné pošty. Kontrolou logů zjištěno, že takovou poštu server neodeslal. Většinou to jsou "Spamy" se změněnou hlavičkou, která ale určuje odesílatele jako existujícího uživatele. Podezření je samozřejmě na něčí zavirovaný notebook. Jak ale efektivně zjistit zdroj této pošty?

---

---

Odpovědi

[disposable]

sender policy framework vznikol prave pre toto

[Filip Jirsák]

Pravděpodobně se jedná o obyčejný spam, který se za chybové zprávy jenom maskuje. Odkud se to k vám dostalo zjistíte z logu serveru – ale budou to různé počítače náhodně po internetu. Pokud si myslíte, že se jedná opravdu o chybové zprávy jako reakce na spam odesílaný z vaší sítě, zablokujte na firewallu odchozí spojení na port tcp/25 z jiných počítačů, než je váš poštovní server, a uživatelé budou e-maily odesílat pouze přes něj. Pokud tedy jde o tak malou síť, že tohle můžete udělat. Jinak by asi bylo nutné logovat provoz na portu tcp/25 a podle toho odhalit, odkud se e-maily odesílají.

[OndraZX]

Mam stejny problem, nedorucitelne zpravy chodi jen na moji e-mail adresu (mam nejpouzivanejsi e-mail) - ostatnim uzivatelum nasi site prozatim ne. Je to vracena nedorucitelna zprava, kde jsem ja uveden jako odesilatel. Jako rozesilatel spamu snad nejsem - jedu na Linuxu , a nevim co by spam mohlo posilat.

Dalsi problem je, ze dostavam hodne spamu z ruska, napsanych azbukou - antispam na tyto zpravy nezabira. Jinak krome "ruskych" a "nedorucitelnych" zprav problem ze spamem nemam.

[Max]

To samé v poslední době řešíme ve firmě :(. tuny spamu, které se tváří jako nedoručená pošta. Nikdo ze sítě nespamuje, páč nikdo nemá přístup na smtp server. Navíc všichni klienti jedou přes proxynu.
Druh tohoto spamu prochází přes mailserver GTSky jako nic a nevíme, co s tím dělat. Jedinou věc, co jsme nezkusili je greylisting, ale ten z jistých důvodů nemůžeme použít :(.
Otázkou je, co s tím a také, proč to ty hovada spamerský posílají, když v tom žádné reklamní kravinky nejsou :(
Zdar Max

[CandySan]

Taktez mi byl z pocatku vycitan greylist a tak bylo nutno se nad nim zamyslet a trochu lip ho nastavit. Vysledek se povedl a dnes uz nikdo nedrzkuje.

postfix+gld+whitelister nastaven tak, ze pokud vyhovi spojeni podle SPF tak se nedela greylist (to zabere na google, seznam a podobne sluzby, ktere vysilaji z mnoha ruznych serveru). Dale gld nastaven tak, aby zaznamenaval pocty pokusu o vysilani zasilky a k tomu nastaven MXGREY (parametr v gld, ktery zajisti, ze kdyz uz pro nekoho prosel - tedy pocet pokusu vyssi nez 2 - smtp server greylistem, pak se jedna o MTA a pro jine trojice z tohoto smtp serveru se jiz greylist neprovadi).

Dale po jednom ci nekolika dnech nechavam mazat vsechny "jednotuku" (ti, kteri neprosli greylistem a tudiz to nejsou mta) a zhruba po mesici nechat smazat ty, kteri se jiz neozvali dele jak ten mesic.

Za velmi kratkou dobu se spolehlive naplnil seznam tech, kteri nemaji spf a zaroven jsou regulernimi mta a vse lita a zadne zdrzovacky uz nejsou. Greylist neni sam o sobe antispamem, ale zachyti neuveritelne mnoho spamu pochazejiciho z ruznych vln virovych epidemii, takze stridave jeho dulezitost neuveritelne stoupne a stridave je jeho vliv minimalni.

Jeste jsem mel snahy vyuzivat ruzne rbl seznamy, ale to se mi vzdy vymstilo, protoze regulerni mail servery (vlastne odesilatele) byvaji spatne nastaveni a tak sami rozesilaji spam a ja dostal obcas na stul vytku ze od nejakeho smudly z horni dolni nejezdi mail, protoze je na seznamu. Samozrejme moje obrana byla zbytecna, protoze smudla sice posila spam, ale on si to nemysli (nevi co s tim) a tak jsem nakonec podlehl a rbl seznamy jsem zrusil.

Kontrole obsahu na strane serveru rozhodne nemuzu verit, takze nakonec ziju jen s greylistem a kontroluju obsah jen v klientovi, kde to muzu jeste osobne proverit, ze tam nic neupadlo omylem (jednou za cas se tak ale stane).

Mam to odzkouseno jednak na vlastni kuzi a pak take v ruznych typech prostredi (ruzne typy firem s ruznym pristupem ke spamu) na mnoha domenach. Nekteri nechteli naprosto zadny spam a spokojili se s tim, ze obcas prisli o mail od nekoho, jini na stejnem sterveru chteli klidne vsechen spam, ale zarucene nechteli ztratit zadny regulerni mail (coz je nejlogictejsi pristup). Nakonec byl dosazen kompromis a mira spamu je udrzitelne nizka a pritom neni odmitan regulerni spam a nejsou pozorovany zdrzovacky.

[Max]

Já nemohu využít greylisting z toho důvodu, že jsou nám zasílány objednávky. Přijde třeba 10 emailů zasebou z jedné adresy. Náš intranetový software je zpracuje, vyextrahuje přílohy, tělo a vloží do našeho informačního systému. Objednávky musí být v tom pořadí, jak byly odeslány. V případě greylistingu by toto nemuselo dopadnou moc dobře a byly by pak velké průtěry :-/. Z toho důvodu u nás greylisting padá a jsme jaksi taksi bez nějakých nápadů :(. Mailserver se spamassassinem patří GTSce a taktéž ho i spravuje. Tuto věc jsem s nimi projednával, ale nedošlo se k žádnému rozumnému řešení :(.
Zdar Max

[CandySan]

hmm... to je pak spatny, pak uz opravdu zbyva jen kontrola obsahu na strane klienta... Nelze se ridit udajema z hlavicek mailu? Je ten soft cizi, nebo si ho pisete sami? Jeste je ve vzduchu nejaka sluba CommTouche coz neznam ale myslenka se mi libi. Kolega mi jednou psal (kdyz jsem podminoval ostre nasazeni jineho softu v ramci testovani namisto nasich puvodnich serveru) tento text "Během pár týdnů bychom měli mít implementovanej CommTouche, což by mělo ty klasický spamy rozpoznávat takřka stoprocentně (placená služba, zjednodušeně: spamy si odchytávaj, dělaj jakýsi CRCy a useři se jich ptaj zda mail s tímto CRCem je spam). Tím by se mělo množství spamů ještě stlačit, takže tady žádnej tlak na gretylisting na unixu není." Ale nedogooglil jsem zadny commtouche, tak buh vi co to je Zatim jsem se na to neptal, protoze greylist bude implementovan do toho softu a to mi stacilo pro povoleni ostreho nasazeni... Kazdopadne se zda, ze podobna technika by byla taktez ucinna proti virovym vlnam.

[Max]

Bohužel, je to komerční dávno nevyvíjené řešení jenž bylo jako doplněk k mailserveru ... :-/
Zdar Max

[Bohuslav Novak]

ja som tento spam zacal dostavat ako reakciu na zalobu na firmu ktora nas spamovala. rastlo to zhruba na 3000 emailov denne na nas 'catch-all' alias pre domenu. cize v mojom pripade to bola pomsta.

SPF je na toto naozaj riesenie: http://www.openspf.org/Introduction

taky utrzok:

You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.

Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.

But it does not have to be this way! The Solution: SPF

[dustin]

V našem případě jsou to odpovědi na spamy, které s naší odchozí mailovou adresou chodí na neexistující adresy.

Existuje možnost nastavit v hlavičce všech mailů odesílaných naším SMTP serverem nějaký příznak, který by byl v chybové odpovědi zachován a podle kterého bychom mohli snadno rozlišovat mezi chybovými odpověďmi na naše vlastní maily (obchodník se přepsal v adrese klienta) a na spamy odesílané odjinud?

[Filip Jirsák]

Obyčejně se v chybové zprávě vrací začátek e-mailu i s hlavičkami, takže by mělo stačit přidat do hlaviček libovolnou vlastní hlavičku X-něco. Ovšem výchovnější by asi bylo dotyčný server, který rozesílá takovýhle spam, zařadit na nějaký veřejný blacklist. Pokud je to tedy skutečně tak, že jsou to odpovědi na spam. Pokud tyhle chybové hlášky rozesílá přímo spammer, bude těch odesílajících počítačů moc a ruční blacklistování bude málo účinné.

[petr_p]

Paradoxní je, že chybové hlášení obálkovému odesílateli je zcela standardní chování.

Jak si představujete, že by měl MTA reagovat?

[Filip Jirsák]

Paradoxní je, že chybové hlášení obálkovému odesílateli je zcela standardní chování.

Bylo to zcela standardní chování v době, kdy se dalo na obálkového odesílatele spolehnout. V případě, že se na obálkového odesílatele spolehnout nemůžete (což je zpravidla případ veškeré pošty, která pochází mimo vaši síť, a dost často to nevíte ani u e-mailů z vlastní sítě), je lepší žádné chybové zprávy neposílat.

Jak si představujete, že by měl MTA reagovat?

Pokud si MTA sám neověřil identitu odesílatele, je nejlepší nereagovat nijak. Protože pokud dnes 80 % posílaných zpráv tvoří spam, a mezi nedoručitelnými e-maily to procento bude ještě vyšší, pak máte více jak 80% pravděpodobnost, že odesláním chybové zprávy pošlete spam.

Bavíme se samozřejmě o MTA někde před cílovým MTA. Cílový MTA by měl, pokud je to možné, odpovědět rovnou během session chybovým kódem.

[dustin]

Mně by tedy vadilo, pokud bych se nedozvěděl, že jsem mail poslal na blbou adresu. Možná je to do budoucna jediná cesta, dokud se nezačne hromadně používat něco jiného účinného. Máte někdo informaci, jaký může být reálný podíl serverů podporujících SPF?

[petr_p]

Ano, mě to také vadí. Problém je, že každé řešení znamená omezení stávající volnosti. A pokud dobře chápu SPF, tak vyžaduje přímé zasílaní mezi SPF vybavenou doménu a cílovým MTA.

V případě chybových hlášení bych se spíš klonil ke kontrole na Message-ID. Stačí si držet kruhovou frontu odeslaných ID a kontrolovat, zda chybová zpráva reaguje na mail odeslaný přes tento server.

[Filip Jirsák]

To záleží do značné míry na tom, jak máte nastaven poštovní systém. Pokud tak, že MTA, který komunikuje s cílovým serverem, dokáže ověřit vaši identitu, pak v případě, že cílový server rovnou odmítne e-mail chybovým kódem, o nedoručení e-mailu se dozvíte. Typicky tedy pokud máte v síti vlastní relay server, který ověří identitu uživatele, pokusí se odeslat e-mail přímo cílovému serveru a pokud ten e-mail odmítne, dokáže váš MTA podle ověřené identity zaslat chybovou zprávu na příslušnou adresu. Pokud ten váš síťový relay server nebude komunikovat přímo s cílovým MTA, ale použije třeba relay ISP, už je o dost méně pravděpodobné, že bude existovat způsob, jak vám chybovou zprávu doručit a zároveň nerozesílat tuny spamu.

Už jsem to tu nedávno psal, jak se vzácně shoduje množina administrátorů e-mailových serverů, které odmítají e-maily podle různých víceméně náhodných pravidel, s množinou administrátorů e-mailových serverů, kteří server klidně nakonfigurují tak, že rozesílá spam. Já se tedy raději řídím pravidlem, že má být služba otevřená v tom, co přijme na vstupu, ale přísná v tom, co dává na výstupu. Tedy že můj server raději přijme spam, než by nepřijal legitimní mail, ale sám nesmí odeslat jedinou nevyžádanou zprávu.

[Michal Kubeček]

Pokud na jedno hlášení o nedoručitelnositi vámi odeslaného mailu připadne stovka hlášení o nedoručitelnosti mailů, které někdo poslal s vaší adresou coby odesílatele, tak se to dost možná nedozvíte stejně, protože to v té hromadě odpadu přehlédnete.

[dustin]

Obávám se, že kdybychom měli do veřejného blacklistu dávat servery, které odpovídají chybovou zprávou na neexistujícího uživatele, pak bychom si za chvíli nic neposlali. Navíc těchto zpráv nám chodí stovky denně z různých serverů, to bychom nedělali nic jiného.