SPAM – greylisting ve firmě

21. 10. 2008 | Ondřej Valoušek

Články - SPAM – greylisting ve firmě  

Šéf mě požádal, abych zpracoval antispamové řešení pro naši firmu. Proč o to požádal právě mě, když na stole byl i návrh na zakoupení "černé antispamové krabice" od renomované firmy za 10 000 euro, která to vyřeší sama od sebe?

Počáteční stav

Nežli popíši počáteční stav naší firemní sítě, rád bych alespoň v kostce čtenáře AbcLinuxu.cz seznámil s tím, proč si myslím, že s problémem SPAMu musíme bojovat.

Proč tedy? Asi proto, že historie SMTP (tedy protokolu zodpovědného za přenos elektronické pošty), je stará přes 20 let, kdy nikdo ani nepomyslel, že by se e-mail mohl zneužít takovýmto způsobem. I otázky, proč to ti spammeři vlastně dělají, ztrácí smysl, když si uvědomíte, že poslat někomu e-mail je zdarma - pokud pošlu někomu neznámému mail s textem "Give me some money", pravděpodobně se zasměje a mail smaže. Pokud však tento mail zašlu pár milionům nic netušících lidí, vždycky se najde nějaký pitomec, který mi zaplatí. A pokud se najde, rád podobný mail zašlu lidem zas - vždyť je to přeci zdarma a zpáteční adresa se dá krásně zfalšovat, takže tisícovky rozzlobených lidí nemají, na kom si právem vylít svoji zlost.

A právě takovou zlost jsem měl i já, když jsem musel každý den mazat desítky nevyžádaných mailů. A tak jsem začal zkoumat, jak naši firemní síť "vylepšit", abych tento neustálý tok mailů zastavil.

Topologie firemní sítě

Jak je vidět z obrázku, konfigurace firemní sítě byla v podstatě standardní - maily z Internetu procházejí firewallem do MTA (Mail Transfer Agent - v podstatě mašina, která mail vezme, rámcově zkontroluje a pošle dál) v zóně DMZ. Tento stroj funguje jako relay agent - maily s vnitřní e-mailovou adresou tak přeposílá na vnitřní mail server na intranetu. Odtud jsou pak přímo dostupné koncovým uživatelům.

Jako MTA zde funguje osvědčený Sendmail a v interní síti MS Exchange (já tlačil Scalix, ale bohužel to neprošlo). Žádný z těchto dvou strojů problém spamu neřešil a filtrování pošty tedy zůstalo na konečných uživatelích (Thunderbird s Bayesovským filtrem).

Problém

Problémy jsme tehdy měli v podstatě dva:

• Nárůst spamu byl takový, že jej koncoví uživatelé dostupnými prostředky nebyli schopni zvládnout (člověk nedělal nic jiného, než mazal maily).
• Mail relay v DMZ nestíhala generovat bounce maily kvůli zfalšovaným adresám odesílatele, tvořily se fronty a odeslání legitimních mailů trvalo hodiny i dny.

Generování bounce-mailů

U problému s generováním bounce-mailů (hlášení o nedoručitelnosti) bych se rád pozastavil, protože si jej mnoho administrátorů MTA (a sítí podobných té naší) neuvědomuje. Představme si větší společnost s doménou @example.com, která má svůj firemní mailserver na lokální síti a maily do internetu posílá a přijímá přes proxy MTA server připojený v demilitarizované zóně - tedy něco jako naše síť na obrázku výše.

Na první pohled z hlediska bezpečnosti výborné řešení, protože vnější útočník se nikdy nemůže dostat přímo na firemní mailserver. Problém ale nastává právě s generováním mail bounces, protože proxy MTA v demilitarizované zóně bude pravděpodobně konfigurován jako RELAY pro celou doménu @example.com a o existenci uživatelských účtů na koncovém mailserveru nebude mít ani tušení.

Pokud tedy přijde spam pro neexistujícího uživatele jarda@example.com, relay MTA v demilitarizované zóně jej s radostí přijme a přepošle firemnímu mailserveru. Ten jej odmítne, protože žádný mailbox pro Jardu nemá, a relay MTA v DMZ tedy musí vygenerovat mail bounce.

V normálním případě by to bylo to v pořádku (mail bounce vygenerovaný proxy MTA by dostal odesílatel a zjistil, že Jarda neexistuje). Pokud by však byla adresa odesílatele podvržená (což je u SPAMu běžný jev), bounce je doručen někomu, kdo nic takového neposílal. V horším případě doručen být nemůže a mail bounce se nám hromadí ve frontě a zbytečně zatěžuje mailserver.

Řešení situace

Neutěšenou situaci ve firmě jsem monitoroval již dlouho a zamýšlel jsem se tedy nad možnostmi řešení - které by pokud možno neobsahovalo žádnou "černou krabici" za spousty peněz. Nejsem sice zapřísáhlým odpůrcem komerčních řešení, ale nerad se dávám všanc něčemu, do čeho nikdo nevidí. Problém jsem rozdělil na dvě části:

• Vyřešit otázku generováni bounce mailů
• Vyřešit otázku detekce spamu

1. Mail bounces

Problém jsem vyřešil pomocí perl skriptu, který je v pravidelných intervalech spouštěn na vnitřním mailserveru a generuje seznam platných firemních emailových adres. Tento seznam je pak pomocí TFTP stáhnut na MTA proxy stroj v zóně DMZ. MTA má pak možnost přímo v otevřeném SMTP spojení ověřit existenci adresy příjemce. Pokud neexistuje, spojení je ukončeno s chybou 550 Recipient not found. Za vygenerování mail bounce je pak zodpovědný vnější odesílatel (ať už pravý, nebo ne).

Jiným řešením by bylo zkonfigurovat LDAP podporu v Sendmailu, který by si sám mohl existenci příjemce ověřit zasláním dotazu přímo na vnitřní LDAP server, ovšem to by znamenalo jisté bezpečnostní riziko, a proto jsem zvolil cestu pomocí tftp.

2. detekce spamu

Jako administrátorovi mailového serveru mi bylo jasné, že neexistuje jediná jednoduchá metoda, jak spam potlačit, a proto se obvykle kombinuje metod více. Není proto ani cílem tohoto článku představit nějakou "zázračnou" novou metodu - spíše shrnout dostupné metody a doporučit nejúčinnější.

V zásadě můžeme antispamové metody rozdělit takto:

Klient (MUA)/server (MTA)

Podle toho, jestli pracují na koncovém mailovém klientovi (např. Thunderbird) nebo přímo na SMTP serveru (např. Sendmail). Obecně je řešení integrované v MTA efektivnější, protože jen MTA má přístup k obálce mailu a také má možnost mail odmítnout ihned a snížit tak zátěž lokální sítě.

Aktivní/pasivní

Podle toho, jestli nějakým způsobem komunikuje s externími zdroji, aby rozhodla, jestli jde o spam, či ham - např. externí blacklist nebo Bayesovský filtr vyžadující trénink od uživatele. Při výběru aktivního řešení musíme být vždy na pozoru, aby se nedalo použít k útoku DoS (např. při užití DNSBL útoku na DNS poskytovatele blacklistu).

SMTP real time/post processing

Podle toho, jestli je mail nejdřív přijat a poté vyhodnocen, nebo jestli umožňuje odmítnutí mailu už během otevřeného SMTP spojení (např. na základě neplatné hlavičky mailu) s odesílatelem. Realtime metody (dále RCPT fáze) samozřejmě šetří zdroje MTA a obecně se jeví jako nejvýhodnější.

Karanténa

Někteří správci volí metodu "karantény", do které přesunou maily "omarkované" podle nějaké metody jako spam. Výhodou je, že uživatel má možnost si čas od času ověřit, jestli v ní neskončil i nějaký "pravý" mail. Já to nevidím jako "to pravé ořechové", protože jak objem spamu narůstá, uživatel ztrácí chuť obsah karantény kontrolovat a pravý mail může být snadno ztracen/zapomenut. To už je lepší podezřelý mail rovnou odmítnout - odesílající strana má pak šanci se bránit (např. telefonicky).

Classic RFC/extension

Extrémně dobrých výsledků lze dnes docílit konfigurací MTA tak, aby vyžadoval přesnou kompatibilitu s RFC specifikací SMTP protokolu (např. dobře známý efektivní greylisting takto pracuje). Jisté je jen jedno, do budoucna bude zapotřebí SMTP protokol doplnit či vylepšit, aby se dosáhlo dobrých výsledků, které budou i trvale udržitelné - touto cestou jdou standardy SPF či DKIM.

3. Metody boje

Uveďme alespoň nejvíce užívané a nejúčinnější (dle mého názoru) metody boje s nevyžádanou poštou. Zde se omezím na řešení integrovatelné do MTA, protože koncového uživatele obtěžují nejméně. Z těchto technik jsou mi nejvíce sympatické RCPT fáze, a to ty, které pracují v úvodních fázích dialogu SMTP:

Blacklisty

Přijímající MTA mail odmítne, pokud se ocitne (podle nějakých pravidel) na veřejně/soukromě udržovaném blacklistu. Obecně nepovažuji jakoukoli formu blacklistu IP adres za bezpečnou a do budoucna udržitelnou. Vzhledem k možnosti podvrhu ani blacklist domén nepřipadá bez dalších opatření v úvahu. I ostatní formy blacklistů narážejí na omezení (někdo to musí udržovat, vysoké riziko omylů - false positives).

Reverse DNS

Hodně administrátorů MTA mail odmítne, pokud pochází z IP adresy, která nemá reverse IP záznam, nebo ho má nějaký "špatný". Toto musím také odmítnout, protože specifikace RFC protokolu SMTP o ničem takovém nehovoří a mnoho nevinných MTA serverů také nemá reverse IP. Jako pomocná pomůcka však ano, proč ne.

Greylisting

V současnosti hodně diskutovaná metoda. Metoda greylistingu [wikipedia, lupa.cz] patří bezesporu k těm nejúčinnějším zbraním, které může spam-aware MTA nabídnout - přesto bych však byl s jejím nasazením trochu opatrný - s ohledem na zpoždění, které vyvolává.

SpamAssassin

Nepracuje ve fázi RCPT, ale vzhledem k jeho oblíbenosti ho přesto zmíním. Je to komplexní antispamový nástroj, který v sobě zahrnuje celou řadu procedur, s jejichž pomocí mail na základě jeho obsahu ohodnotí. Pracuje s celým e-mailem (tedy post-processing metoda) a kvůli tomu (+ dosti vysokým nárokům na CPU a paměť při vysoké zátěži MTA) bych tuto metodu doporučil jen jako doplňkovou. Přeci jen většina filtrů SA počítá s jistou zvyklostí spammerů. Pokud spammeři vyberou jinou taktiku, donedávna účinná technika selže (např: s heuristikou na obrázkovém mailu mnoho nepořídíte).

Sender address verification

Kontroluje platnost MAIL FROM obálky mailu tím, že na ní zkusmo pošle bounce. Musím říci, že nejdříve jsem byl touto taktikou nadšený - pak mi došlo, že s tímto otravuji MTA nevinných a mnohdy podvržených příjemců (nejlepší cesta, jak se dostat na blacklist), a proto se spokojím s její "odlehčenou" verzí kontroly existence MX záznamu domény MAIL FROM případně EHLO.

Kontrola platnosti odesílatele a digitální podpis zprávy

O metodách SPF [wikipedia, lupa.cz] a DKIM [wikipedia, lupa.cz] si myslím, že ačkoli nejsou primárně určeny na boj proti spamu, nelze si do budoucna boj proti nevyžádané poště bez těchto technologií představit. Obě jsou mnohdy prezentovány jako konkurenční, já však SPF (verze 1; SenderID ponechme Microsoftu) a DKIM vidím jako dokonale se doplňující rozšíření SMTP.

Jak už jsem říkal, nejvíce sympatické jsou mi techniky, které pracují v úvodních fázích SMTP dialogu (dále RCPT fáze). V této fázi je již známa adresa odesílatele, příjemce a stroj, od kterého zpráva přichází, ale ne tělo zprávy. Proč mi tedy přijde zajímavá?

1. Tělo zprávy ještě nebylo přeneseno, takže pokud se rozhodneme mail odmítnout, ušetříme strojový čas a přenosové pásmo.
2. Pokud děláme greylisting ve fázi RCPT (mail tedy odmítneme s dočasnou chybou typu "451 You have been greylisted, try again later") šance na zopakování doručení je větší než ve fázi DATA (tedy když už bylo tělo zprávy přijato). Proč? Normální MTA mají tendenci brát dočasnou chybu v DATA fázi jako permanentní error.
3. Pokud se rozhodneme mail odmítnout, za vygenerování MAIL BOUNCE (zpráva o nedoručitelnosti) je zodpovědný odesílatel, ne my - a z toho plynou výhody - viz výše.

Jaké jsou nevýhody technik v RCPT fázi:

1. Samozřejmě nemůžeme nasadit antispamové taktiky pracující s tělem zprávy.
2. Nutná těsná integrace do MTA (např. prostřednictvím milter rozhraní, které je k dispozici pro dva nejrozšířenější MTA - Sendmail a Postfix).

Implementace

Naše firemní MTA je realizována na Linuxu a Sendmailu, proto jsem se rozhodl o nasazení greylistingu prostřednictvím skvělého démona milter-greylist, který běží na mail proxy stroji v DMZ a je tak nejblíže zdrojům SPAMu - a může tam fungovat nejefektivněji (pokud mluvíme o realtime technikách detekce spamu, tak ty je možno aplikovat pouze na tomto stroji - na vnitřním mailserveru to už nemá smysl). Jak název připomíná, základ tohoto démona je v implementaci greylistingu, který je v mém případě prominut odesílatelům s pravým SPF podpisem nebo, těm kteří alespoň disponují podporou TLS [wikipedia, IETF.org].

Závěr

Účinnost mého řešení přesahuje 90 % - a to v podstatě "zadarmo", protože nároky na CPU jsou nízké a dále není třeba nic updatovat a ani se o něco starat. Ano, nějaký spam i tak sem tam proleze, ale pořád je zde ještě možnost nasazení zmiňovaného SpamAssassinu (na který je možno démona milter-greylist také připojit), který by účinnost dále dramaticky zvýšil. Zároveň se rýsuje možnost nasazení dalších slibných technik jako P0f, DKIM a DNSRBL. Stabilita tohoto softwaru je rovněž příkladná, takže určitě mohu doporučit.

Přikládám prezentaci (ODP), kterou jsem vytvořil v rámci propagace greylistingu pro naši firmu.

Diskuse k tomuto článku

[isimluk]

Pěkný čtení, díky

[Radek Podgorny]

Ja pouzivam postfix+postgrey. Rozchozeni prakticky hned, ucinnost velka. Skoda jen, ze nektere mailservery opakuji poslani az za dlouho.

[vencas]

Ano, ano, postfix a postgrey spolu s dotazem na existenci uživatele přes LDAP (mailserver běží na gatewayi, která propojuje internet s intranetem) zlikvidovalo asi 80% mailového provozu. Opakování posílání za dlouho: nejdéle jsem se setkal asi s půlhodinou.

[tomfi]

i taková půlhodina může v mnoha firmách znamenat rozdíl mezi vykázáním zisku a ztráty, mezi chopěním se nabídky a čtením nabídky u které vím, že ji už uspokojil někdo jiný... mám zkušenosti že jsou firmy, které jako chybu hlásí už 15 minutové zpoždění, sice jim mohu vysvětlit, že smtp není technologie s garantovanou dobou doručení... ale to zákazníka moc zajímat nebude a zisk jim to také nezvýší :/

graylisting ... jistě, pro poštu babičky klidně ;)

[Drom]

Fuj, v takovy firme bych teda delat nechtel...

[hwsoft]

Mam to doplneno spamassassinem a lokalnim blacklistem. To se osvedcilo nejvice, blacklist mam hlavne na SMTO clenu, co to neumi nastavit, a bounces mi zatezuji mailserver. Navic to mam nastaveno na vystupu jako transparentni SMTP proxy, cimz eliminuju Wirouse a jako posledni vec jaou limits v postfixu s generovani udalosti tenhle posila moc, jukni zda neni zawirovan.

Chtelo by to jeste nasledujici:
Automaticky zablokovat SPAMMera z vnitrni site, vcetne fredirectu HTTP na lokalni server s upozornenim o omezeni pripojeni.
analyzator nejhorsich SPAMMeru zvenci s tim, ze se daji primo do FW jako REJECT

[voves]

analyzator nejhorsich SPAMMeru zvenci s tim, ze se daji primo do FW jako REJECT

Jako ze treba kvuli jedne postarsi zenske se zavirovanym pocitacem kompletne odstrihnete nejaky jiny freenet? Zajimavy pristup.

[melkors]

Mozna byste se divil, jak rychlo potom ostatni clenove toho freenetu zacnou hledat hrisnika
Inu, hazet salam na neco, kvuli cemu Vam ostatni desive nadavaji ...

[voves]

Vas filozoficky pristup mne silne neimponuje. Zacit neco hledat je zcela jina vec, nez neco napravit. A v pripade vetsich siti to muze byt velmi, ale velmi neproduktivni.

[Valoun]

Ano, ale muselo by to být už na GW toho freenetu.

S tímhle přístupem jsem se setkal na kolejích ve Finsku. Jakmile zjisitili, že někdo dělá rozesílá brajgl, odstřihli ho od netu a povolili přístup pouze na stránky vybraných antivirových firem. O opětovné povolení se muselo požádat osobně. A bylo to poprvé v životě, kdy jsem viděl obýčejné uživatele OPRAVDU se starat, aby neměli zavirovaný počítač a neklikali na kdejakou hloupost.

[voves]

Ano, ale muselo by to být už na GW toho freenetu.

To ovsem mluvite o zcela jinem navrhu hwsofta:

Automaticky zablokovat SPAMMera z vnitrni site, vcetne fredirectu HTTP na lokalni server s upozornenim o omezeni pripojeni.

Je to zcela neco jineho nez se snazit donutit bandu neschopnych loudu ze vzdaleneho mesta, aby precetli logy a nedejboze sahli do konfigurace (ktere od odchodu Jardy nikdo nerozumi) a neco s tim udelali. Vase duvody na ne vetsinou delaji silny dojem jen do okamziku, nez zavesite telefon.

[happy barney]

modelová situácia: banda loudu = firma, ktorá vám zabezpečuje 50-100% príjmu ?

[voves]

???

[hwsoft]

Spatne, nam 100% prijmu zajistuji nasi clenove :D, takze ostatni me zas tak nezajimaji.

[hwsoft]

no a co je na tom spatneho? Mam to v logu, az SPAM storm opadne tak se to vrati do normalu. Navic to je korektni reseni, neporusime zadne RFC, (samo ze zalozni server to musi vedet taky :) ).

Je to asi lepsi, nez dat do FW celou Jizni Koreu, ktera generuje vetsinu SPAM utoku, jelikoz jejcih penetrace M$ produkty je primo desiva :(.

[voves]

Rozhodne je to taky lepsi nez vyhodit do vzduchu budovu evropskeho parlamentu. A to vam staci?

[hwsoft]

Smarja co resis? Nikomu neublizim, oni dostanou od sveho MTA hlasku o nedorucitelnbosti a muzou to zacit resit.

[voves]

Zacit muzou, skoncit nemusi. Freenety jsou utocistem lidi, kteri sice radi resi ale nikdy nic nevyresi.

[Pev]

Smarja co resis? Nikomu neublizim, oni dostanou od sveho MTA hlasku o nedorucitelnbosti a muzou to zacit resit.

Taky se přikláním k názoru to řešit jinak než zakázat konkretní IP...

[petr_p]

To je jejich problém, že jsou za jednou adresou.

[voves]

Jiste, proc neslapnout nekomu na nohu, kdyz muzu, ze. Zvlaste kdyz se bude tezko dovolavat spravedlnosti.

[hwsoft]

??? pokud vim, kazdy ma nejaky kontakt, kam se hlasi problemy. Jestli ty osobne na sve cleny (zakazniky, partnery) kasles, je smutne, ale obecne to tak nefunguje, normalni je, ze se problemy resi.

[voves]

Ja vim az moc dobre z vlastni zkusenosti, jak freenety resi problemy svych zakazniku. Takze si ty svoje recicky odpustte.

[hwsoft]

Joj ty jsi ale kokot. Pro tvou informaci, v NFX je nyni cca 20 tisic clenu, ale zadny zakaznik. A ze by neco neresili, nevim, to spis komercni poskytovatele posledni dobou se snizujicim se ziskem prospousti schopne, a nastupuji lamy, co delaji za malo.

[voves]

Hlavne mi nevykladejte, ze freenety jsou plne schopnych lidi. Naprosta vetsina jsou namysleni ignoranti, co uz davno zapomneli na zakladni internetove paradigma: bud tolerantni na vstupu a presny na vystupu.

[hwsoft]

Vykladam a trvam si na tom. Ti lide to delaji ve svem volnem case jako svuj konicek, tedy nejsou zatizeni nutnosti komercniho vyuziti(prasaren).

Nakonec nekecej a ukaz, kde se co deje spatne?

[voves]

Jen jestli to nedelaji ve svem volnem case jako svuj konicek prave proto, aby to to mohli rikat a zbavit se odpovednosti za chod cele te veci. "Neco nejde? No jo, ale muj den ma taky jen 24 hodin a ja to delam ve svem volnem case a navic jako konicek. Proto vam zablokujeme prichozi maily od vaseho syna, protoze od nej chodi spamy" A nedovolate se. Stal jste se vlastni blbosti pasivnim clenem nejake podivne organizace zhulenejch nymandu. Chcete neco konkretniho? Macros sveho casu lidem, kteri ho k necemu nutili na irc utinal spojeni na routech (protoze k nim mel pristup). Pak jste si v archivu mohl dohledat, jak se po odstrizeni dotycneho o tom s potesenim bavil se spoluzhulenci.

[hwsoft]

tohle jsem nikdy nezazil, zato vylet v jedenact v noci kvuli odesle karte neni vyjimkou. Macrose znam jen jako nick, ale je fakt, ze czfree v Praze a mimo ni je dost velky rozdil. Ale neverim ze lidi jako belgarat, muki nebo danny a jini by se k necemu takovemu snizili. Protoze oni na rozdil od tebe umi a nemaji potrebu si honit triko.

[petr_p]

s/bude/budu

Jak oni na mne, tak já ne ně. Nemám povinnost se od nich nechat obtěžovat.

Zcela běžně adresu zablokuji, aby se jim vracela chybová zpráva ICMP admin prohibited, a na whois tech-c/remark-abuse kontakt pošlu log se stížností.

Poslední dobou (především z Číny) se mi vrací zprávy o nedoručení (mailbox full/account doesn't exist). Když tam mají bordel, ať si ho užijí.

Ano, mluvím o útocích, ne o spamu. Ale problém to je stejný. Jediný způsob, jak zlepšit situaci, je donutit zdroj, aby ho to bolelo. Pak totiž pocítí potřebu záležitost řešit.

Nehledě na to, že rozzuřený soused má mnohem lepší pole působnosti, než já na druhém konci světa.

[voves]

Rozumim vam asi vic, nez si myslite. Zasilani stiznosti je zasluzne (a nemyslim to ironicky), ale to zpusobeni bolesti je s velkym otaznikem. Zalezi na situaci (a pokud jde o utok, tak se s vami zcela ztotoznuji), ale naprikald u spamu, kdyz mate obrovskou sanci, ze takovy spam spravne vytridite, je blokovani vlastne priznanim vlastni neschopnosti. U one bolesti je proste treba vazit, zda ji nezpusobite spise nevinnym nez vinikovi. Navic blokovani dava spammerum velmi efektivni moznost ladit metody a texty. A v neposledni rade jde proti duchu prikazani: bud tolerantni na vstupu a presny na vystupu.

[petr_p]

Zalezi na situaci (a pokud jde o utok, tak se s vami zcela ztotoznuji), ale naprikald u spamu

Když bude uživatel dostávat tolik spamu, že se v něm ztratí ham, tak uživatel takovou službu nebude chtít používat. Efektivně se jedná o DoS a srovnání s jakýmkoliv jiným neoprávněným/neúměrným využití služby je zcela na místě.

kdyz mate obrovskou sanci, ze takovy spam spravne vytridite, je blokovani vlastne priznanim vlastni neschopnosti

Ale já mám takovou šanci obvykle i u automatizovaných útoků. Mám vypracované systémy, které jsou schopny útok rozpoznat a dočasně jej neutralizovat. Přesto pravidelně procházím bezpečnostní hlášení, abych mohl zdroji vynadat.

Trvalou blokaci používám jako prevenci do budoucna (opětovné napadení stejným zdrojem je častý jev) a jako páku na druhý konec, aby byl motivován problém řešit. Pokud se zdroj ozve a zjedná nápravu, adresa je uvolněna.

Vůbec nejde o slabost, naopak se jedná o aktivní obranu. Když jsme u pořekadel, tak znáte to o útoku coby nejlepší obraně?

U one bolesti je proste treba vazit, zda ji nezpusobite spise nevinnym nez vinikovi.

Jistě. Ale v Internetu je nejmenší jednotkou IP adresa. Pokud si za ní někdo staví místní síť, je to skutečně jeho riziko. Na vyšších úrovní je zcela běžné blokování celých autonomních systémů.

Navic blokovani dava spammerum velmi efektivni moznost ladit metody a texty.

S tím jsem smířený. Já také ladím. Nevím, proč bych nemohl s nimi držet krok. Tím se totiž spamování spammerům prodraží, což je pádný důvod, proč přestat spamovat.

bud tolerantni na vstupu a presny na vystupu.

Netiketa má i další přikázání (svým jednáním neobtěžovat). Nemíním být hodný na ty zlé.

[hydrandt]

Taky používám toto řešení, na většině serverů mi fungují ještě blacklisty (požadavek zaměstnavatele), ale asi je brzy vyhodím, případně přejdu na bodový systém spamassassinu (blacklist = plus body).

[Devilkin]

Také bych se rád zbavil blacklistů "natvrdo", ale nikde jsem nenašel nějaký rozumný článek jak donutit spamassassina přidávat jen body za účast v blacklistu . Vsechny postupy se týkají Razora a podobných, ale já bych jen chtěl abych vybral seznam blacklistu předhodil je spamassassinovi a ten by přidal třeba 5 bodů. Jenže takové řešení nemůžu nikde najít. Nemůžu dokonce ani najít nějaké články které by se tím zabývaly.

Přitom jsem si skoro jistý, že by to měla být záležitost dvou řádku v amavis.conf .

Používám klasiku.

Postfix s virtuálními účty (mysql) + amavis-new + ClamAV + spamassassin a na určité emailové účty mam aplikovaný sqlgrey. Tohle by samo o sobě mělo stačit a blacklisty jsem za začátku nepoužíval vůbec, ale začalo tím procházet v určitou chvíli až 20 spamů denně do schránky a to už je prostě moc.

Zvláštní je i to, že přesto že určité maily předhodím sa pomoci sa-learn --spam třeba i 10x, tak pořád ten samý projde . Mám asi 3500 spam mailů a 700 ham mailu.

No asi se tím budu muset začít brzo zabývat, protože blacklisty jsou docela prasárna. Na druhou stranu je ale tahle prasárna účinná a dokonce ani nemusím mail přijmout k analýze, hlavně se to nesmí s těmi blacklisty přehánět a občas projít logy aby měl člověk přehled, co se odmítá.

On by stačil už jen samotný Graylisting, bohužel nesprávně nastavených smtp serverů je strašně moc a není v mých silách obvolávat jejich správce .

[Honza Jaroš]

Také bych se rád zbavil blacklistů "natvrdo", ale nikde jsem nenašel nějaký rozumný článek jak donutit spamassassina přidávat jen body za účast v blacklistu .

Něco na tento způsob v user_prefs by nestačilo? Trošku jsem to rozepsal, ať tam je vidět víc možností...

header __TO_DOMAIN1     To =~ /(<)?[a-z,0-9,._-]+\@(domena1.org|domena1.info)(>)?(;)?[[:space:]]*$/i
header __TO_DOMAIN2     To =~ /(<)?[a-z,0-9,._-]+\@domena2.net(>)?(;)?[[:space:]]*$/i

meta   __TO_VSICHNI    (__TO_DOMAIN2 || __TO_DOMAIN2)

## hnusna@adresa.cz > *@domena2.net
header __FROM_HNUSCZ     From =~ /(<)?hnusna\@adresa.cz(>)?(;)?([[:space:]])*$/i
meta   FROM_HNUSCZ_TO_DOMAIN2  (__FROM_HNUZCZ && __TO_DOMAIN2)
score  FROM_HNUSCZ_TO_DOMAIN     100.0

[Devilkin]

Díky, ale zakázat domény nebo konkrétní maily není problém (nebo jim přidat body).

Já hledám nějakou (bodovou) náhradu za, např.

smtpd_recipient_restrictions = reject_rbl_client bl.spamcop.net

prostě ověřeni IP adresy, jestli není na blacklistu a podle toho jen přidělit body.

Ty blaclisty se pletou jen velmi zřídka, ale stane se to. A proto bych je chtěl jen jako body navíc.

[Honza Jaroš]

Jo takhle. Tak to jsem nikdy nezkoumal, pod Gentoo tam mám nějaké skórování na základě Spamcopu & spol přednastavené a zatím jsem neměl potřebu s tím hýbat. Tohle a tohle by nepomohlo?

[vader]

Pokud nemas nejakou exotickou instalaci spamassassinu, tak staci do konfigu pripsat

score RCVD_IN_SBL  3
score RCVD_IN_XBL  3
score RCVD_IN_PBL  3

skore si muzes zmenit jak chces. Tento priklad pouziva spamhaus.

[ntw]

>...pomocí perl skriptu, který je v pravidelných intervalech spouštěn na vnitřním mailserveru a generuje seznam platných firemních emailových adres. Tento seznam je pak pomocí TFTP stáhnut na MTA proxy stroj v zóně DMZ

Jak je ten seznam připojen do Sendmailu? Do jakého souboru?

ntw

[Ondar]

seznam adres dávám do soubouru access. Sendmail je v podstatě nakonfigurován tak, že relaying je zakázáno kromě příjemců z toho tftp serveru

[Jiří (BoodOk) Kadeřávek]

Nevím jak sendmail ale kombinace SMTP->MTA/Exim->LMTP->MS/Cyrus/SA/ClamAV žádné takto komplikované řešení nepotřebuje. Exim se prostě podívá, zda je mail doručitelný a pokud ne, ukončí konverzaci. Co se týče účinnosti takových řešení z vlastní zkušenosti. Cca 90% mailů je odmítnuto ukončením konverzace, na prošlých 10% je aplikován učící se SpamAssasin a ClamAV s účinností cca 95%. Chybovost je minimální (nejčastěji se týká cizojazyčný mailů), počet prošlých spamů také (nejčastěji české spamy). Celková účinnost je >99%. Vše s open-source komponenty a tou výhodou, že kteroukoliv část procesu je možné libovolně nakonfigurovat.

[ntw]

Sendmail umí ověřovat existenci příjemce přes SMTP také - např. pomocí milteru smf-sav (když už zůstaneme u čistě OSS řešení). Pokud ovšem cílový server (ten s mailboxy) neumí odmítnout neexistujicí alias na SMTP úrovni (typicky qmail server), pak se hodí i takový mechanismus, který je popsaný v článku. Samozřejmě namítnete, že existují patche do qmailu, které to řeší, ale pokud jde o server s mnoha zákazníky (nekolik set domén), tak nemám chuť se v tom moc za provozu hrabat.

Ptal jsem se hlavně proto, že mě zajímalo, jestli je využitý čistě soubor access nebo nějaké chytřejší řešení. Co jsem hledal, tak jsem nenašel ani jak rozdělit soubour access do dvou souborů, což by mně ušetřilo skriptování.

O Eximu vím, ale i když je defaultní v Debianu, tak kupodivu není příliš (zřejmě neprávem) populární.

Když už jsem nakousl smf-sav, používá ho někdo? Mám s ním problém ten, že časem zabírá stále více paměti a občas jej kvůli tomu musím restartovat.

ntw

[Ondar]

Také jsem chvíli používal smf-sav, ale pak jsem to zavrhnul jako ošklivé řešení - právě kvůli tomu, jak pracuje. V podstatě obtěžujete mailservery, které se spamem nemají nic společného. To je hodně blbý. Někdo by se (právem) mohl naštvat a hodit váš stroj do blacklistu. To samé se dá říci o otestování příjemce ve vnitřní síti pomocí smtp - jenom obtěžujete (smtp k tomuto není navržen) mailserver protože nemáte lepší řešení.

[Jiří (BoodOk) Kadeřávek]

To testování se provádí pomocí LMTP, ne SMTP.

[Boris Michelsz]

Len doplnim,

je potrebne aby bol *.cf vygenerovany z *.mc suboru v ktorom zmenime riadok

FEATURE(`access.db', `hash -T <TMPF> /etc/mail/access')dnl

na

FEATURE(`access.db', `hash -T <TMPF> /etc/mail/access', `relaytofulladdress')dnl

Viac tu. Slackware 12.1 to zapnute nemal.

Potom je mozne pouzit v /etc/mail/access nasledovne:

domena.tld              REJECT
znamy1@domena.tld       RELAY
znamy2@domena.tld       RELAY

V logu je potom mozne vidiet ze email sa doruci iba pre adresata, ktory je uvedeny v access. LogLevel je v *.cf nastaveny na 16

O LogLevel=16

----------------------------------

host sm-mta[20482]: NOQUEUE: connect from ukclean.gotadsl.co.uk [62.3.228.105]
host sm-mta[20482]: AUTH: available mech=CRAM-MD5 DIGEST-MD5 LOGIN PLAIN OTP, allowed mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
host sm-mta[20482]: mAE79vta020482: Milter: no active filter
host sm-mta[20482]: mAE79vta020482: --- 220 host.domena.tld ESMTP Sendmail 8.14.2/8.14.2; Fri, 14 Nov 2008 08:09:57 +0100
host sm-mta[20482]: mAE79vta020482: <-- HELO ukclean1
host sm-mta[20482]: mAE79vta020482: --- 250 host.domena.tld Hello ukclean.gotadsl.co.uk [62.3.228.105], pleased to meet you
host sm-mta[20482]: mAE79vta020482: <-- MAIL FROM:<BradwinchMeyer@economist.com>
host sm-mta[20482]: mAE79vta020482: --- 250 2.1.0 <BradwinchMeyer@economist.com>... Sender ok
host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:7<neznamy1@domane.tld>
host sm-mta[20482]: mAE79vta020482: --- 550 5.2.1 <neznamy1@domane.tld>... Mailbox disabled for this recipient
host sm-mta[20482]: mAE79vta020482: ruleset=check_rcpt, arg1=<neznamy1@domena.tld>, relay=ukclean.gotadsl.co.uk [62.3.228.105], reject=550 5.2.1 <neznamy@domena.tld>... Mailbox disabled for this recipient
host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:<neznamy2@domena.tld>
host sm-mta[20482]: mAE79vta020482: --- 550 5.2.1 <neznamy2@domena.tld>... Mailbox disabled for this recipient
host sm-mta[20482]: mAE79vta020482: ruleset=check_rcpt, arg1=<neznamy2@domena.tld>, relay=ukclean.gotadsl.co.uk [62.3.228.105], reject=550 5.2.1 <neznamy2@domena.tld>... Mailbox disabled for this recipient
host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:<znamy1@domena.tld>
host sm-mta[20482]: mAE79vta020482: --- 250 2.1.5 <znamy1@domena.tld>... Recipient ok
host sm-mta[20482]: mAE79vta020482: <-- DATA
host sm-mta[20482]: mAE79vta020482: --- 354 Enter mail, end with "." on a line by itself
host sm-mta[20482]: mAE79vta020482: from=<BradwinchMeyer@economist.com>>, size=717, class=0, nrcpts=1, msgid=<5301016521.20081111192666@economist.com>, proto=SMTP, daemon=MTA, relay=ukclean.gotadsl.co.uk [62.3.228.105]
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, neznamy2@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, znamy1@domena.tld ... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 znamy1@domena.tld, neznamy1@domena.tld> ... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, neznamy1@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 znamy1@domena.tld, neznamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld... Unbalanced '>' (hold)
host sm-mta[20482]: mAE79vta020482: --- 250 2.0.0 mAE79vta020482 Message accepted for delivery
host sm-mta[20484]: mAE79vta020482: SMTP outgoing connect on host.domena.tld
host sm-mta[20482]: mAE79vtb020482: <-- QUIT
host sm-mta[20482]: mAE79vtb020482: --- 221 2.0.0 host.domena.tld closing connection
host sm-mta[20484]: mAE79vta020482: to=<znamy1@domena.tld>, delay=00:00:01, xdelay=00:00:00, mailer=smtp, pri=120717, relay=[xxx.xxx.xxx.xxx] [xxx.xxx.xxx.xxx], dsn=2.0.0, stat=Sent (OK, mail data spooled)
host sm-mta[20484]: mAE79vta020482: done; delay=00:00:01, ntries=1

Snad to niekomu pomoze.

[Max]

V naší firmě bohužel nemůžeme používat greylisting :(. Důvod je ten, že nám přijde objednávka třeba v 10 emailech a je potřeba, abychom je přijali v tom pořadí, v jakém byly odeslány, což se u greylistingu nemusí zrovna dobře podařit.
Zdar Max

[pht]

To se nemusi podarit ani pri normalnim e-mailu. Na to byste si meli radit doslou postu podle data odeslani.

[Max]

Já vím, že ne. Ale když nejsou potíže se serverem, tak téměř není šance, že se tak stane.Objednávky jsou automaticky zpracovávány programem, takže je řadit dle času je na nic. Protože přijde várka, která se zpracuje a zapíše se hned do IS. Kdyby přišel další email za nějakou hodinu, tak je konec. Dělá to komerční produkt třetí strany. Řešení je v plánu :)
Zdar Max

[c]

Clovek ktery takovy system navrhl musi byt vskutku dement, predevsim nejspis vzivote nevidel rfc, natoz neco ohledne fungovani mailu. Copak delate, kdyz mail nedorazi vubec ?

[Max]

Toto vzniklo dalekou předemnou(asi v r. 2002, kdo ví :-/ ). Tento typ objednávek je odesílán stále ze stejných adres, takže to funguje. Řešení je v pořadníku úkolů.
Zdar Max

[Michal Ludvig]

V tom případě greylist klidně nasadit můžete protože těch pár adres budete mít ve white listu a zdržovat se nebudou.

[Max]

Bohužel i tak nemůžeme. Emaily se nesmí zpožďovat.Čím dřív, tím líp(vzhledem k tomu, že to jsou všechno obchodní maily a objednávky). Což je asi ten největší problém :-/. O whitelistu pro greylisting jsem nevěděl, ale bohužel nás to stejně nespasí :-/.
Zdar Max

[Jarda]

Pouzivam ke greylistingu sqlgrey s vyuzitim sql databaze. Pokud vam maily s objednavkami chodi porad z jedineho mista/adresy, pak vam greylist spozdi pouze prvni varku mailu s objednavkou. Pote bude odesilatel/IP ulozen do whitelistu a k zadnemu spozdeni nedojde.

sqlgrey navic implementuje dva whitelisty, jeden zohlednuje dvojici e-mail odesilatele + IP a druhy whitelist sleduje pocet prijetych mailu z konkretni domeny + IP.

Lze nastavit i delku platnosti zaznamu v jednotlivych whitelistech od posledniho mailu, ktery byl prijat na zaklade pravidla v listu.

[Max]

Jj, vím, jak to funguje. Spoždění dochází jen při první komunikaci, pak se záznamy uloží. Bohužel, komunikace není jen s těmi samými zákazníky :-/.
Jinak server nespravujeme my (naše firma), takže o to by to bylo složitější. Mno, uvidíme, každpádně děkuji :).
Zdar Max

[..]

U rozumneho greylist reseni lze udelat seznam adres, ktere se nebudou greylistovat coz je vec, ktera vas problem j

[1john2]

proc v deseti emailech?

[pht]

Ten napad s mail bounces se mi libi. Nejaky napad jak by se to implementovalo do postfixu?

Greylisting se mi nelibi - z me praxe temer vsechen spam odfiltruje spamassassin. Zrovna tak se mi nelibi odmitani spamu, mnohem lepsi je "karantenni" slozka Spam (kterou muzete treba jednou v noci projet a smazat veci starsi 14 dnu). Spamove filtry se totiz obcas pletou, a tato mira falesnych poplachu neni zanedbatelna. Pokud se jako bezny uzivatel nekam nedomailuju, je to mnohem horsi nez kdyz se domailuju ale skoncim ve slozce Spam. Na nejake braneni se telefonem zapomente - jednak to trva moc dlouho (nez se na to vubec prijde! uvedomte si, ze cist bounces neni dnes prakticke zrovna z duvodu spamu), duvera useru v system klesa, jednak telefonovat treba do Indie neni nic prijemneho a jednak to pak bude otravovat spravce serveru aby zavedl whitelist nebo kdovijake nestandardni reseni. Podobne jsou na tom hratky s sikanou kolem uvodniho dialogu SMTP - odesilatelova IP je kolikrat neresolvovatelna, nebo neni jinym zpusobem vse koser a pritom se muze jednat o naprosto legitimni a nadnarodni firmu

[melkors]

Legitimni a nadnarodni firma by SNAD mohla mit penize na zaplaceni nekoho, kdo by jim to uvedl do poradnu. Nebo se pletu?

[Kvakor]

Pokud ma velka nadnarodni firma neresolvovatelnou adresu (osobne jsem to nikdy nevidel), tak jsou jeji spravci nymandi. Ale pokud se korektni, RFC dbajici mailserver s takovouto odpovedi setka, mel by zkusit dalsi MX zaznam.

Proto je resenim mit jako zalohu jeste dalsi, sekundarni mailserver (nap. mailserver providera) - pokud nejaky spatne nakonfigurovany mailserver (napr. s neresolvovatelnou IP, nerespektujici greylist a pod.) neproleze pres primarni, zkusi to u sekundarniho a ten ho pusti. Pokud takovyhle mail potom najdu, tak zkontroluju, proc prosel pres sekundarni mailserver a pokud je duvodem jen neresolvovatelna adresa, dam ho do whitelistu (a pokud clovek, se kterym se komunikuje, neni naprosta lama, jemne ho upozornime na spatne nakonfiguropvany mailserver).

Ale pozor - pokud sekundarni mailserver nema zadnou ochranu proti spamu, polezou skrz nej dovnitr spamy, jejich odesilace berou MX zaznamy od posledniho. Nejucinnejsim resenim pak je dat jak na prvni, tak na posledni misto stroj, ktery sice existuje, ale nebezi na nem SMTP (teto metode se rika NoListing), jako druhy mit vlastni server, jako treti (a obecne dalsi) zalozni servery providera nebo webhosingu a predposledni zase vlastni stroj. Jedina nevyhoda je, ze to chce mit alespon dve verejne adresy.

[pht]

Ono ani nezalezi na tom jestli je nekdo velka firma, nymand, nebo cokoliv, ale jestli ten mail prijde nebo ne.

[tomfi]

Tak tak... je to jako kdyby ženská v ústředně pokládala okamžitě všechny hovory kde volající nezačal tím, že se představí... zvýšilo by to možná vychování volajících, ale asi by si takto vychovaní lidé volali do jiných firem :D

[Ondar]

To je věc názoru. Já zas nesnáším karanténu. V okamžiku, kdy vám za den přijde 100 mailů spamu a po dovolené se tím musíte prodírat i hodiny, tak si říkám ne, tudy cesta nevede. A kromě toho jsme jen lidi takže snadno v tom moři svinstva přehlédnete platný mail. Spamové filtry se občas pletou, to ano, ale přesto bych řekl že pokud podezření na spam hraničí s jistotou, tak bych to odmítnul z fleku v rámci otevřeného smtp spojení.

[voves]

Vy nam neco vykladejte o ucinnosti vaseho reseni. Ucinna reseni znackuji a tridi spam tak dobre, ze nepotrebujete ani po dovolene ani jindy prochazet slozku s vytridenymi spamy sam od sebe "aby vam neco neuteklo". Timto jste potvrdil, ze nasazene reseni dost casto odmita i normalni emaily a vy o tom jen nevite. Zato chcete po odesilateli, aby vam pripadne zavolal.

[Ondar]

No comment

[ntw]

Co je spam nebo ne, může posoudit jen příjemce. Jeden a ten stejný mail doručený dvěma lidem může být pro jednoho spam a pro druhého ne.

[voves]

Ano. Prave proto je treba vyladit filtr tak, ze po dovolene maji uzivatele v mailboxu krome prislusneho poctu pracovnich emailu i par spamu, a ne tak, ze bezhlave zahodim vsechno na vstupu a chlubim se 105% uspesnosti. Zkusenost rika, ze par spamu tydne nikomu nevadi (pokud vidi, ze ve slozce spam jich maji o nekolik radu vic)

[Vladki]

Musim rict ze z me zkusenosti je karantenni slozka zlo. Nekdo "dulezity" vam neco posle - a jako na potvoru to skonci v karantene. Pokud mate v karantene kazdy den 100 spamu a pokud ji kontrolujete jen obcas tak to tutove prehlednete. Odesilatel si mysli ze jste mail dostal a je nastvany ze neodpovidate. Vy ani netusite ze vam neco poslal. Pokud dostane odesilate chybovou hlasku kde uvidi hormadu cizojazycneho textu a v nem nekde vasi e-mailovou adresu, tak zvedne telefon a zavola Vam ze "Vam nefunguje mail".

Karantena s vice jak 10 maily denne je temer ekvivalentni presmerovani do /dev/null.

[Jakub Lucký]

stačí ty maily nějak logisticky prohledávat...

na gmailu jsou na to skvělé operátory: in:spam from:cz

Jednou za čas nakouknu co přišlo z .cz a z několika konkrétních webů co nejsou .cz...

[mrzout]

Pokud dokážete email proskenovat spamassasinem dříve, než odesílateli pošlete potvrzení o úspěšném přijetí emailu, pak je to srovnatelné. V případě spamu odesílateli přes SMTP sdělíte nepřijetí a je na něm, jak si s tím poradí.

Pokud ale email přijmete, a pak z jakéhokoliv důvodu nedoručíte, je to špatně. Může jít o false positive a díky vaší chybě nebude doručen platný email. Buď kvůli tomu budete generovat mraky bounces obvykle na podvržené emaily nebo jste zašantročil email a odesílatel o tom nemá ani páru. Neposlal bych si přes vás dobrovolně ani přáníčko k svátku.

Právě velká výhoda greylistu je v tom, že se email nikde neztratí.

[pht]

Jelikoz vsichni reagovali na muj rant kolem greylistingu a nikdo na otazku s postfixem, tak si odpovim sam:

Je to parametr relay_recipient_maps, ktery lze v jednoduchem pripade nasmerovat na soubor (hash:/etc/postfix/prijemci) ve slozitem pripade nasmerovat na nakou sluzbu.

[Heron]

Hezky napsáno díky.

My používáme greylisting též. Jenže čím dát tím více spamu pochází z běžných SMTP, takže pře greyl. projde. Pak máme nasazen spamassassin, jenže na základě jeho výsledků nic nevyhazujeme, pouze omarkujeme. Ať si s tím uživatel poradí (ono jich není tak moc). Na soukromém mailu mám toto ještě vylepšeno tak, že uživatel může vkládat do složky spam emaily a na ty se v cronu použí sa-learn. A tímto způsobem učí assassina na serveru.

[roman]

ad Generování bounce-mailů - my mame v lokalni siti Domino server, z nej generujeme pomoci LDAP seznam mail useru, ten se prenasi na smtp gateway(debian + postfix), nasledne tedy dochazi k odmitnuti mejlu pro neexistujiciho usera jiz na smtp gateway. toto reseni(skript co vytahuje pres LDAP usery) jsem videl jak pro Domino tak i pro Exchange.

[ntw]

Exchange lze snadno nakonfigurovat, aby odmítal mail pro neexistující aliasy. ntw

[Kovář David]

Věta Realtime metody (dále RCPT fáze) samozřejmě šetří zdroje MTA a obecně se jeví jako nevýhodnější. se mi zdá nesmyslná. Nemělo tam být nejvýhodnější?

[Robert Krátký]

Díky, opraveno.

[melkors]

Automaticke korekce, ze jo?

[Lampa]

greylisting je skvela vec 90% omezeni spamu (pouzivam s qmailem)

co bych mozna pridal tak je BATV (http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation)

proc neodmitat spam(na urcovni smtp), ktery dostane score 15+, kdyz hranice je 5 ?

*** Qmail-Scanner Quarantine Envelope Details Begin ***
X-Qmail-Scanner-Mail-From: "xxxx" via localhost
X-Qmail-Scanner-Rcpt-To: "yyy"
X-Qmail-Scanner: 2.05st (clamdscan: 0.94/8457. spamassassin: 3.2.5. perlscan: 2.05st.  SPAM Found. Processed in 2.227756 secs) process 32553
Quarantine-Description: SPAM exceeds "quarantine" threshold - hits=33.7/5.0/5
SA_REPORT hits = 33.7/5.0
  2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                             [URIs: elite-russian-girls4you.biz]
  1.9 URIBL_AB_SURBL         Contains an URL listed in the AB SURBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  1.5 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  1.5 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  1.5 URIBL_OB_SURBL         Contains an URL listed in the OB SURBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  0.5 URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  3.5 BAYES_99               BODY: Bayesian spam probability is 99 to 100%
                             [score: 1.0000]
  4.3 RCVD_FORGED_WROTE2     RCVD_FORGED_WROTE2
  2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                [Blocked - see {http://www.spamcop.net/bl.shtml?89.121.125.42}]
  0.0 HTML_MESSAGE           BODY: HTML included in message
  1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
                             above 50%
                             [cf: 100]
  0.5 RAZOR2_CHECK           Listed in Razor2 (http://razor.sf.net/)
  1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level
                             above 50%
                             [cf: 100]
  0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
                             [cf: 100]
  3.7 PYZOR_CHECK            Listed in Pyzor (http://pyzor.sf.net/)
  2.2 DCC_CHECK              Listed in DCC (http://rhyolite.com/anti-spam/dcc/)
  1.5 URIBL_SBL              Contains an URL listed in the SBL blocklist
                             [URIs: elite-russian-girls4you.biz]
  0.0 DIGEST_MULTIPLE        Message hits more than one network digest check
  0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS
  3.7 XMAILER_MIMEOLE_OL_22B61 XMAILER_MIMEOLE_OL_22B61
*** Qmail-Scanner Quarantine Envelope Details End ***

[Leoš Literák]

Na abicku je mozne vkladat ke komentarum prilohy

[papundekl]

Lepsi nez tftp stazeni by bylo jakekoliv natlaceni zevnitr site na smtp branu. Otevirat spojeni z vnejsku dovnitr se nevyplaci. Taky soudim, ze maily by se mely znackovat a tridit spise nez zahazovat s tim, ze "vsak on zavola".

[Lukáš Benda]

V dnesni dobe mi chodi vyrazne vice bounce mailu nez SPAMu, protoze se SPAMem si bez potizi poradi filtry, ale bounce maily se jen tak zahodit nedaji :(. A to vse castecne kvuli Graylistu (ktery tvori bounce maily ve vetsim mnozstvi), ale samozrejme hlavne diky retezovym mailum, ktere si tahaji sebou tisicovky zivych adres a kterymi mne nezapominaji kamaradi obdarovat :( a tak se obcas nejaky virus (nebo smap) rozhodne posilat svuj hnuj pod mojim e-mailem.

P.S.: Co kdyby ste posilali bounce maily jenom na e-maly s reverznim IP?

[voves]

MailScanner ma moznost generovat pro odchozi maily vodoznaky, takze pozna prave NDR od falesnych (pokud tedy vase posta odchazi pres spravne zkonfigurovane SMTP brany se shodne nastavenym MailScannerem) Jinak mail na zaklade blacklistu blokuji jen psychopati. Znackovani a trideni je spravny pristup.

[Lukáš Benda]

Takze opravit by se to dalo tak, ze bych bounce e-mail rozbalil podival se na prilozeny "puvodni" e-mail a tam zkontroloval NDR? A nedpovidajici bounce e-maily zahazoval?

[voves]

Pokud vas mail tece pres shodne nakonfigurovane SMTP brany s MailScannerem, nemusite krome nastaveni konfiguraku nic delat. Od leta tohoto roku snad uz watermarking dozral a stiznosti na nej ustaly. Casem ho doufam nahradi plnohodnotny BATV, ale to je beh na dlouhou trat.

[ntw]

To je ideální řešení. Umí to tuším i nějký milter do Sendmailu. Jenomže pokud filtrujete mail pro externí firmy s různými road warriory nebo s odesíláním z firemní domény z domu, či z webmailu, tak tam málokdy donutíte zákazníka, aby všichni zaměstnanci posílali mail ven přes tu správnou bránu (např. domácí ISP blokuje port SMTP port ap).

ntw

[voves]

Souhlas. Ale BTW prave proto stale kazdemu vykladam, ze "znackovat" a ne "blokovat". Pak at se s nasledky svych miskonfiguraci zakaznik pripadne popere sam (pokud zvoli cestu vodotisku). Ja mu rad poradim.

[Kroko]

Tohle jsem vyresil jednoduse, vzdy kdyz nekdo takovej retez posle, tak mu hned vynadam. A uz jsem si vsechny vycvicil tak, ze mi retezi neposilaj :)

[online]

Malý pythonový skript pro Postfix, který do mailu přídává watermark... http://freshmeat.net/projects/inspector/

[maker007]

Poté, co jsme nasadili graylisting ve firmě tak nejprve bylo nadšení protože účinnost byla vysoká. Pak se ale ukázalo, že i spousta regulérních mailů s tím má problémy. Některé mailservery se nepokouší o druhý pokus a rovnou vrátí hlášku o nedoručitelnosti (kterou nikdo nečte!), jiné čekají neúměrně dlouho. Takže jsme ho museli zase zrušit. Zjistili jsem ale, že kombinací ostatních antispamových metod dosáhneme skoro stejné účinnosti bez těchto problémů. Graylisting rozhodně nedoporučuji. Podle mě je celý princip přenosu pošty blbě navržený, kromě hlavičky Received přidané vlastním mail serverem se nedá ničemu věřit. Mělo by to fungovat podobně jako například Jabber. Zkuste poslat XMPP zprávu, kde bude podvržený příjemce nebo odesilatel. V systému mailové komunikace (nemluvím jen o SMTP) je spousta - skoro bych řekl bugů, které se bohužel už tak vžili, že jediná možnost je zamítnout tento protokol jako celek.

[peppa]

a co použít tarpitting (zpoždění odpovědi na EHLO o 15-25 s.)?

[camlost]

to ponechava otevrene porty neumerne dlouho, takze si casem vycerpate pool a hromadi se Vam zpravy ve fronte. navic pres to cas od casu nejaky odesilatel neprojde (mysleno SMTP client).

[peppa]

Portů mám dostatek. Jediné co se hromadí jsou zprávy ve frontě odesilatele - spammera. U Keria tomu říkají Spam Repellent/Odrazování spammerů.

Taky to leckterý spamový bot vzdá a jde dál.

[22/Oct/2008 07:20:34] SMTP Spam attack detected from 94.180.5.153, client closed connection before SMTP greeting

[Ondar]

Jak říkám, greylisting sám o samotě není ideální - ale když to spojíte se SPF kontrolou, tak je to super. Podepisování mailů SPF záznamem je čím dál tím oblíbenější, takže míň mailů je zpožděno..

[priserka]

SPF je smrt pro mobilni uzivatele.

Zkuste poslat postu jako nekdo@nejaka.domena ze site jineho ISP, kdyz ma domena SPF omezeni na konkretni 'proverene' servery pro odchozi postu. Kdyz ma 'jiny ISP' policy, ze nepousti uzivatele na externi SMTP servery (jednu dobu napr. TMobile nevim jak ted), mate dokonale po zizalkach. Budto se ISP prizpusobi (haha) spravci, ktery autorizaci odesilatele povazuje za antispamove reseni, nebo spravce pochopi, ze jeho uzivatele ne vzdy mohou vyuzit jeho postovni servery.

Jenze marketing kolem SPF tvrdi ze SPF je neco jineho nez pro co bylo ve skutecnosti navrzeno (obrana proti podvrzeni from:)...a tak se pouziva hlava nehlava.

[Ondar]

Jasně, ale jinak to přátelé nepůjde. Chceš odeslat email i když jsi na cestách? Fajn, použij náš smtp server ke kterému se autentizuješ. Nemůžu si pomoci, ale mě to přijde férové.

[happy barney]

to neporieši, ak máš blbého providera, čo blokuje všetky 25-tky okrem svojho vlastného. Na cestách máš mať VPN do dôveryhodnej zóny.

[hwsoft]

Dneska uz to musi kazdy, tedy, kdyz ne blokovat, tak jako my redirect na nas mailserver.

Neni to idealni, ale nebudu kvuli nejakymu kokotovi coo z naseho poolu posila SPAM na blacklistech a pak si neposle email nikdo. Oni ti RBL kontroluji cely rozsah pridelenych IP, a pak tam jsem vsichni (Ted bych to mohl udelat, protoze NATuju na IP co je psany na klfree, ale z toho by kluci urcite radost nemeli ).

[Luboš Doležel (Doli)]

To samé je na Silicon Hillu a stačí mít SMTP ještě třeba na portu 1025.

[voves]

To je urcite minus operatora a ne SPF. Kazdopadne muzete pouzit VPN k sobe. A priste vybrat operatora s ohledem na tuto skutecnost.

[ntw]

To ano, ale VPN už do toho vnáší komplikaci a jak známo, nejlépe fungují jednoduché věci. Pak kromě nefunkčního SMTP budete řešit ještě nefunkční VPN.

[voves]

Njn, ale vzato do dusledku, pokud pracujete v podniku, kde si voli operatora podle uplatku managorum, je lepsi si najit jineho zamestnavatele, protoze to casem stejne skonci tak, ze po vas budou chtit provozovat IT infrastrukturu s nulovymi naklady a zvedat telefon i v noci ze soboty na nedeli za podprumernej plat.

[obludka]

To je samozrejme minus SPF, protoze o tehle nectnosti (a dalsich) se vi od jeho prvni publikace (cca 3 roky ?) a presto se jeho evangeliste vubec nijak nesnazi problemy resit. Marketingove se tlaci SPF vsude mozne, aby se pak dalo rict 'vzdyt to pouzivaji vsichni'.

To, ze organizace A zacne pouzivat technologii X by nemelo (ve slusne spolecnosti) mit dopady na uzivatele organizace B - napriklad nesouvisejiciho ISP. Setkal jsem se s adminem, ktery byl podobne 'pritroubly' a nedokazal pochopit, ze pokud hodla autorizovat pomoci SPF, musi vlastnim uzivatelum vysvetlit omezeni a dusledky, napr. prave nutne pouziti VPN aby mohli mailovat pres 'firemni' server.

[voves]

To je snad ale chyba toho admina, ze dela neco, o cem nevi, jak funguje. Evangeliste zduraznovat mohou ba primo musi, ale minus SPF to neni.

[obludka]

Nerikal jsem chyba evangelistu. Je to chyba pracovni skupiny, ktera SPF definovala a 'tlaci' do produkce ... a pritom neresi problemy. Kazda specifikace nejake ma, ale je priznacne, ze u technologie, ktera zpusobuje bundle SMTP + POP na tehoz provozovatele se nejak moc (tzn. radove roky) nesnazi.

[obludka]

... tak omluva - jsem skutecne napsal ze na vine jsou evangeliste (staci si po sobe nejdriv precist, coz jsem neudelal). Mea culpa -- spatne vyjadreno, berte tedy odpoved vyse jako zpresneni toho co jsem vlastne myslel.

[j.]

VPN? Standardni policy (aspon ve firmach kde jsem zatim delal, 5000+ zamestnancu) je, ze firemni maily se posilaji jenom pres VPN a vnitrni servery. Mobilni uzivatel si maily beztak potrebuje taky stahnout, podivat se na intranet, ulozit soubor na server, stahnout data ze serveru, spustit nejakeho klienta, ... Je dost zbytecne resit bezpecnost pro kazdou aplikaci zvlast.

[obludka]

VPN je korektni reseni, jen musi byt spravce ochotny a schopny jej pouzit a uzivatele na takovou vec pripravit. Misto toho se voli 'asymetricke' reseni: my mame striktni politiku pro mailovani, tak ostatni musi uvolnit tu svou, aby NASI uzivatele mohli fungovat podle NASICH pravidel.

[vencas]

Některé smtp servery dokážou (zdá se mi) filtrovat (odchozí, ale to je fuk) maily spamassassinem už ve fázi RCPT. Nevíte jak to dělají? Stalo se mi, že jsem pokusně odesílal mail s viagrou a byl odmínut už při odesílání.

[Lampa]

napr simscan nebo qmail-scanner pro qmail

[juras]

sa-exim

[ZiGi]

napriklad exim vie filtrovat maily vo faze DATA, to je podla mna uplne najuzitocnejsie - po obdrzani celeho mailu ho prehnat spamassassinom/AV a vratit OK/REJECT podla vysledku. nevyhoda je male pozdrzanie medzi prijatim znacky konca dat a odoslanim mailu.

samozrejme sa to nevylucuje s kontrolami vo faze RCPT.

exim tiez umoznuje overit kazdeho adresata SMTP dotazom na koncovom serveri, takze nie je treba generovat kompletne zoznamy adries na vsetkych serveroch.

[Tomáš]

Mohu se zeptat autora, co byla "černá antispamová krabice" od renomované firmy za 10 000 euro?

[voves]

Byl to duvod pro implementaci vlastniho Q&D reseni bez nutnosti hlubsiho porozumeni principum fungovani SMTP :))

[Ondar]

To bohužel doteď nevim sám Viděl jsem to v návrhu rozpočtu od jednoho kolegy a dál jsem se nepídil. Zajímavé je, že i když si tu krabici objednáte tak se s dosti velkou pravděpodobností může stát, že bude fungovat na vlas stejně jako moje řešení.

[Filip Jirsák]

Účinnost mého řešení přesahuje 90 % ... Ano, nějaký spam i tak sem tam proleze, ale pořád je zde ještě možnost nasazení zmiňovaného SpamAssassinu (na který je možno démona milter-greylist také připojit), který by účinnost dále dramaticky zvýšil.

Klasická chyba měření účinnosti spam filtru. Účinnost spam filtru není dána jenom tím, jaký je podíl zastaveného spamu, ale také tím, jaký je podíl propuštěné regulérní pošty. Pokud budete účinnost měřit jenom tím prvním kritériem, je nejúčinnější vypnout mailserver.

[Ondar]

No, měřil jsem to jako podíl pošty co prošla a co neprošla. Pokud bereme, že všechna pošta co neprošla je spam a vše co prošlo je ham, dostal jsem 90%. Vím, není to přesné, ale všechno přesnější by vyžadovalo spolupráci uživatelů. A vzhledem k tomu, že si nikdo nestěžoval (spíše jsem dostal pochvalné komentáře), tak bych řekl, že to i sedí.

[Palo]

Ak vsetka posta ktora presla je "ham" a vsetko ktora nepresla je SPAM tak ucinnost SPAM filtra je 100%. Nie?

[Ondar]

Dobrá připomínka Vlastně jsem to měřil jako poměr odmítnuté a přijaté pošty s tím, že většina pošty je spam. Jak říkám udělat to přesně je vlastně nemožné protože to vyžaduje spolupráci uživatelů (zkuste to když jich máte ve firmě 300)

[Michal Kozlik]

Takze je to vlastne pouze pomer "SPAMU" k regulerni poste. Bohuzel v pripade velkeho objemu regulerni posty se muzete dostat treba k ucinnosti Vaseho reseni rovne 50%. Takove cislo opravdu nic nerika. Je nutne dobrat se poctu false positive a to jak spamu tak hamu a tento udaj pak vztahnout k mnozstvi zbyle posty. Zde ovsem vetsinou narazite na ochotu a schopnosti obycejnych uzivatelu reportovat spatne vyhodnocenou postu.

[hankey]

A já navrhuju služby jako smtp a pop (tedy klasický email) konečně nechat dějinám internetu a používat službu, kde odeslání pošty bude vázané na existenci účtu a nebudeme muset bojovat se spamem. Jsme přesvědčen, že by to stálo mnohem méně peněz, než právě se spamem bojovat, protože spam stojí móc peněz a móc času...
Stejně k tomu dojde...

[Heron]

A jak by sis to představoval? Zejména to "kde odeslání pošty bude vázané na existenci účtu". Co mi dnes brání poslat spam ze zcela regulérní adresy, přes správně nakonfigurovaný SMTP a s existující adresou odesilatele?

[c]

Nedojde, zkuste managorovi vysvetlit, ze ma zahodit toho svyho utlouka a pouzivat neco (cokoli) jineho.

[maker007]

Ono by stačilo, kdyby ten outlook uměl i něco jiného. Samozřejmě, že to nepůjde hned ale postupem času bychom se mohli k tomu dopracovat.

[hankey]

Dojde. Klasický email jak ho známe, bude muset skončit. A už by to chtělo začít používat pomalu něco jiného, nebo to bude pak o to dražší. Managor bude používat stále svůj Utlouk, ale v něm poběží komunikace přes jiné služby než je smtp a pop.

[camlost]

vynecham dlouhe okecavani a zkopiruju sem kousek z RFC 1912:

2.1 Inconsistent, Missing, or Bad Data

Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME.

takze pokud chce s mym serverem nekdo komunikovat, musi se holt chovat slusne a dodrzovat vyse uvedene. (vsak oni se to chlapci z O2 jednou nauci.)

[Ondar]

vidíte, to jsem ani nevěděl. Ale píši si - další argument pro to nastavit tvrdší greylisting pro stroje s nesedícím (pokud vůbec nějakým) DNS záznamem

[voves]

Spravne. Nezapomente zahazovat veskerou postu z non .cz tld. Vasi uzivatele stejne s podezrelymi cizinci nekomunikuji.

[Filip Jirsák]

Teď by bylo ještě potřeba napsat, jak RFC 1912 (navíc Informational) souvisí se SMTP... Podle mne je rozumné se tím, co jste citoval, řídit (navíc pro ISP není problém tohle do DNS vygenerovat automaticky, zmatek v tom začnou dělat až ti, kteří požadují jiný reverzní záznam), ale podle mne není rozumné od druhé strany to striktně vyžadovat. To RFC je jenom informační, ten odstavec začíná should have...

[Vladki]

Co je P0f ?

[Ondar]

http://www.sans.org/resources/idfaq/p0f.php Jinými slovy si můžete říct, že mail z mašin běžících Win95 mail nepřijmete pač tam asi žádný regulérní MTA neběží. Neříkám, že s tím souhlasím, ale je to taky věc názoru....

[Miloslav Ponkrác]

Skvělý článek, opravdu se mi líbí. Přímo na profesionální úrovni.

Jinak já mám pocit, že díky antispamu už nebudu moci brzy posílat maily. Používám adresu @gmail.com a čím dál více příjemců jí označuje jako spam. Důvody? Nebyla odeslána z domény gmail.com, tedy odeslal jsem jí lokálním mailovým klientem, nikoli přes web rozhraní. Zejména u SpamAssasinu dostane ode mě HTML mail z @gmail.com, který odešlu přes lokálního mailového klienta automaticky značku spamu, protože penalizace za neodeslání z gmail.com domény + penalizace za HTML hlavičky u SpanAssasinu se přehoupne většinou přes hranici označující spam. Řeším to dnes tak, že kašlu na ty, kdo takhle blbnou, a pracovně spolupracuji s rozumnými lidmi.

Také řada lidí blokuje maily s jinou, než .cz koncovkou.

[hwsoft]

Probmlem neni ani tak odkud posilas, ale gmail obecne, tak jako ostatni freemaily je hodnocen jako potencialni SPAM. Dulezite emaily mi z freemailu nechodi, zato SPAM a SCAM stale. Konci mezi zahozenymi, ktere ani nekontroluju, jen obcas grepem zkusim projit a pak smazu.

[voves]

No to je opravdu skvely, primo profesionalni pristup. Zeptejte se jisteho strejdy: smtp ssl gmail

Nejvic me fascinuje, jak na rovinu rikate, ze chcete spolupracovat jen se stejne "rozumnejma". To se teda musite cejtit fakt mezi svejma.

[mrzout]

Přesně tak. Gmail jednoduše uznává politiku, že maily z jeho domény musí jít přes něj. Jestli přes Web nebo jeho SMTP je mu jedno, hlavně se odesílatel musí předtím přihlásit.

A pomocí SPF pak se příjemce informuje, zda je odesílatel důvěryhodný nebo ne. Vlastně je to perfektní řešení, škoda že rovnou do SPF nedá doporučení takovou poštu odmítat.

[hwsoft]

To mu obecne nepomuze, bohuzel SSL je do SMTP dobastleno, a tak je nemohu pri navazani spojeni odlisit. Tedy pokud mam redirect (reject) na 25ku, tak ma smulu.

[voves]

Nemohu nez opakovat: zeptejte se jisteho strejdy: smtp ssl gmail

[hwsoft]

OK to ze to google hodil na jine porty, stale neznamena 100% uspech, zalezi na nastaveni FW, lepe by udela posunem portu nad 1024.

[voves]

Vidim, ze pro vas to bude celkem objevne odpoledne. Prikladam vypis z mych /etc/services:

smtps           465/tcp                         # SMTP over SSL (TLS)

A nez svym nebohym clenum zablokujete odchozi tcp na 465ku, tak vezte, ze vetsinou se pri SSL/TLS pozaduje autentizace a pak jsou definovana efektivni pravidla, jak zamezit prilis intenzivnimu rozesilani mailu.

[Ondar]

Ježíš, ty jsi ale trouba žejo? To je síla. Pán si hraje na machra - takový mám nejradši.
Pak bude pro tebe určitě objevné i ten fakt že smtps je už poněkud out-of-date - TLS můžeš honit i na pětadvacítce. Takže mohu 465-ku klidně zavřít.

[voves]

Kdybyste se na chvili zamyslel, pochopil byste. Neni to obtizne. Fakt.

[trekker.dk]

Příště, než napíšeš takovouhle pitomost, tak se zhluboka nadechni, přečti si vlákno, na které reaguješ, ještě jednou, napočítej do deseti.

Pak nebudeš za blbce, protože v diskuzi, kde se řeší nedostupnost portu 25 kvůli blokování poskytovatelem, nenapíšeš, že TLS se dá provozovat i na portu 25.

[mrzout]

Ale to je proto, že gmail má takto nastaveno SPF, vizte http://www.abclinuxu.cz/forum/show/240976#57

Pokud tedy za partnery odmítáte někoho, kdo je schopen pracovat se SPF, škodíte především sobě.

[Ondar]

Koukam, ze strejda voves je asi jediny kok*t ktery se tu v diskuzi objevil - cekal jsem to horsi Kazdopadne s tim gmailem je to skutecne kvuli SPF zaznamum. Posilat maily do site jen tak slo drive a ted to pujde cim dal tim hure - a je to dobre pac jinak by email kvuli spamu vymrel a byl by nahrazen nejakym IM resenim. Zkratka, nema smysl se tomu branit....

[voves]

Hlavne nezapomente blokovat co nejvide mailu. Tak vzacny dar, ze cokoli zablokujete musi byt spam, jen tak nekdo nema.

[ntw]

Já to vidím jinak. Právě příspěvky od vovese mně přišly k užitku.

[Ondar]

Některé ano (kupodivu)....

[svaca]

Ono nema moc cenu se pod clankem o greylistingu bavit s kolegou vovesem, nebo kolegou Jirsakem ... Oni totiz Vase postupy proste neuznavaji, nebot jsou samozrejme spatne, kor kdyz se branite greylistingem a nebo ? No hadejte cim ...

Pocitace jsou tu totiz od toho, aby pocitaly spam a ne se flakaly ...

Sorry za OT, musel jsem si rypnout ..

Jinak super clanek. A zase nejaky normalni administrator ...

[trekker.dk]

A já už jsem se býl, že se tu místní zahodím-co-nejvíc-regulérní-pošty überadmin nevyjádří...

[Filip Jirsák]

Oni totiz Vase postupy proste neuznavaji, nebot jsou samozrejme spatne

Mně je celkem jedno, jaké kdo používá postupy. Mně vadí jenom to, když někdo zahazuje regulérní e-maily. Ale to je asi marné vám vysvětlovat.

[svaca]

Samozrejme, ze nema Protoze zahazuju regulerni maily

[trekker.dk]

S tou smajlíkománií by ses měl léčit.

[svaca]

To vis, ze jo Pro takoveho super admina jako jsi Ty, to samozrejme udelam Hned jsen co zjistim, kam se mi schovaly ty regulerni emaily, sakra

[Filip Jirsák]

Tak e-mail vymře o něco později, protože spamu bude navzdory podobným opatřením chodit jen o málo méně, ale regulární pošty bude pro taková opatření chodit čím dál méně. Takže místo rychlého postupu, který by mohl vést ke snaze e-mail zachránit, bude raději nahrazován postupně a nechá se pomalu zemřít. No, možná je to nakonec dobře.

[gutas]

Já používám amavis, který spouští spamassassina a vyladil jsem to skoro do 100% účinnosti a jsem s tím spokojenej. Používám blacklisty jako součást bodového hodnocení spamu, dále různé db jako razor, pak různý image a pdf filtry a nakonec bayes. Většina spamů má score nad 25 a to je dá se říct dost dobrý. Většinou se ani nestává, že by ham byl hodnocen jako spam a opačně.

[hankey]

Mám pro tebe jednoduché řešení: prostě používej smtp.gmail.com a problémy mít nebudeš.

[Smajchl]

Jelikož dost ISP blokuje ve svých sítích port SMTP mimo jeho vlastniho SMTP proto, aby jeho síť nebyla zbytečně vytížená zavirovanýma počítačema s Windows, který odesílaj tisíce spamů za minutu (možná to je i víc, to nevim), tak potom něco jako smtp.gmail.com nejde používat. Takže začarovanej kruh.

[Filip Jirsák]

smtp.gmail.com na portu 25 nepoužijete pro odeslání pošty mimo gmail.com ani od ISP, který port 25 neblokuje. GMail s TLS totiž běží na portech 465 a 587.

[hankey]

Ale já mu jen radil, jak se zbavit označení "spammer" - protože odesílá @gmail.com přes jiné smtp než je smtp.gmail.com. Já to prve taky odesílal z jiného smtp a taky se mi to vracelo. A teď děkuju za ten veřejný smtp, tzn. ať žije přenosný počítač! Hip hip hurá!

[Filip Jirsák]

Já vás jenom podporuju Vyvracel jsem tvrzení, že od něktrých ISP nepůjde e-mail na smtp.gmail.com odeslat.

[Smajchl]

Tak to je pravda, zrovna u gmailu to pujde, ale jinde ne Tam kde se pouziva nesifrovany SMTP (port 25).

[Bernie]

Nebude to spise zpusobeno SPF zaznamem u domeny gmail.com? Pouzivate jejich odchozi smtp server?

[cenda]

Jiným řešením by bylo zkonfigurovat LDAP podporu v Sendmailu, který by si sám mohl existenci příjemce ověřit zasláním dotazu přímo na vnitřní LDAP server, ovšem to by znamenalo jisté bezpečnostní riziko...

Proč myslíš, že je to bezpečnostní riziko?

[Ondar]

No pač tím vlastně otevíráte díru do vnitřní sítě - pokud bude MTA v DMZ napaden útočníkem, tak si může i pohrát s vaším vnitřním LDAP serverem - to není zrovna lákavá vyhlídka....

[Filip Jirsák]

Jak pohrát? Maximálně si přečte seznam schránek, který má i v tom souboru nahrávaném přes FTP. Předpokládám tedy, že by ten mailserver přistupoval k LDAPu s minimálními možnými právy, nemusí se tam připojovat hned pod administrátorským účtem…

[Ondar]

To je přeci vedlejší - může provést útok na váš LDAP server - DDoS nebo brute force. Důležité je, že má k němu přístup...

[pupu]

Kupovat 'krabici za 10.000 EUR' Vam prijde jako docela dobry napad v okamziku, kdy zjistite, ze mate pul milionu schranek, dva administratory a cim dal tim vic nabusenych serveru s opensourcem, ktere to proste nestihaji, zatimco ta krabice v pohode. Neco bych o tom vedel. Pochopitelne pro firmu o par desitkach lidi to smysl nema (tedy alespon od okamziku, kdy manazer pomoci hrubeho nasili donuti admina, aby reseni zdokumentoval a dokumentaci udrzoval aktualni). Jinak pekny clanek, dekuji.

[Ondar]

No, s nasazení takového řešení pro sítě s půl milionem schránek opravdu nemám zkušenosti ale vím že to v pohodě používají na velkých univerzitách ve Švýcarsku - a tam těch uživatelů taky není málo. Ohledně OSS - neříkám, že se dá nasadit všude ale obvykle když se člověk snaží pochopit problém proč třeba box nestíhá, najde i řešení jak to poladit...

[frr]

Osobně jsem se greylistingu dlouho bránil. Když mi ale objem spamů udávil v malé firmě mailserver (Pentium III) na CPU výkon spotřebovaný ClamAV a SpamAssassinem, rozhodl jsem se jednat. Proboha - na mailserver má stačit 486tka. Takže jsem nerad nahodil greylisting. V kombinaci se stávajícím ClamAV a SpamAssassinem.

Od té doby je klid. Mailserver má load zpátky v nízkých jednotkách procent. Občas někdo zavolá, že mu neprocházejí maily - tak se mrknu do logů, a pokud uznám, že si jeho dementní mailserver naběhl na můj greylisting, omluvím se a přidám ho rukama do tvrdého whitelistu. Takto dementní mailservery (nebo farmy) mívají veliké firmy, někdy dokonce outsourcované od třetí strany - napadá mě slovenský T-Mobile nebo mezinárodní FedEx. Takový dementní mailserver nedělá lokální ukládání a nový pokus po půl hodině, jak bývalo dobrým zvykem (protože dělat tohle pro milion zákazníků by asi nebylo technicky sjízdné), resp. lokální store-and-forward dělá nějaký skrytý uzel ve farmě a díky load balancingu si vybere pokaždé jiný outgoing node, takže Posgrey vidí pozdější pokusy o doručení pokaždé z nové IP adresy. To se nedá nic dělat. Farma se dá ve whitelistu velice snadno povolit uvedením 2nd-level domény, netřeba dohledávat a vypisovat všechny IP adresy.

Podle našich zkušeností optimální zpoždění pro greylisting je cca 20 minut. Existují spam zombies, které to zkoušejí znovu po 15 minutách. Zpoždění o klasickou půlhodinu (navíc jenom při prvním pokusu) není u mailu žádná velká tragédie, kromě situace, kdy se odesilatel s příjemcem zrovna zároveň baví po telefonu a čekají, až proleze příloha...

Jednou jsem zaznamenal, že můj greylisting "clashnul" s kamarádovým "zpětným SMTP dotazem na existenci účtu odesilatele" - výsledkem byl nedoručený můj mail jemu Takže whitelist v Postgreyi a jelo se dál. Osobně pokládám tenhle zpětný SMTP dotaz možná za horší prohřešek než greylisting a méně účinné opatření, protože spammeři často berou adresy odesilatele z harvestované databáze (takže typicky skutečně existují).

Prohledávat SPAMy v karanténě jsem dávno přestal. I s greylistingem jsou jich nízké desítky denně. Zatím jsem nezaznamenal, že bych kvůli SpamAssassinu přišel o nějaký důležitý e-mail.

Osobně si myslím, že definitivní tečkou za SPAMem by bylo důsledně vyžadovat a používat elektronické podpisy a případně podle nich centrálně blacklistovat přímo koncové uživatele. Což ssebou ale dodnes nese spoustu "otravných podružných praktických zádrhelů", jako je už třeba neexistence všeobecně uznávané a důvěryhodné hierarchie certifikačních autorit... Spousta platných certifkátů od de facto důvěryhodných menších CA je klientským softwarem odmítáno, protože zmíněná CA chybí na něčím seznamu, nebo protože ji konkrétní MUA nedokázal ověřit kvůli nějaké technické nekompatibilitě.

Ještě jinak řečeno: bylo by třeba jednoznačně identifikovat koncové uživatele a jednotlivě a nekompromisně jim vtloukat do hlaviček, že SPAMovat se nemá. Teoretickou otázkou je volba trestu - odpojení od sítě, přestupkový nebo trestní postih... Už z doby před nějakými deseti lety si pamatuju dilema internetového providera, jak domluvit dobře platícímu zákazníkovi, který bezostyšně SPAMuje, protože na tom stojí jeho lukrativní byznys Nebo později, co dělat se zákazníkem, který už sice nespamuje okatě přímo z naší sítě, ale obsah SPAMů na něj jednoznačně ukazuje. To byly vždycky interní tahanice mezi adminem a obchodníkem... A to se prosím dělo u zodpovědného providera ve vyspělé průmyslové zemi, který své dobře platící ovečky svědomitě cepoval. Jak donutit k poslušnosti ty smečky zdivočelých zablešených užovek na různých místních freenetech, nebo spamové barony operující z banánových republik na druhém konci světa... při současném administrativním stavu e-mailového systému se vžilo vytloukat klín klínem pomocí různých polovičatých technicistních opatření, která "nejdou k jádru pudla".

[Ondar]

Takový dementní mailserver nedělá lokální ukládání a nový pokus po půl hodině, jak bývalo dobrým zvykem.....

Tak tady se musím tvrdě ohradit. Nazývat mail farmy "dementními mailservery" je nesprávné. RFC nic o nutnosti lokálního ukládání mailů neříká, takže nový pokus o odeslání může naprosto legitimně přijít z jiné IP. A to že vám to nabourá greylisting je vaše chyba - ne jeho.
Nicméně jakás takás obrana tu je, pač takovéhle mail farmy (třeba gmail) mají obvykle definovaný SPF záznam, který můžete užít k whitelistingu. Taky se dá uvažovat, že pokud druhý pokus o odeslání přijde ze stejné podsítě, tak ho vezmete...

Jednou jsem zaznamenal, že můj greylisting "clashnul" s kamarádovým "zpětným SMTP dotazem na existenci účtu odesilatele"

To je klasický případ který už jsem tady zmiňoval - na chybě je váš kamarád, jehož MTA který obtěžuje svým dotazováním jiné mailservery. To je nejlepší cesta jak se dostat do blacklistu. Ideální řešení by mělo být pokud možno pasivní....

[frr]

Díky za Vaše poznámky ohledně SPF - vypadá to jako krok správným směrem, tj. k zodpovědnosti skutečných odesilatelů a jejich přímých providerů. Sice to v principu nebrání spammerům vyhýbat se doménám, které mají definované SPF záznamy, a vesele spamovat s použitím prakticky jakékoli jiné odesilatelské adresy, ale je to další klacek pod jejich nohy a tlačí je to do kouta. Pokud se SPF bude dále šířit, určitě ho začnu používat - jak jako odesilatel, tak jako příjemce. Těším se na dobu, až penetrace SPF bude taková, že bude možné dovolit si prostě odmítat maily z domén, které SPF nemají (a případné "chtěné provinilce" řešit whitelistem).

Dělat greylisting ne podle IP adresy ale podle nějakého subnetu, to je netriviální. Jednak to komplikuje základní jednoduchý algoritmus postgreye, druhak zmíněné nájemné odesílací farmy jsou často multi-homed, jednotlivá IPčka ve farmě patří do několika různých ASek... Ale souhlasím, že takové chování není v rozporu se SMTP RFC. Dokonce u multi-homed farmy může být i výhodné v tom smyslu, že se případně vyhne nějakému peeringovému problému v globálním BGP.

[Filip Jirsák]

SPF spammery nijak neomezuje – pouze musí u napadeného počítače buď použít skutečnou doménu odesílatele, nebo použít vlastní doménu, na kterou si nastaví SPF dle libosti. Takže vedle blacklistů IP adres budou vznikat blacklisty domén – jenomže nové a nové domény lze generovat snad ještě rychleji, než jak spammer získává nové odesílající počítače.

[Luboš Doležel (Doli)]

Takže vedle blacklistů IP adres budou vznikat blacklisty domén – jenomže nové a nové domény lze generovat snad ještě rychleji, než jak spammer získává nové odesílající počítače.

To se ale stejně dělá už teď - za mail z příliš nové domény mi spamassassin dává body navíc a pokud je doména uvedená v tělě mailu/hlavičkách na spammerském blacklistu, tak už se mail zahodí.

[Ondar]

Ale omezuje. Čím víc domén bude s platným SPF podpisem tím větší klacek pod nohy spammera. A vlastní doména? Za tu se musí jednak platit (takže spamovat už není zadarmo) a ani ten SPF záznam si nemohu nastavit jak chci - záznam jako "v=spf1 +all" vypadá dosti podezřele ne? Takovou doménu mohu hned označit za spammerskou.

[Filip Jirsák]

Platí se za vlastní doménu 2. řádu, navíc různé banánové republiky určitě nabízejí domény za hubičku. Vygenerovat si x domén 3. řádu na jedné placené doméně, a pod nimi třeba další domény tak, abyste měl SPF třeba pro céčkové sítě, to je jednoduché. proti tomu pak musí postupovat nějaký člověk, který rozhodne, že všechny tyhle domény jsou spammerské a zařadí na blacklist rovnou tu doménu 2. řádu. Automaticky to dělat nejde, představte si, že někdo hackne DNS server nějakého zapadlého ústavu lékařské fakulty UK, a někdo by na základě toho rovnou zařadil celou doménu cuni.cz i s poddoménami na blacklist.

[Ondar]

zas - na druhé straně - kolik legálních mailů k vám zamíří od jarda@uroven.uroven.cz ? Velmi, velmi málo - klidně pak mohu říci (až mě to bude trápit), že SPF beru v potaz jen z 1 a 2 řádu a vše ostatní jako kdyby nebylo podepsáno....

[Filip Jirsák]

Záleží na tom, kolik máte do činění s nějakou univerzitou…

[happy barney]

hmm, a čo .co.uk ?

[$L@$h]

třeba spousta nadnárodních firem a korporací toto používá - cz.firma.com

[motyq]

toto jsem v predchozim zamestnani s uspechem vyresil pomoci assp (zkousel jsem i jine moznosti) - perl software, ktery v sobe zahrnuje snad vsechny myslitelne techniky boje proti spamu. Konfiguroval jsem to do stavajiciho prostredi kde bezel symantec smtpgw a za nim exchange. Prakticky po tydnu ladeni bylo hotovo. Umi to ucici rezim, kdy si to pouze plni databazi, markuje, loguje - ma to hromady funkci, takze tuto funkci jsem dost pouzival na samotne ladeni. Pote prakticky 100% uspesnost - pocet mailu(spam+regulerni posta)/den komplet pred zavedenim byl cca 6milionu. Regulerni posty je tak 5000/den. Jenom jeste detail - neni to smtp server, ciste takova gateway pres kterou to tece, takze to tam zustalo nasazene mezi symantec smtpgw a tim exchangem. Zajimava moznost je generovani whitelistu pri pruchodu mailu smerem ven - respektive generovani tupletu prijemce/odesilatel, pokud prijde posta se stejnym tupletem zvenci, lze nastavit, ze nebudou pravidla tak restriktivni. Take tu nekdo zminoval moznost ldap/active directory kvuli dorucovani posty pouze realnym uzivatelum - to lze nastavit. Mozna to ted vypada jako bych to dealoval, ale v dobe rozchazeni tohoto reseni, jsem s tim byl zcela unesen... Ted uz pracuji jinde, ale ac se v minule firme vymenilo spousta veci, tak toto porad pouzivaji :)

[BoBLO]

Ano, mozem potvrdit! Po mesiacoch experimentovania so vsetkym moznym som pred dvoma rokmi nasiel ASSP - a dodnes zostal. Toto jednoduche, a pritom funkcne bohate riesenie integruje takmer vsetko, co sa tu spominalo (greylisting, RBL, SPF, SRS, black-white-red-listy, bayes-filtre...) a vsetko mozno spustat v testmode, odladit a potom spustit naostro. Pekna vlastnost je reaktivita na spatnu vazbu od pouzivatelov, okrem toho jednoducha konfiguracia a komfortne webovske rozhranie pre administraciu. Skvely kusok!

[motyq]

hehe, zrovna predevcirem jsem komunikoval s mym nastupcem v minule firme update na 1.3.3.10 verzi :) Co jsem se tak ptal, tak od te doby (ted uz cca 3 roky) nevedi co je spam. Bylo to jeste zajimavejsi v tom, ze firma komunikovala cesky, anglicky, holandsky, nemecky a ja nevimjakejmajeste jazykama + hromadu ruznych nabidek, ktere byly realne, ale ja osobne bych je vyhodnotil jako spam uz od pohledu.. jsem rad ze to jede dodnes. Pokud si pamatuju tak sefik z toho byl tak hotovej ze prosadil nejake prachy a ty se poslali vyvojarum - myslim neco kolem 1000$. Zvlastni (nebo spise uzasne) na te veci je to, ze kdyz si s tim pohrajes tak nemas zadne false-positive - teda samozrejme hodnoceno subjektivne (+logy), ze od nasazeni do meho odchodu si nikdo nestezoval, ze mu neprislo neco co mu melo prijit, nebo ze mu neodeslo neco co poslal. Co jsem tak koukal tak aktualni verze uz nema problem s ocr pluginem + rovnou plugin pro clamav (to ta verze co jsem sveho casu nasazoval jeste neumela)... Jen kdyby se treba nekdo ptal - assp vazne umi vsechny me zname techniky boje proti spamu. No zamacknu slzu a jdu zase neco plodneho delat.

[motyq]

jo jeste takovy podotek :) s kolegou co tam dela misto me jsem dost v kontaktu, takze neni problem od nej vytahnout ty db, ktere obsahuji vzorky spam/nespam. Pocitam ze po 3 letech uceni uz budou docela pouzitelne :)

[jerrymysak]

nevím co je to spam ve firmě (i doma)mám postfix, blokuju neplatné DNS, potom na blacklisty, pak si to vezme do parády amavis a vyhaze maily co jsou moc velký a se spustitelnými přílohami a nakonec spamassassin se postará o těch pár co prošli. Průměrně mám ve schránce 1 spam / měsíc a to mi chodí denně desítky mailů. Připojuji výpis jen mam ve scriptu chybu a nesčítá mi blokovaný maily kvůli DNS a blokovaný na blacklistech

./stat.sh

Odmitnutych mailu za den 22-10-2008 je 1710 Odmitnutych mailu za mesic Oct je 9486

Podrobny vypis za den 22-10-2008 131 bl.spamcop.net 1578 cbl.abuseat.org 1 sbl-xbl.spamhaus.org ------------------------------- 460 Chybejici zaznam v DNS ------------------------------- 6 Neznamy uzivatel -------------------------------

Podrobny vypis za mesic Oct 307 bl.spamcop.net 9093 cbl.abuseat.org 57 dnsbl.njabl.org 29 sbl-xbl.spamhaus.org ------------------------------- 3475 Chybejici zaznam v DNS ------------------------------- 90 Neznamy uzivatel -------------------------------

[jerrymysak]

trochu mi ro rozhodilo formatovani

[hwsoft]

Tak maly provoz bych chtel taky mit , bohuzel resim mnohem vetsi objemy.

[PaJaSoft]

Dotazovani na directory lze vyresit bezpecne (na zcela stejne urovni jako to udela MTA pri doruceni klasickeho mailu) pomoci nastroju jako milter-ahead (neni zdaleka jediny). I (ne)oblibene groupwarove molochy lze naucit konfiguraci k tomu, aby nedorucitelny e-mail odmitaly primo v envelope a ne az jako bounce... Navic tento zpusob lze jednoduse retezit pres vsechny zalozni MX servery bez jakychkoli problemu (prece nebudeme povolat pristup do lokalni site) a zaznamy (pozitivni i negativni) se mohou cacheovat atd... Jedina okolnost, kterou nelze uspokojive vyresit je to, kdyz primarni server je mimo provoz (a dotycny zaznam neni v cache), pak zaloham nezbyde nic jineho nez to prijmout a pote vygenerovat eventuelni bounce - stale jsem presvedcen, ze chovat se v ramci prislusnych RFC je mensi zlo nez nefunkcni dorucovani (ze Telefonico?!). Dalsi cesta jsou replikace LDAP (pod)stromu, ale IMHO prilis velke kladivo v tomto vyuziti...

Udajna neexistence pravidel a vubec OCRkovani obrazku, rozeznavani PDF/PS spamu atd. uz je take davno uspokojive resena oblast, takze i zde je vhodne sve znalosti zaktualizovat... (jeden plugin do SpamAssassinu (SA) to dela kouzelne - prevede obrazek(-ky) na text a vytvori z toho "interni" e-mail, ktery znovu predhodi SA a ten ho standardni cestou ohodnoti - vyuziji se tedy vsechny dostupne finesy jako v klasickem rozpoznavani a neporovna se vuci statickemu seznamu proflaknutych slov apod.)

Celkove clanek hodnotim jako zajimave cteni pro nekoho, kdo to dostal ve firme na starost a o problematice prilis nevi (existuje dnes jeste nekdo takovy?). Ten kdo se v problematice orientuje je udiven mnozstvi nepresnosti az zavadejicich informaci nebo kategorickych tvrzeni, ktere bohuzel (nebo bohudik) nemaji realne opodstatneni...

[mrzout]

Jedina okolnost, kterou nelze uspokojive vyresit je to, kdyz primarni server je mimo provoz (a dotycny zaznam neni v cache), pak zaloham nezbyde nic jineho nez to prijmout a pote vygenerovat eventuelni bounce - stale jsem presvedcen, ze chovat se v ramci prislusnych RFC je mensi zlo nez nefunkcni dorucovani (ze Telefonico?!).

řekl bych, že čistší řešení je dočasně poštu odmítnout s poukazem na dočasné problémy.

Na druhou stranu, právě SPF docela slušně snižuje pravděpodobnost, že mi přijde bounce na zprávu s mojí podvrženou adresou. Protože jsem si tam dal natvrdo doporučení odjinud odmítnout.

[Jirka]

Spam je bolest. Chtelo by to kompletne novy mailovy protokol, resp. sadu protokolu, ktera bude ve sve vnitrni logice podporovat podpisy (a jejich kontrolu) a to ani ne tak podpisy odesilatele a prijemce, ale hlavne podpisy vsech mailovych serveru, pres ktere dany email projde. Snadno pak pak pujde odlisit "pirata" od normalniho serveru, a snadno pujde sdilet adresy mailserveru, ktere se ukazi jako vadne (at uz z duvody spatne konfigurace nebo nekvalitniho softwaru).

Nikdo si tedy nedovoli odnekud posilat spamy bez radneho podpisu. A pokud ano, bude zahy odhalen a prakticky vsechny ostatni mailove servery se ihned dozvi, ze od te a te masiny chodi spamy. Tu pak odblokuji a jeji spravce se bude muset zacit hodne starat. No a kdyby mel radny podpis, tak sama certifikacni agentura se rychle postara o zneplatneni tohoto zneuziteho podpisu, aby se sama nedostala na seznam neduveryhodnych. Ve vysledku tedy bude zneuzity server izolovan z okoli a jeho majitel to bude muset resit.