Názory k článku Greylisting aneb kladivo na spam

Kontrolovat, zda se v komentáři nevyskytují slova "porucha" a "osobnosti" nebo "psychopat*" a pokud ano, tak ho odstranit.

Moc hezké řešení má Jakub Steiner tady: http://jimmac.musichall.cz/weblog.php
Ve formuláři na odeslání komentáře je otázka "Are you an annoying spammer?" a odpověď je předvyplněná na "yes" a když to člověk nezmění, tak se komentář zahodí ;-)

Nedavno jsem svedl boj s automatizovanym hlasovanim. Nejaky vytecnik postupne vylepsoval svuj scriptik tak, ze dokazal prijimat cookies, rozlisoval prejmenovane a zprehazene inputboxy, dokazal i odpovidat na polymorfni otazky. Kdyz se proste nekdo zameri zrovna na Vase stranky...

Proc to pisu - nakonec jsem pouzil nasledujici zatemnovac: http://nenya.ms.mff.cuni.cz/~holub/imagescure/. To uz nerozdychal a bylo po problemech.

jo jo :)
pokial neobjavi toto:
http://yann.lecun.com/exdb/lenet/a31.html

Neni nad to naletet na perfektni prezentaci :) Taky si nejakou udelam, hehe

Vim ze bych nemel (je to mimo tema), ale neda mi to, protoze jsem se tomu dlouhou dobu venoval. Tahle metoda funguje nadherne dokud pracujes nad malou domenou. Jakmile ji ale zvetsis treba prave o pismena, nedejboze i s rozdilem mala/velka a rozdilnymi fonty, tak i s drobnym mnozstvim transofrmaci je to naprosto v haji - neuronova sit prestava konvergovat, nebo konverguje k jinym hodnotam.

perfektni prezentace neni vsechno ;) chce to mit i jmeno ktere je ve svete vedy zname, vid Peto

Na php.vrana.cz je geniální řešení, které opravdu funguje.

"Taková situace si samozřejmě žádá nějaká opatření a snad žádný admin už dnes neprovozuje mail server, na kterém by nebyla alespoň základní ochrana proti spamu."

Bohuzel takove firmy znam, napr. forpsi.cz. Maji mail-relay pro redirect posty ktery vubec nekontroluje zda je odesilajici PC vubec autorizovane posilat mail (odkazuje na nej MX zaznam, sedi reverzni lookup) resp. prijima postu i z adres, ktere reverzni zaznam vubec nemaji.. takze je to jedina dira v relativne bezpecnem svete, veskery spam ke me chodi pres ten server (zbyle 2 cesty, skolni/firemni mail jsou chraneny) a admini s tim uz rok nic nedelaji.

No, na chybejici IPv4 revezni zanam se nedila vic firem, na IPv6 reverz snad temer nikdo.

Aby spmamer nepockal par minut a nepustil robota jeste jednou...

Každý mail má jednoznačný identifikátor (Mail ID), musí být poslát identický mail (tedy pouze resend). Z toho mi vyplývá, že musí spammer nějakým způsobem donutit mailserver o resend. Vzhledem k tomu, že spammeři používají různé windows udělátka, které fungují jako MTA, tak to funguje docela dobře.

Souhlasim - globalni nasazeni povede k tomu, ze se bude posilat 2x tolik spamu co ted... Vzdy po provedeni urcite casti se projede znova. A to ty spamovaci prg nebudou tak blbe a rozpoznaji IP kam se posila, takze oni si usetri prenosy/cas, o coz jim jde, majli dojnou minimalne 1x (rade chudaku asi 2x), a budeme tam kde jse byli.

Uz dnes jsou spamersky programky pomerne sofistikvoany utility, takze.... Existuje duvod, proc si myslet, ze se tomu neprizpusobi ?

R.

Také si myslím, že je to dosti slabý způsob bohe proti spamu. Z hlediska spamerů stačí velmi málo a greylist je k ničemu. Škoda času autora, který o tom psal článek a škoda mého času, že jsem ho četl a také psal tento komentář :-)

Mějte se hezky

TK

Greylisting funguje dobře proti spamu, ale nikde jsem se nedočetl, jak to rozumně nastavit pro případ, že má doména ještě sekundární MX záznam. V případě chyby by posílající poštovní server měl zkusit doručit email pomocí druhého MX záznamu. Pokud i na záložním serveru bude greylisting, skončí pokus opět chybou. Avšak už to, že se posílající server pokusí o doručení pomocí druhého MX záznamu znamená, že se pravděpodobně nejedná o jednoučelový program na posílání spamu ale o plnohodnotný poštovní server. Pokud greylisting na záložním serveru nebude, bude přes něj chodit spam, protože hodně spamerů využívá rovnou sekundární MX záznamy právě proto, že očekávají menší ochranu na těchto strojích.

ja exportujem z primarneho mxka z sqlka virtual_alias_maps a virtual_alias_domains ktory nakopnem do sekundarneho mxka a tam kontrolujem cez relay_domains a relay_recipient_maps
tym padom sa zo sekundarneho mxka da poslat email iba na existujuce adresy danej domeny
takze uz ziadne mailer-daemon sracky v postfix queue :)

No mohol by si napr. zdielat databazu greylistu medzi tymito serverami. Napr. cez SAGATOR je mozne robit greylist nad SQL databazami, mozes zvolit napr. MySQL a ten dat replikovat (obojsmerne) medzi 2 servery. Tym by si dosiahol, ze na druhom serveri to uz moze byt prijate, ale muselo by to vyhoviet nastaveniam greylistu (takze nesmie poslat mail na 2. server skor, ako je minimalny cas medzi dvomi pokusmi, ktory mozes taktiez konfigurovat).

V pripade obycajneho greylistu by oba servery mali mail zamietnut (4XX) a po case by sa odosielatel mal opat pokusit o durucenie, pricom kazdy z takto skusenych serverov by mal spravu uz prijat. Proste budes ucit greylist na oboch serveroch.

Presne kvoli tomuto som musel nedavno sekundarne MX zrusit...chodil tade IBA spam, nic ine. A ked primarny MX nahodou par hodin nejde, tak sa nic nedeje - spravi to akurat taky prirodzeny graylisting :)

na to funguje finta

MX 10 serverA
MX 20 serverB
MX 30 serverA

spameři útočí na poslední "nejslaběji zabezpečený" server

presne ;-) takisto som sekundarnemu MX povedal ahoj, pretoze nebol pod mojou vladou a jedine, co sa z neho sypalo bol spam. ako zaloha pri vypadku primaru uz tym padom nebol nijako uzitocny.

> Pokud uz trvate na sekundarnim MX, tak je potreba zajistit, ze bude mit platnou databazi uzivatelu

... a on-line synchronizovanou databázi pro greylisting. Milter-greylist (pro sendmail) něco takového má umět, ale nezkoušel jsem to.

Co se týče farmy mailserverů, setkal jsem se s tímto problémem např u gmailu, kde se pokoušel odeslat zprávu z různých adres, ale časem se opět vrátil k jedné z už použitých a mail prošel. Zpoždění není až tak velký problém, server čeká deset minut a zatim se to zda dostatecne, a vzhledem k učinnosti si na tz maily velmi rád počkám, zde je pár zajímavých čísel:

Statistics since Mon Jul 24 15:25:12 2006 (9 days and 16 hours ago)
-------------------------------------------------------------------
415 items, matching 830 requests, are currently whitelisted
0 items, matching 0 requests, are currently blacklisted
180 items, matching 182 requests, are currently greylisted

Of 6035 items that were initially greylisted:
- 415 ( 6.9%) became whitelisted
- 5620 ( 93.1%) expired from the greylist

Nabízí se otázka - spamassassin už nedostává tolik vzorků, takže nemusí být na to přípraven (až se spammeři aklimatizují na graylisting).

Greylisting je zajímavý nápad, ale bohužel ve firemním prostředí téměř nepoužitelný. Problémem je právě ta prodleva mezi prvním (greylistovaným) a druhým (akceptovaným) pokusem o doručení.

Stačí když si takhle dopisujete s novým zákazníkem, a máte o zábavu postaráno -- 4 hodinová pauza při čekání na mail není nic moc. A pokud vám chodí různá potvrzení z nových adres (třeba při objednávání zboží, atd.), taky není v praxi použitelné čekat do druhého dne než dostanete mailem třeba registrační kód. A udržovat whitelisty je pěkná otrava.

Greylisting jsem kdysi zkoušel, a právě z těchto důvodů ho zase zrušil. Nehledě na to, že doba pokročila, a spameři pravděpodobně postupem času začnou pro odesílání používat programy které si s greylistingem poradí. Proto mi jako výrazně lepší řešení připadne používat skutečnou kontrolu spamu, například SpamAssassin. A k tomu samozřejmě vhodná pravidla v sendmailu -- nepovolit doručování z domén které mají divné DNS záznamy.

Mě se to bohužel stávalo. Je samozřejmě možné (a pravděpodobné), že webová aplikace, ze které ten mail odcházel, používala nějaký divný mailserver.

Jenže na rozdíl od domácího uživatele, který v radosti nad tím že mu nechodí spamy, ani nezaregistruje že mu třeba nepřišel jeden regulérní mail, to firmách obvykle funguje jinak. Dá se tam spíš akceptovat skutečnost že do schránky přijde 20 spamů, než to že jeden mail nebude doručen. Což u graylistingu hrozí.

Z pohledu admina je pak sice hezké že nechodí spamy, ale z pohledu obchodníků a šéfů je velice nepěkné že občas nedorazí i normální mail (a nesejde na tom, že má zákazník debilní mailserver, protože náš zákazník = náš pán) :)

ono 5 firem je relativni cislo :), kolika to odpovida mailboxum?
taky jsme greylisting zkouseli, taky jsme ho museli zrusit... Ono muzete zastupci zakaznika neco povidat o nastaveni jeho mailserveru, kdyz je to sam jenom radovy zamestnanec relativne velkeho podniku a nema ani tuseni, kdo ze to ma jejich mail server na starost... Nemluve o tom, ze lidi dokaze vytocit i 30 minutove cekani na mail. Typicky priklad (pronaseno do telefonu): "Prave to posilam, uz vam to doslo?"
(proto jsem se ptal na pocet mailboxu - je rozdil jestli se ozve jednou za cas jeden uzivatel kteremu "nedorazil" e-mail, nebo zda si ruzni lide stezuji co 5 minut)

Zdravím,

doporučuji, aby jste neměnil místo. Já bych Vás za takový přístup na hodinu vyhodil. IT má sloužit... Mějte se hezky ;-)

Nepoužívám greylisting, ale tarpitting.

Zpožděná (o 20s) odpověď na HELO/EHLO také odradí 60-80% spamovacích robotů.
Na legitimní e-mail nemá tato funkce žádný vliv.

A jakym zpusobem se to da pro Postfix nastavit?

Dekuji

Ano, také jej používám na serveru pro cca 7000 uživatelů a jsem s ním spokojen.

Jen doplním, že je velmi snadné si v konfiguraci nastavit whitelist na IP adresy, ze kterých se nemá greylisting aplikovat, a také cílové adresy uživatelů, kteým se nemá pošta zdržovat. Poštu od autentizovaných odesílatelů (smtp-auth) také lze pouštět bez zdržení.

Milter-greylist také také umí (já to však nezkoušel) synchronizovat greylistingovou databázi s "bratrským" serverem, takže by mělo být možné používat i sekundární MX.

Zrovna včera jsem ho nasazoval na stroj, který se stal sekundárním mailserverem (na primár zatím nemám odvahu).

Chová se na můj vkus trochu divně :

- většinu spojení sendmail rovnou odmítne, protože je najde na dnsbl.sorbs.net
- u některých spojení vypíše :
reject=451 4.7.1 Greylisting in action, please come back later

To by mělo být v pořádku, ale kam si ukládá ty svoje záznamy ?

V adresáři /var/lib/milter-greylist/db je sice soubor greylist.db, ale má včerejší datum (13:40) a je v něm jediný záznam (a navíc ten soubor není otevřený žádným procesem).
Přitom jsem teď na chvíli odstavil primární server, takže přes něj jde veškerá komunikace - za poslední hodinu odmítnul s výše uvedenou hlášou 2902 mailů.

Ale kde teda má sakra ty svoje záznamy ?!?

Autor zapomel na nejvetsi nevyhodu: Pokud stroj odpovi 450, tak se dost casto (ted nevim, jestli vzdy) posle nazpet informace o tom, ze mail byl pozdrzen. Bud je uzivatel (BFU) zmaten, protoze nevi ktera bije, nebo si naopak rekne "v ty firme maji neschopnyho admina, maji rozbity postovni server". A ani jedno z toho nedela firme dobrou vizitku.

I ja jsem uz jednou/dvakrat chtel psat kamaradovi, ze maji asi nejaky problem na mailserveru, kdyz jsem si uvedomil, ze to je nejspis greylisting :-)

Jeste k popisu algoritmu v clanku: Chybi tam poznamka, ze si server zaznamena jeste cas udalosti a pri opakovanem doruceni toto povoli pouze pokud uplynul nejaky cas od uvodniho pokusu.

Spammeri pak mohou toto obejit jednoduse - budou si pamatovat, kam se jim nepovedlo dorucit a treba za pul hodiny udelaji novy pokus.

Teoreticky se generovat nesmi, ale (jak jsem psal), uz nekolikrat se mi stalo, ze se vygeneroval.

To poznam. Obcas to robi gmail. Odpovie 450, ale zaroven sa objavi mail v "Sent" vo web-interface. Z toho som bol jelen ci to teda poslal alebo neposlal, nakoniec vylucovacou metodou som zistil, ze asi neposlal ;-)

Nadpis jako bych už někde slyšel :-D

Jestli jsem to spravne pochopil, tak cela vec je zalozena na tom, ze spameri pouzivaji mailservery nevyhovujici RFC. To je podle me nedostatecnej predpoklad, kterej prestane platit, jakmile se graylisting trochu vic rozsiri. A budem zase tam kde sme byli.

Možná - ale pokud bude spammer používat korektní server, bude muset mít patřičně dimenzovanou frontu. A to vzhledem k charakteru spamového provozu nebude asi úplně jednoduché, zvlášť na nějakém hacknutém PC.

zkousel jsem taky spoustu ruznych veci. delam ve vetsi firme kde cca pred pul rokem uz spamy zacly delat vic nez jen problemy. jelikoz jsme dcera jedne zahranicni spolecnosti tak se u nas (bohuzel) jelo porad na komercnich resenich (cti drahych).
cca pred tydnem jsem vyzkousel assp (http://assp.sf.net). Ktera obsahuje greylist, bayesansky filtry a hromadu dalsich inteligentnich funkci pro boj proti spamu.
Kdyz jsem videl co to vsecko umi, tak jsem si pres to zkusmo posilal nektere mene frekventovane domeny ktere nase firma pouziva. tri dny jsem ucil bayes filtry a ted uz to bezi na vsechny domeny (nebylo to jednoduche - komunikace ve firme - cesky, anglicky, nemecky, holandsky, obcas neco francouzsky). Greylist mam tedy vypnuty - presne kvuli tomu co tu psal nekdo nademnou - lidi nesnesou zpozdeni nejakeho mailu :(
Sefik je tak nadseny ze chce dokonce poslat penize tomu vyvojovemu tymu (1000$ - zkusim ho jeste trosku pumnout).
Statistiky po 8 dnech pouzivani:
messages processed: 367720
messages blocked: 345976 (95.6%)
messages passed: 21744

"lidi nesnesou zpozdeni nejakeho mailu"

Coz je jejich problem. Obcas taky musim nekterym ignorantum vysvetlovat, ze mail neni z principu chat, a to ze prijde hodinu po odeslani je naprosto bezny. Obzvlast kdyz tentyz magor posle mailem 20MB a pak se strasne divi, ze poslal jeste dalsi email s jednou radkou a ze uz je to pul hodinu a stale nebyl dorucen.

Zkratka pokud chce nekdo komunikovat online, ma na to pouzivat prislusny IM nastroj. Baliky se mi taky domu neteleportujou.

uved tu prosim konfiguraci tveho assp

priradit prislusne site do mynetworks a pred 'check_policy_service unix:/var/postgrey/postgrey.socket' dat 'permit_mynetworks'. nevyzkouseno, ale fungovat by to melo.

Hádám, že na notebooku používáte lokální postfix jen k odeslání, příjem skoro jistě máte přes POP3 nebo IMAP.
Pak se Vás greylisting netýká, ten by když tak běžel na smtp serveru, který přijímá Vaši poštu.

BTW, občas vám asi uvízne odchozí dopis ve frontě a může tam být, dokud se s notebookem zase nepřipojíte. Mně by to vadilo, pořád to hlídat.

Pro cestování s notebookem je výhodné mít někde smtp server, ke kterému se můžete autentizovat (smtp auth, potřebujete username a heslo) a který pak autentizovanému uživateli povolí relay odkudkoli kamkoli (a bez greylistingu).
Také někde povolují relay na krátkou dobu z IP adresy, ze které byla provedena úspěšná autentizace na POP3 nebo IMAP serveru.

Je-li někde blokován přístup do vnější sítě na port 25, zkuste odesílat přes SSL (port 465), případně je pro autentizovaná spojení určen i port 587. Ale to by samozřejmě na takových portech musel ten smtp server poslouchat, což není běžné, je starost s platností certifikátů, s autentizací uživatelů, atd. Ovšem když už to jednou běží, nemohu si to vynachválit.

Paradoxně může greylisting nasazený na příjmu zdržet i odeslání některých dopisů. Já si to nevymyslel, to jsem vypozoroval a vyčetl z logů.

Některé servery se totiž brání příjmu dopisů z neexistujících adres odesílatele tím, že si ještě v průběhu příchozí transakce otevřou další pomocné odchozí smtp spojení k odesílateli a pomocí mail from a rcpt to si ověřují, zda ta adresa, ze které dopis jako jde, existuje. Když je odpověď kladná, tak to pomocné spojení zavře a do té původní příchozí smtp transakce pošle OK. Když odpověď kladná není, pošle přijímající server do původní příchozí transakce chybu 450 a dopis uvízne na odesílajícím serveru na nějakou dobu ve frontě.

A přesně tohle (tj. zdržení odesílaného dopisu) nastane u prvého dopisu, je-li na odesílacím serveru greylisting. Pokud se posílá na nějaký cluster, může být při příštím pokusu o doručení ve hře jiná IP adresa a je tu další zdržení.

Nechci rozebírat, k čemu je ta kontrola odesílatelovy adresy, jen chci upozornit na další možný problém s greylistingem.

Naštěstí serverů, které si takto ověřují odesílatele, není mnoho.

Jejich IP adresy jsem vyloučil z greylistingu, ale vím, že to není moc dobré řešení...

Jedna zahada vyriesena. Thx :-)

Podle zkusenonosti s porovzem mailserveru (Postfix+Gld) jsem zjistil, ze je zbytecne pouzivat hodinove prodlevy, protoze naprosta vetsina spambotu a podobnych spamostroju to vzda hned napoprve. Jedine spamy co projdou jsou ty, co jdou pres sekundarni STMP server posktovatele pripojeni (ten trik s opakovanim MX zaznamu od Peppy musim vyzkouset, vypada velmi vychytrale).

Ja mam nastaveny interval na 60 sekund a naprosto to staci. Maily to zdrzuje minimalne, protoze celou domenu .cz mam ve whitelistu (ceskych spamu je naproste minimum), spolu s nekolika domenamy druheho radu velkych provideru co nejsou .cz (jako czechia.com, foprsi.com a pod.). Gld uklada zaznamy v MySQL databazi a tak je jednoduche zkontrolovat, odkud co chodi, navic je jednoduche cistit stare zaznamy (dela to primo Gld pres cron), takze databaze postupne neboptna.

Ale podle logu mailserver mnohem vice mailu vyradi pouha kontrola SMTP "serveru" (pres smtpd_helo_restrictions). Vetsina z nich nema v poradku reverzni zaznam, nebo ma spatne jmeno (fully-qualified hostname). Vyhoda je, ze je to jeste pred zaslani jakychkoliv dat a ze se ani nemusi prochazet blacklisty.

Jako druha obranna jsou blacklisty, kde jsou jak spamujici servery (obvlast ty, co klidne poslou trista stejnych mailu za hodinu), tak neplatna ci zpotvorena jmena adresatu ziskana roboty ze stranek. Greylisting pomoci Gld je az treti obranna linie, ve ctvrte je jeste analyza hlavickek a oskenovani pomoci ClamAV antiviru. Tohle vsechno zachyti tak 98% spamu, takze misto nekolika stovek denne prijde tak pet-deset spamu (vetsinou v dusledku poslani pres sekundarni mailserver).

Takze dokud nebudou mit vsichni spammeri mailserver s vlastnim reverznim zaznamem, platnym nazvem a neodflaknutou podporou SMTP protokolu podle RFC 2821, spam pro mne nebude problem.

tak ted uz chapu, proc vsechny spamy chodi vzdy dvakrat trikrat i ctyrikrat za sebou. greylisting. je to tedy naprosta zhovadilost ten greylisting.

> tak ted uz chapu, proc vsechny spamy chodi vzdy dvakrat trikrat i ctyrikrat za sebou. greylisting. je to tedy naprosta zhovadilost ten greylisting.

Neřekl bych. Statistika z našeho serveru za včerejšek říká, že greylistingem bylo pozdrženo 13359 mailu, 1067 bylo doručeno se zpožděním způsobeným greylistingem, 1216 doručeno bez zdržení, protože předchozí mail stejným směrem už pred nedávnem cestu otevřel. Vychází mi z toho, že cca 12000 mailů bylo odfiltrovano greylistingem, tedy vůbec nedorazilo na server. Úplně přesně to říci nelze, protože to jsou jen jednoduché počty odmítnutých a přijatých, ale vůbec není jasné, zda patří k sobě např na hranici mezi dny.

Účinné to tedy bezesporu je. Když jsem s greylistingem před dvěma lety začínal, také jsem si myslel, že do půl roku to bude neúčinné. Škoda, že z té doby nemám statistiku (nebyl jsem tehdy tak pilný), takže nemám přesné srovnání. Účinnost od té doby sice subjektivně poklesla, ale jak je z těch čísel vidět, pořád to stojí za to.

K vašim opakovaným spamům: zkoumal jste jejich hlavičky, zda opravdu pocházejí ze stejného zdroje? Já bych spíše řekl, že to jde z různých zdrojů (většinou "zavirovaných" pc), které použily stejné nebo překrývající se rozesílací seznamy.

Ahoj,
zajimala by me nejaka analyza, proc prislo tech zbylych 6 mailu. Nabizi se jednoducha odpoved, ze spammer mail poslal znovu. Je to tak?

Ano, je to zvrhle, ale nepozna niekto nieco free pre Win? Kunsaft ma Exchange a je lakomy na nejaky plugin do toho uzasneho systemu...

dakujem za tipy ...

viz tip nahore - http://assp.sf.net - je to perlovy skript, takze se to da rozbehat i na woknousech (nezkouseno - pouze precteno pri prohlizeni stranek projektu)
ale primo free plugin do exchange imho zatim neexistuje

GreyList je asi magic, ale more magic jsou admini české sparkasse, kdy můj mail z gmail.com greylisting vrátil a ani po třech dnech opětoveného posílání (serverem) jej nepřijal. Chtěl jsem jim chybu oznámit, ale skončil jsem zase na greylistu. Paráda. Když zákazník (dnes již bývalý) nedostane na svou otázku odpověď, a tak je nucen vyhledat služby jinde. Takže pokud chci ochranu proti spamu, nesmím mít za admina diletanta.

Zrovna gmail je taky trocha patologicky pripad, pretoze je to obrovsky cluster a casto sa moze stat, ze kazdy zo zopar pokusov odosle z ineho uzla clusteru (stalo sa mi). Viz: http://www.root.cz/clanky/greylisting-aneb-kladivo-na-spam/nazory/99873/

Inak je pravda, ze gmail je jedna z mala vynimiek. Ak spravne rozumiem, do gmailu je este stale treba pozvanka, takze spammeri musia harvestovat pozvanky. A tipnem si (hypoteza), ze gmail postupne rusi spammerom konta. Spammeri si sice vedia zohnat dalsie pozvanky, ale treba na to uz ludsku pracu. Odhadujem, ze pridelovanie pozvanok je "hodnotene", tj. clovek, ktory poskytol "vela" schranok spammerom, dostane malo alebo ziadne pozvanky. Hodnotenie mailov robia samotni useri => najvyssia spolahlivost.

IMHO mam radsej greylisting nez Bayesovske filtre, pretoze ked sa mail neodosle, tak o tom viem, pri Bayesovi moze nastat "false positive" (oznacenie legitimneho mailu za spam) a nedozviem sa to. Obe metody (Bayes aj GL) maju svoje pre a proti.

pouzivam greylisting nad qmailom, GL data su ulozene v sql. Na server mi pred greylistingom chodilo cca 3000 spamov denne, po nasadeni GL ich pride maximalne 5 a o tie sa postara SA. O com ale chcem pisat je vyvratit mylne myslienky a dohady o GL, ktore tu boli popisane:

1. Vacsina mailserver fariem pouziva ipcky z jedneho /24 subnetu. Nebavime sa o worldwide freemailoch, ktore manualne nahodit do databazy je otazka 10 minut. Cize uplne staci, ked
sa pri prijimani mailu zaznamena adresa vo forme x.y.z.% (a cela adresa pre pripad potreby) a ta sa potom pouziva pri matchovani dalsich mailov.

2. podla rfc2821: "The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes". Cize, kto nedodrzuje RFC, ma problem on nie ja. Preto ak sa z rovnakeho subnetu pokusi niekto dorucit mail skor ako po 30 minutach, jedna sa o spammera. Ak je to regularny MTA, tak raz ten mail doruci po pozadovanej odmlke. Konkretne u mna sa o to stara zaznam v stlpci block_expires a pri zapisovani do databazy je NOW()+30minut.

GL funguje, funguje skvele a nezaujima ma co bude ked sa spameri naucia posielat maily RFC compilant... to budem riesit az to nastane a nie potom si vycitat, ze kym sa este dalo efektivne bojovat proti spamu, tak som sa radsej babral a stracal cas s inymi metodami.

"In general, the retry interval SHOULD be at least 30 minutes" [...] Preto ak sa z rovnakeho subnetu pokusi niekto dorucit mail skor ako po 30 minutach, jedna sa o spammera.

No pozor, SHOULD != MUST. Odosielatelia necakajuci 30 minut vyhovuju RFC. Dokonca by som povedal, ze najlepsie riesenie pre server je vybrat nahodne uniformne cakanie z intervalu (0, 30] minut kym akceptuje mail. V priemernom pripade bude cakanie 15 minut (v najhorsom 30). Alebo vybrat take rozdelenie, ze maximalna hranica bude neobmedzena (nekonecno), ale pravdepodobnost, ze si server take cakanie vyberie, bude klesat inverzne exponencialne (napr. normalne rozdelenie s maximom v 15 minut a rozumne "natiahnute" do stran).

Uz sa mi parkrat stalo, ze som sa potreboval poslat rychlo mail (odchod do zony bez netu ;-)) a bol som zagreylistovany. Pockat trebars 10 minut sa este da, ale tych 30 minut moze byt problem.

netvrdim ze greylisting nema ziadne nevyhody... a zdrzanie legalnych mailov je jediny, ktory cloveka moze naozaj nastvat. Mozem povedat, ze prve 3 mesiace som vzdy prepadol panike, ze mi nefunguje mta, ked som si odniekial poslal mail, resp. niekto poslal mne a nedorazil mi za par okamihov. Dnes som s tym uz zmiereny :)

SHOULD = MAL BY... cize ak posle skor, je to na jeho riziko, ze si tym uskodi. Ak mam pravdu povedat, tak ani samotny qmail od DJB nedodrziava 30 minut od prveho dorucenia (1. okamzite, druhe po cca 6 min., tretie po cca 26 min. a az stvrte je po hodine).

Cim vyssia doba (onych 30 minut), tym je system efektivnejsi pri boji proti spamu... pretoze az po tej dobe sa sprava od daneho odosielatela z nejakej ip pre dotycneho prijimatela povazuje za nespam. A ked niekto zaflooduje milion mailov, je otazkou par desiatok minut, kym sa ip adresa objavi na nejakom znamom blackliste. Dovtedy treba drzat hradzu pred pripadnym pokusom o opakovany flood :)

Na koniec este - pravdepodobnost, ze ti niekto prvy mail posle s urgenciou je dost nizka... cize ak si uz s niekym komunikoval, spravy od neho ti dorazia okamzite.

Na koniec este - pravdepodobnost, ze ti niekto prvy mail posle s urgenciou je dost nizka... cize ak si uz s niekym komunikoval, spravy od neho ti dorazia okamzite.

Jj, v spominanom pripade to vyzeralo, ze greylisting bol cerstvo zavedeny na MTA, takze este nebol "natrenovany" na "znamych ludi".

hmmm, a existuje niekde zoznam hostov z ktorych t treba radsej povolit? (napr. gmail farma atd)?

neviem ci niekde je zoznam, ale staci si dat: "SELECT relay_ip FROM relaytofrom where mail_from LIKE "%gmail.com" GROUP BY relay_ip" na databazu po par dnoch a pozriet reverz. Konkretne gmail ma format "countrycode"-out-####.google.com
A potom to tam nahadzat s hodnotou MANUAL v stlpci origin_type (aby sa to pri cisteni nezmazalo)

no ja mam spamd z OpenBSD ... ale v zasade chapem, skor som myslel/dufal ze take nieco existuje.

host -t MX gmail.com
gmail.com mail is handled by 50 gsmtp163.google.com.
gmail.com mail is handled by 50 gsmtp183.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.

Mam pocit, ze gmail schvalne pravidelne meni DNS MX zaznamy (a aj odosielacie uzly), natvrdo zadratovat povolenie gmailu bude tazke. Zda sa mi, ze je to ochrana proti automatickym skriptom, ktore maju natvrdo zadratovane IP/hostname.

Napadlo ma, ze skript tiez moze pustit 'host -t MX', ale asi to nerobia. Zaujimavym riesenim by mozno bolo, keby DNS "obcas klamalo" o MX zaznamoch.

Ahoj, poradí mi někdo co dělat,když moji mailovou adresu, resp. doménu,někdo zneužil a začal posílat spam maily podepsané mojí adresou. Dneska nejsem schopen odeslat svůj mail, protože je to všude bráno jako spam :(