Greylisting - stop nevyžiadanej pošte

30.4.2011 14:48 | Přečteno: 2301× | Opensource | poslední úprava: 30.4.2011 14:53

V poslednej dobe sa neúmerne navýšilo množstvo nevyžiadanej pošty v mojich schránkach. Tieto návaly SPAMu som dokázal ignorovať celý týždeň. Potom mi došli nervy a rozhodol som sa situáciu riešiť. Zvolil som greylisting ako formu boja proti nevyžiadanej pošte.

Greylisting

Je zaujímavá a efektívna metóda pre boj s nevyžiadanou poštou. Server na ktorom je nasadená táto metóda neprijíma prichádzajúcu poštu ihneď. Namiesto prijatia správy pošle odpoveď že správu nie je možné momentálne doručiť. Po akú dobu bude server prichádzajúcej pošty odmietať správu doručiť je možné nastaviť. Slušný server odosielatela  chvíľku počká a pokúsi sa správu doručiť znova. Až vtedy bude uznaný za dôveryhodný a správa bude doručená. K dispozícii je aj whitelist. Servery ktoré sú v ňom uvedené nebudú overovaním zdržované. Je možné nastaviť aby sa greylistingom overené servery automaticky pridávali do whitelistu po určitom počte úspešných overení.

Z princípu je teda jasné že nevýhodou greylistingu bude zdržovanie správ. Ja osobne mám nastavenú dobu "odmietania" na 60 sekúnd. To znamená že počas prvých 60 sekúnd správa určite nedorazí. Po uplynutí tejto doby bude ďalší pokus o doručenie uznaný a správa doručená. No neznamená to že správy budú chodiť v tomto prípade s minútovým oneskorením. Kedy sa rozhodne odosielajúci server zopakovať pokus o doručenie je záležitosťou jeho nastavenia (na ktoré má dosah iba jeho správca).

Konfigurácia

Ako MTA používam postfix s virtuálnymi schránkami. A čo sa greylistingu týka, po niekoľkých omyloch a pokusoch som sa rozhodol zakotviť u postgrey. Inštalácia a konfigurácia v Debian GNU/Linux OS je veľmi jednoduchá. Stačí nainštalovať balík postgrey:

# aptitude install postgrey

následne upraviť nasledovné konfiguračné súbory /etc/default/postgrey a /etc/postfix/main.cf

/etc/default/postgrey

# postgrey startup options, created for Debian

# you may want to set
#   --delay=N   how long to greylist, seconds (default: 300)
#   --max-age=N delete old entries after N days (default: 35)
# see also the postgrey(8) manpage

POSTGREY_OPTS="--inet=10023 --lookup-by-host --delay=60 --max-age=90 --auto-whitelist-clients=3 --retry-window=4"

# the --greylist-text commandline argument can not be easily passed through
# POSTGREY_OPTS when it contains spaces.  So, insert your text here:
POSTGREY_TEXT="Greylisted."

Podľa konfigurácie vyššie bude postgrey bežať na porte 10023 a do jeho databázy sa budú ukladať záznamy s celými IP adresami po dobu 90 dní. Po troch úspešných overeniach bude odosielateľ pridaný na whitelist. Každá nová správa bude odmietaná po dobu 60 sekúnd a ako príčina bude uvedný text "Greylisted."


úryvok z /etc/postfix/main.cf

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unauth_destination,
        reject_unauth_pipelining,
        reject_invalid_hostname,
        check_client_access hash:/etc/postfix/checks/client,
        check_sender_access hash:/etc/postfix/checks/sender,
        check_recipient_access hash:/etc/postfix/checks/recipient,
        check_helo_access hash:/etc/postfix/checks/helo,
        check_policy_service inet:127.0.0.1:10023,
        permit

Overenie postgreyom je uvedené ako predposledné. Správne poradie položiek u smtpd_recipient_restrictions je dôležité.
Treba si dávať pozor aj na stabilitu služby (programu) ktorá je pre greylisting (alebo iné overovanie) použítá. Pokiaľ z nejakej príčiny zlyhá (seg. fault, bug, atď..), správa bude zamietnutá s kódom 451 a textom "Server configuration problem".
Následne už stačí iba reštartovať postfix a postgrey aby sa prejavili nové nastavenia. Ako postfix a postgrey pracujú si môžeme pozrieť pomocou tailf /var/log/mail.info (hlavne si je dobré overiť správnosť fungovania).

Záver

Od nasadenia postgrey (cca dnes o 01:00) sa mi do schránky nepredral jediný SPAM. Za zmienku stojí aj to že postgrey prichádza s už predvyplneným whitelistom kde sa nachádzajú užívateľmi overené adresy (napr. gmail, ebay, yahoo, atď..).

---

Blogpost pochádza z cyberasylum.eu


       

Komentáře

[trekker.dk]

prichádza s už predvyplneným whitelistom kde sa nachádzajú užívateľmi overené adresy (napr. gmail, ebay, yahoo, atď..)

Což je vcelku nutnost, protože gmail při odesílání mění IP adresy odesílajího serveru.

Ale jinak bych řekl, že ještě lepší ochrana proti spamu jsou RBL - pokud člověk použije nějaké rozumné blacklisty (tzn. např. NE sorbs), odfiltruje se jimi dost bordelu, aniž by to působilo problémy legitimním odesílatelům.

[asfethan]

Ako najprv som uvazoval ze nasadim RBL, GL a SPF... Vsetko spolu. Postupne som od toho upustil po boji s SPF (hlavne s demonmi ktore aj v stable obsahovali bugy, alebo napr. padli po znovunacitani konfiguracie). Nasledne som sa zameral hlavne na najdenie kvalitneho GL demona. A ked som ho nasiel a nakonfiguroval podla svojich predstav, na RBL som akosi zabudol :)

[trekker.dk]

SPF má malinkou nevýhodu - když se použije, přestane fungovat přesměrování/přeposílání e-mailů na jinou adresu.

[pavlix]

DKIM tuhle nevýhodu nemá.

[pavlix]

Mně osobně přijde, že RBL a Greylist pokrývají odlišné skupiny spamu, takže se mi líbí obojí.

[trekker.dk]

Greylist pokryje navíc to, co se ještě nedostalo do RBL. Nicméně čistě prakticky - když vezmu maily odmítnuté pomocí RBL i greylistingu dohromady, tak za situace, kdy chodí značně nadprůměrné množství spamu, má RBL v tom součtu podíl cca 95%. Když chodí spamu málo, tak je to půl na půl.

(Básník chce říci, že když někdo přemýšlí, co se spamem, tak má nejdřív kouknout po RBL a pak teprve po greylistingu.)

[pavlix]

S tím se nedá než souhlasit.

[pasmen]

Také používám greylisting (a také postgrey). Od roku 2006, kdy jsem zapnul na mailové bráně statistiky, se účinnost greylistingu ovšem neustále snižuje.

[Max]

Mno, greylisting má své pro i proti. Nám třeba v jobu přijde cca 40 000 emailů, z toho se jich asi 38000 vyloučí kvůli špatnému adresátovi. Zbývá nějakých 12000, z toho spamfiltery a blacklisty vyloučí dalších cca 5000 emailů.
O greylistingu jsme jeden čas přemýšleli, ale právě je u nás důležité včasné doručení emailů + doručení v takovém pořadí, v jakém byly odeslány (automatické zpracování objednávek a tak).
Něco se dá vyřešit whitelistem, něco ne :-/.
Otázkou také je, jakou účinnost má greylisting s malým časovým intervalem.
My jsme si řekli, že je pro nás greylisting věc, která může docela dost snížit schopnost správného a včasného doručení emailu, což by se nám nevyplatilo.
Zdar Max

[Josef Kufner]

U greylistingu na časovém intervalu nijak zvlášť nezáleží. Pointa je v provedení druhého pokusu. Jedna minuta bohatě stačí – prakticky ověřeno.

[SPM]

Ovšem vy nejste ten admin, který určuje kdy se druhý pokus provede...

[Josef Kufner]

Tak to samozřejmě. Ovšem je zbytečné čekat na ten třetí, když by druhý přišel o trošku dřív než bylo nastaveno.

[trekker.dk]

Když tak zavzpomínám...

Kerio mailserver. Na tom udělátoru je snad výchozí upozornění na situaci, kdy mail nejde doručit okamžitě. Odesílatel přes to odešle zprávu, cílový server s greylistingem vrátí dočasnou chybu, Kerio odesílateli pošle mail, že to nešlo doručit hned a že to ještě bude zkoušet. (A odesílatel samozřejmě nečte, ale rovnou začne řešit, že nefungují maily.)

Nebo tenkrát, kdy něčí mailserver opakované pokusy prováděl nejdřív po minutě a pak každý den ve čtvrt na šest ráno. To se samozřejmě netrefilo do povoleného okna, takže mail došel až po týdnu, kdy se odesílací server kromě čtvrt na šest ráno pokusil ještě někdy v deset dopoledne (hádám, že poslední pokus), což už konečně vyšlo.

Někdy nevycházím z údivu nad tím, co dokáží lidi na svém mailserveru nastavit.

[pavlix]

Někde se to nehodí, ale obecně se s prodlevou dá žít, protože pokud s někým komunikuju, tak už se greylist neuplatňuje, a konkrétní výjimky se dají navíc whitelistovat.

[Luk]

doručení v takovém pořadí, v jakém byly odeslány

Tohle není zaručeno nikdy. Odesílající server může mít např. chvilkový výpadek konektivity, jedna zpráva se neodešle, další už ano. Nebo mohou jít různé zprávy různými cestami. Možností je spousta.

[cynic_asshole]

A co policyd? Ten používám já a spokojenost.

[asfethan]

Prave policyd vyzeralo velmi slubne. GL, SPF, vsetko v jednom. Lenze verzia v stable obsahuje bug. Dalej som narazil na take chovanie ze po znovu nacitani konfiguragu (/etc/init.d/postfix-policyd reload) padol. A toto nie je zrovna ziaduce chovanie u mna. Povazujem to za nestabilitu a ak by mi nahodou prestali chodit maily ked sa zruti... Velmi neprijemna predstava.

[cynic_asshole]

Aha, to jsem netušil. Provozuju ho na FreeBSD jako tentobalíček a s tebou popisovanými problémy jsem se nesetkal.

[SPM]

Mno, osobně shledávám greylisting stejně užitečný, jako automat na kondomy ve Vatikánu... ještě lepších výsledků člověk dosáhne, když si zadropuje port 25 na mailserveru (tam neprojde spam žádný ) :))) Mno, teď vážně... Nemám jej rád - opožďuje maily, přičemž to, jak moc je opozdí je v rukou těch druhých adminů a ne mých. Já sám dost nemám rád, když se ten mail někde fláká a další otázka je, jak moc je to užitečné s výhledem do budoucna - až takhle greylisting nasadí skoro všichni, tak se na to spameři připraví a budou ty maily prostě posílat 2x...

[Heron]

zadropuje port 25 na mailserveru (tam neprojde spam žádný )

Jsem skutečně rád, že v této diskusi nejsem první, kdo tohle napsal . Minule to mělo poněkud neblahé konsekvence.

Já sám dost nemám rád, když se ten mail někde fláká

Hmm, něco podobného zde uvedlo více lidí, což je poněkud zvláštní vzhledem k tomu, že u emailu není vůbec zaručeno jeho doručení (dnes je spíše zázrak, že nějaký email přes tyhle konstrukce projde), natož pak jeho doručení v nějaké garantované době. Osobně email považuji za komunikaci, kde je na reakci několik dnů čas a nějaká ta minuta nehraje roli.

budou ty maily prostě posílat 2x

A nebo prostě přes normální mail servery, což už se částečně děje.

[pavlix]

Jsem skutečně rád, že v této diskusi nejsem první, kdo tohle napsal . Minule to mělo poněkud neblahé konsekvence.

Nevím proč jsi rád, když je to očividný nesmysl.

A nebo prostě přes normální mail servery, což už se částečně děje.

Tam do jisté míry pomáhají blacklisty.

[trekker.dk]

Tam do jisté míry pomáhají blacklisty.

Ajaj. Kdepak mám ty asbestové spodky...

[Heron]

Trekker, který si na to pamatuje, už si jde pro spodky.

Nevím proč jsi rád, když je to očividný nesmysl.

Někteří admini dělají všechno proto, aby jim žádný email nepřišel. Dělají to ale strašně složitě, zablokovat port 25 (nebo rovnou vypnout postfix) je jednodušší.

[pavlix]

Někteří admini dělají všechno proto, aby jim žádný email nepřišel. Dělají to ale strašně složitě, zablokovat port 25 (nebo rovnou vypnout postfix) je jednodušší.

Často píšeš věci, které mají hlavu a patu.

Tohle není ten případ... ale jo, viděl jsem to u spousty chytrých lidí, že když se jim nějaká technika nelíbí, že začnou vymýšlet úplně na hlavu postavené argumenty proti tomu. Mimochodem neříká se tomuhle straw man?

Greylisting je metoda, která má za vedlejší účinek zdržení některých mailů. Výjimečně vede na delší zdržení. Téměř nikdy nevede na nedoručění mailu z jiného mailserveru. A ta metoda má oproti žádné metodě obrovskou účinnost, v kombinaci s RBL ještě větší, protože vykrývá, co RBL nechytily.

Jistě, existují sofistikovanější metody, ale o tom řeč není.

Takže můžu s klidným svědomím napsat, že tvé srovnání nasazení greylistu a vypnutí mailserveru je blbost a tvůj velký úskok od racionálního myšlení.

[Heron]

Tohle není ten případ... ale jo, viděl jsem to u spousty chytrých lidí, že když se jim nějaká technika nelíbí, že začnou vymýšlet úplně na hlavu postavené argumenty proti tomu. Mimochodem neříká se tomuhle straw man?

Jsem rád, že mám svého soukromého psychologa. Ne, teď vážně. Já jsem o této technice (abychom byli konkrétní, o greylistingu) zatím vůbec nevyjádřil. Nelze tedy tvrdit, že se mi nelíbí. Naopak, GL se mi líbí daleko více, než blacklisty, na které se dostal snad každý mailserver (kdo nebyl na blacklistu, ten jako by ani nežil ).

GL je de facto zkouška nastavení odesílajícího mailserveru, podobně jako třeba checky na existenci domény odesílatele. Proti tomuto nic moc nemám.

K těm blacklistům, zažil jsem mnohokrát situaci, kdy se správce emailového serveru (což já nejsem, teď si jistě mnoho lidí oddechlo ) snažil ve stresu odstranit svůj server z BL a to jenom proto, že nějaký cizí server jeho emaily odmítal. Ok, pokud někdo nechce moje emaily (myšleno z mého mailserveru), a to ještě na základě toho, že někdo úplně jiný jej dal na BL, tak ať si trhne.

Takže můžu s klidným svědomím napsat, že tvé srovnání nasazení greylistu a vypnutí mailserveru je blbost a tvůj velký úskok od racionálního myšlení.

To bys s klidným svědomím napsat mohl ve chvíli, kdy bych něco takového vyplodil. Což se nestalo.

[trekker.dk]

Naopak, GL se mi líbí daleko více, než blacklisty, na které se dostal snad každý mailserver

Jako vždy jsi vynechal jeden důležitý fakt: na ten blacklist se server (přesněji IP adresa) dostává z nějakého důvodu - většinou je to za posílání spamu, tzn. naprosto oprávněně.

Ano, jednotlivé blacklisty se liší podle toho, jak rychle tě (za kolik spamu) tě přidají a jak rychle tě odstraní. Takže samozřejmě, když někdo nasadí uceprotect level 3 (zjednodušeně blokuje rozsah, ve kterém se nachází rozsah, ve kterém se nachází spamující IP), může rovnou s klidem ten mailserver vypnout. Na druhou stranu pokud používáš rozumné blacklisty - takové, které adresu automaticky odstraní po pár hodinách, co z ní přestal chodit spam - tak není problém.

[Heron]

Jako vždy jsi vynechal jeden důležitý fakt: na ten blacklist se server (přesněji IP adresa) dostává z nějakého důvodu - většinou je to za posílání spamu, tzn. naprosto oprávněně.

A teď už jen zbývá dodefinovat takovou maličkost, že jo. Co je to spam? (Moje) odpověď: Pro každého je to něco jiného. Někdo bere dané sdělení jako užitečnou informaci a na tuto reaguje. Jinak by nemělo smysl tu informaci rozesílat. Takže se opět vracím k tomu, že se IP dostane na blacklist jen na základě subjektivní posouzení třetí osoby (či spíše třetího systému), která danou informaci bere jako spam, přičemž pro jiné daná informace spamem být nemusí.

Sám si napsal většinou. Takže to mohou býti i jiné důvody, že ano.

[trekker.dk]

Co je to spam? (Moje) odpověď: Pro každého je to něco jiného.

To je v některých případech klidně možné, nicméně na tom, že některé zprávy jsou spam, se shodnou všichni. Nebo téměř všichni, protože někteří mají tendence být alternativní za každou cenu. A kdybys chtěl příklad, tak nemám na mysli různé hotely, ale ch34p m3ds s odkazem na stránku, kde ti IE stáhne do počítače vir.

přičemž pro jiné daná informace spamem být nemusí.

Můžeš psát, jak obecně chceš, ale to nemění fakt, že většina strojově označených spamů (se slušně nastaveným antispamem, což předpokládám, že provozovatelé blacklistů mají) jsou spamy, které nejsou užitečné pro nikoho (z příjemců) Samozřejmě až na pár chci-být-výjimečných.

Sám si napsal většinou. Takže to mohou býti i jiné důvody, že ano.

Takhle narychlo si vzpomínám na blacklist, kde byl seznam serverů (spammerů), co neukončují SMTP relaci příkazem quit. Apod. Myslel jsi, že protože jsou tam omylem?

[Heron]

No, vzhledem k tomu, že už i Filip k tomu míří tak to napíšu rovnou.

To co je pro něj spam si určí sám příjemce pošty. Nikdo jiný to nemůže rozhodnout. Mohou mu k tomu pomoci hinty, například počet bodů, které by tomu dat nějaký ultra super antispam. Příjemce si též může naučit (bayes, fuzzy) vlastní filtry, aby mu to filtrovalo poštu podle jeho vlastního nastavení.

Ale nikdy nemůže takový systém sám ze své zvůle zahodit relevantní email (to je to nejhorší, co se může stát) -- jinými slovy, nesmí automaticky zahodit žádný email, pokud si to uživatel sám nenadefinuje.

Toto já považuji za antispamové řešení, protože je to individuální, stejně jako pojetí spamu. Nikoliv to, co někdo nadiktuje ostatním.

[trekker.dk]

To co je pro něj spam si určí sám příjemce pošty. Nikdo jiný to nemůže rozhodnout.

A u většiny spamů se na tom, že daná zpráva je spam, shodnou všichni až na výjimky uvedené výše.

Ale nikdy nemůže takový systém sám ze své zvůle zahodit relevantní email (to je to nejhorší, co se může stát) -- jinými slovy, nesmí automaticky zahodit žádný email, pokud si to uživatel sám nenadefinuje.

Už je to tu zase. Greylisting (stejně jako blacklisty) neznamená, že mail bude zahozen. Právě naopak, pokud se odesílatel chová podle standardů, mail zahozen nebude.

[Filip Jirsák]

Právě naopak, pokud se odesílatel chová podle standardů, mail zahozen nebude.

To je lež a vy to víte. Odesílatel se může chovat podle standardů, odmítnutý e-mail se může pokoušet opakovaně doručit třeba týden, a vy ho stejně pokaždé odmítnete

[trekker.dk]

To je lež a vy to víte.

Ne není, jenom jsem jednou vynechal "pro normálně se chovajících 99% provozovatelů poštovních serverů", protože jsem myslel, že už je to jasné; samozřejmě to bys nebyl Jirsák, kdyby ses toho okamžitě nechytil, protože slovíčkaření je něco, co ti jde nejlíp.

[Filip Jirsák]

Vynechal jste, že odesílatel musí splňovat vaše pravidla (která nazýváte normálem). Nevím, co vidíte nenormálního na clusteru odesílajících klientů nebo na odesílajícím klientu bez pevné IP adresy.

[pavlix]

nebo na odesílajícím klientu bez pevné IP adresy.

Takové odmítám rovnou (samozřejmě s výjimkou svých autentizovaných) a je mi úplně jedno, co si o tom kdo myslí :). Ono to totiž nikomu kromě Jirsáka nevadí, a ten se holt přizpůsobí, navíc tím, že mi od něj nebudou chodit maily, o nic nepřijdu.

Nevím, co na tom vidíte normálního.

[cynic_asshole]

Odesílající klient bez pevné IP adresy se přeci může autentifikovat oproti SMTP serveru. A odeslíatel musí splnit jaká pravidla? Že po pěti minutách pošle odložený mail znovu? To je přeci v RFC2821. Jaký je rozdíl oproti tomu, že cílový mailserver má plný disk a nebo greylistne (tfuj, jaký to patvar) regulérní e-mail?

[Filip Jirsák]

Odesílající klient bez pevné IP adresy se přeci může autentifikovat oproti SMTP serveru.

A nebo může e-mail poslat rovnou. Protokol SMTP nevyžaduje, že by klient musel mít pevnou IP adresu.

A odeslíatel musí splnit jaká pravidla? Že po pěti minutách pošle odložený mail znovu? To je přeci v RFC2821.

Tedy po sto prvé: odesílatel dodrží všechna pravidla, po nějaké době (třeba 5 minut) pošle e-mail znova, a vy jej stejně zahodíte – protože nedokážete poznat, že jde o stejný e-mail. Kde je tedy chyba?

Jaký je rozdíl oproti tomu, že cílový mailserver má plný disk a nebo greylistne (tfuj, jaký to patvar) regulérní e-mail?

Rozdíl je v tom, že až se místo na disku uvolní, e-mail se přijme (po opakovaném odeslání). Při použití greylistingu se znova odmítne, protože nepoznáte, že jde o ten samý e-mail.

[pavlix]

Rozdíl je v tom, že až se místo na disku uvolní, e-mail se přijme (po opakovaném odeslání). Při použití greylistingu se znova odmítne, protože nepoznáte, že jde o ten samý e-mail.

Ovšem pouze podle vaší imaginární teorie, kdy chceme přijímat e-maily od někoho jiného než autentizovaných klientů a mailserverů.

[Filip Jirsák]

Existenci mailserverů v clusteru popíráte jenom vy. S tím, jak se bude rozšiřovat využití virtualizace a cloudů jich bude čím dál víc, ne jen velcí globální poskytovatelé jako GMail nebo i velcí lokální poskytovatelé jako Seznam.

[trekker.dk]

Při použití greylistingu se znova odmítne, protože nepoznáte, že jde o ten samý e-mail.

Ano, to píšeš podruhý v jednom příspěvku, ale jaksi tu chybí informace o tom, proč nepoznám, že jde o ten samý mail. (Je-li tomu skutečně tak.)

[Filip Jirsák]

Tu informaci jsem napsal už několikrát. Stačí, aby se ten e-mail pokusil znovu odeslat klient s dostatečně jinou IP adresou – jiný počítač z clusteru, ten samý počítač po změně IP adresy, ten samý počítač přes jiného ISP…

[trekker.dk]

Možná jsi to tu psal několikrát, ale ani když to zopakuješ stokrát, nic nezměníš na faktu, že při odeslání z jiné IP to není stejný mail.

[Filip Jirsák]

No to je mi novinka. Ve kterém RFC jste to našel?

[trekker.dk]

Zkus si porovnat mail zaslaný přes dva různé servery a uvidíš, že se bude lišit - třeba co se Received: týče. Podle mě to pak není stejný mail.

[Filip Jirsák]

Hlavičku Received: přidává přijímající server, od klienta ale odchází stále stejný e-mail. Jinak v té hlavičce se bude lišit i e-mail odeslaný přes stejný server, ale v různý čas. Takže pokud to berete takhle, nelze stejný e-mail poslat znovu, tudíž podmínky greylistingu nejde nikdy splnit.

[pavlix]

Takže pokud to berete takhle, nelze stejný e-mail poslat znovu, tudíž podmínky greylistingu nejde nikdy splnit.

Líbí se mi, že vaše myšlenková onanie došla až k tomu, že Greylisting odmítá všechno... a co takhle se vrátit k realitě...

Otevřete si Wikipedii nebo Google, a nejdřív si o Greylistingu přečtěte aspoň nějaké základí informace.

[Filip Jirsák]

To jste ale špatně četl. Ne já, ale Trekker.dk popisuje pravidla, podle kterých by greylisting měl odmítat všechno. Zapletl se do toho tak proto, že odmítá uznat, že opakované doručení jednoho e-mailu z různých IP adres je zcela legitimní, a jeho greylisting takový e-mail může odmítnout – takže odmítne normální e-mail, který byl doručován podle všech pravidel RFC.

[pavlix]

Naštěstí je Greylisting, stejně jako kontrola dopředného i zpětného mapování DNS nebo blacklisty, docela oblíbený. Takže kdokoli nový se chce objevit na trhu a hrát podle čistého SMTP, má tak trochu smůlu.

Idealista by řekl, že je to důvod ke smutku, ale když je RFC takové jaké je a samo o sobě nenabízí prostředky pro boj se spamem (nechci diskutovat o tom, jestli ho nabídnout vůbec může, to je úplně jiná debata), holt přichází kreativita a přirozený vývoj.

Jedinci, co nově vstupují na trh mají možnost se přizpůsobit a nebo nést následky toho, že se nepřizpůsobí.

[Filip Jirsák]

Bohužel ta nejrůznější nikde nezdokumentovaná pravidla nad rámec RFC stále přibývají. Aby uživatelé moc neremcali, že se jim ztrácí e-maily, řeší se to whitelisty velkých provozovatelů. Takže nejspolehlivější způsob, jak poslat e-mail, je zase přes velkého poskytovatele. Takže Google a další na sebe budou nabalovat více a více provozu, a bude čím dál obtížnější provozovat nějaký menší server, který se nedostane na whitelisty. Až v ideálním konečném stavu bude pár velkých poskytovatelů, jako Google nebo Microsoft, a to bude vše. Pak budete mít, co jste chtěli.

[pavlix]

Bohužel ta nejrůznější nikde nezdokumentovaná pravidla nad rámec RFC stále přibývají.

Bohužel ano, taková je realita.

Aby uživatelé moc neremcali, že se jim ztrácí e-maily, řeší se to whitelisty velkých provozovatelů.

Ano, whitelistů, které často propouštějí hromadu spamu. Ale není to zase tak horké.

Pak budete mít, co jste chtěli.

To zní jak nějaká křesťanská agitka... a nebo straw man.

[Heron]

No to je fakt štěstí. Takže výsledkem je, že se používá technologie bez příslušných standardů (nebo alespoň RFC), každý si to nastaví podle sebe, to své řešení označí jako většinové nastavení a ti ostatní jsou projistotu hned nepřízpůsobiví a mají smůlu, protože se chovají dle standardů. Super přístup, obzvláště s přihlédnutím na okolnost, že jsme na abclinuxu. Na portálu o nějaké proprietální uzavřené technologii bych to ještě pochopil.

[pavlix]

No to je fakt štěstí. Takže výsledkem je, že se používá technologie bez příslušných standardů (nebo alespoň RFC), každý si to nastaví podle sebe, to své řešení označí jako většinové nastavení a ti ostatní jsou projistotu hned nepřízpůsobiví a mají smůlu, protože se chovají dle standardů.

To co popisuješ má od reality ještě pořád docela daleko.

a ti ostatní jsou projistotu hned nepřízpůsobiví a mají smůlu, protože se chovají dle standardů. Super přístup

Doufám, že tě ani v nejmenším nenapadlo toto podsunout mě. Asi bych musel zapochobyvat o tvé soudnosti.

Super přístup, obzvláště s přihlédnutím na okolnost, že jsme na abclinuxu. Na portálu o nějaké proprietální uzavřené technologii bych to ještě pochopil.

Ano, jsme na Abclinuxu, kam chodí hodně idealistů včetně těch, kteří mají v hlavě striktně zakódováno, že se nesmí nic udělat než se to dá na papír a dá ke schválení standardizační organizaci.

Ale kromě pouhých idealistů jsou tu i lidi z oboru, kteří se musí občas podívat svýma reálnýma očima na okolní reálný svět a třeba taky dělat svoji práci. Tedy, jsou idealisti, ale žijí v nedokonalém reálném světě a berou v některé jeho vlastnosti v potaz.

[Heron]

Ale kromě pouhých idealistů jsou tu i lidi z oboru, kteří se musí občas podívat svýma reálnýma očima na okolní reálný svět a třeba taky dělat svoji práci. Tedy, jsou idealisti, ale žijí v nedokonalém reálném světě a berou v některé jeho vlastnosti v potaz.

Ano, stím souhlasím. Problém je, že ty s trekkerem máte pouze to své řešení (a Jirsák má můj obdiv za výkon v této diskusi) a všechno ostatní odmítáte (to by ještě nebylo tak hrozné), ale místo technické argumentace (z praxe jsme tu nejspíš všichni) se pouštíš do osobních výpadů. Takže bych prosil, diskutujme technicky.

Ale kromě pouhých idealistů jsou tu i lidi z oboru, kteří se musí občas podívat svýma reálnýma očima na okolní reálný svět a třeba taky dělat svoji práci. Tedy, jsou idealisti, ale žijí v nedokonalém reálném světě a berou v některé jeho vlastnosti v potaz.

No a potom jsou tady ještě lidé z praxe, kteří vidí jednak reálný problém ale také problému způsobené tím jediným správným řešením diktovaným zmíněnou "většinou".

Zajímavé je, že tady ještě nikdo nevytáhl příčinu rozesílání spamu. Kdyby na ty emaily nikdo nereagoval... Ale to jsme zpět u toho, co je to spam.

[trekker.dk]

a všechno ostatní odmítáte

Jsem ochoten přijmout cokoliv, co někdo podloží fakty a čísly, nikoliv tvrzením "to nemůže fungovat"

Zajímavé je, že tady ještě nikdo nevytáhl příčinu rozesílání spamu. Kdyby na ty emaily nikdo nereagoval...

Klidně, jsem zcela pro to zakázat všem BFU používání elektronické pošty.

[trekker.dk]

každý si to nastaví podle sebe, to své řešení označí jako většinové nastavení a ti ostatní jsou projistotu hned nepřízpůsobiví a mají smůlu

Jenže to nastavení JE většinové: podle Googlu se Postfix o opakované doručení pokouší v intervalech od pěti minut do hodiny a kousek. Qmail postupně intervaly prodlužuje, začíná na 6 minut 40s, pak 26:40, 1:00:00, 1:46:40 atd. Sendmail to zkouší jednou za hodinu. Exchange jednou za minutu. Kerio mailserver jednou za půl hodiny (?)

Takže když greylisting umožňuje doručení ještě několik hodin po prvním pokusu, všechny tyhle servery bez potíží zprávu doručí. Problémy mají akorát "jéheleklikátko" hovádka, která něco nastaví jenom proto, že to jde.

a mají smůlu, protože se chovají dle standardů

Je standard napsaný na papíře a je standard definovaný tím, co je standardní, tzn. používají to všichni drtivá většina. Ano, samozřejmě, když někdo opakovaný pokus o doručení provede druhý den, zcela to odpovídá RFC, ale standardní to rozhodně není - viz výše. A hlavně: za celou tuhle diskuzi tady nikdo z odpůrců greylistingu neřekl, proč něco takového dělat. Opravdu bych rád slyšel rozumný důvod, proč by mailserver měl zdržovat zprávu ve frontě několik (desítek) hodin.

Super přístup, obzvláště s přihlédnutím na okolnost, že jsme na abclinuxu. Na portálu o nějaké proprietální uzavřené technologii bych to ještě pochopil

Co je na greylistingu proprietárního? Je to technika velmi dobře popsaná a nastavení se liší v detailech (tj. hlavně jak dlouho je zpráva odmítána od prvního pokusu a jak dlouho od prvního pokusu je otevřené okno, kdy bude přijata)

[trekker.dk]

Ne já, ale Trekker.dk popisuje pravidla, podle kterých by greylisting měl odmítat všechno.

...což je opět tvůj výmysl. Narozdíl od tebe totiž připouštím, že u stejného e-mailu se při opakovaných pokusech změní čas, je to totiž logické, protože k nim dojde jindy. Jenže IP je už něco trochu jiného, že?

Btw. ještě pořád jsi pořádně neodpověděl na to, jaktože odmítnutí dočasnou chybou kvůli greylistingu je největší zlo, kdežto odmítnutí dočasnou chybou kvůli něčemu jinému je naprosto v pořádku a každý odesílatel je schopen se s tím vypořádat...

[Filip Jirsák]

...což je opět tvůj výmysl. Narozdíl od tebe totiž připouštím, že u stejného e-mailu se při opakovaných pokusech změní čas, je to totiž logické, protože k nim dojde jindy.

Psal jste, že hlavička Received:, kterou vloží přijímající server, je součástí e-mailu. Ta hlavička je pokaždé jiná, tudíž nemohou být (podle té vaší teorie) dva stejné e-maily, takže není možné jeden e-mail doručovat opakovaně.

Jenže IP je už něco trochu jiného, že?

Proč?

Btw. ještě pořád jsi pořádně neodpověděl na to, jaktože odmítnutí dočasnou chybou kvůli greylistingu je největší zlo, kdežto odmítnutí dočasnou chybou kvůli něčemu jinému je naprosto v pořádku a každý odesílatel je schopen se s tím vypořádat...

Odpověděl jsem na to už x-krát. Odmítnutí dočasnou chybou kvůli něčemu jinému nevadí, protože odesílatel pošle e-mail znova, a když chyba pomine, e-mail bude doručen. Odmítnutí dočasnou chybou kvůli greylistingu vadí, protože greylisting není dočasná chyba, ale trvalá chyba, a bude ten e-mail odmítat pořád dokola. Pokud tedy správce tu chybu – greylisting – včas neodstraní.

[trekker.dk]

Odmítnutí dočasnou chybou kvůli greylistingu vadí, protože greylisting není dočasná chyba, ale trvalá chyba

Ha. Ha. Jak vtipné.

Ok, žij si ve svém světě, já s dovolením zůstanu v realitě, kde greylisting pro 99.9 a ještě pár devítek % mailů nepředstavuje vůbec žádný problém a kde mají problémy jenom správci mailserverů - pitomci, co si nastavili nestandardní ptákoviny, aby byli cool.

[pavlix]

Odmítnutí dočasnou chybou kvůli něčemu jinému nevadí, protože odesílatel pošle e-mail znova, a když chyba pomine, e-mail bude doručen. Odmítnutí dočasnou chybou kvůli greylistingu vadí, protože greylisting není dočasná chyba, ale trvalá chyba, a bude ten e-mail odmítat pořád dokola. Pokud tedy správce tu chybu – greylisting – včas neodstraní.

Proč si tedy o GL něco málo nezjistíte?

[Filip Jirsák]

Co si o něm mám zjišťovat? Server s aktivním greylistingem může odmítat opakované pokusy o doručení e-mailu tak dlouho, až vyprší všechny timeouty na straně odesílatele. Odesílatel tedy dodržel všechna ustanovení příslušných RFC, e-mail se pokoušel doručit opakovaně, a pokaždé byl odmítnut. To je pro mne závažný problém greylistingu.

[pavlix]

Odesílatel tedy dodržel všechna ustanovení příslušných RFC, e-mail se pokoušel doručit opakovaně, a pokaždé byl odmítnut. To je pro mne závažný problém greylistingu.

Přitom stačí, aby odesílatel dodržel o maličko víc (99,9% jich to dodržuje automaticky, zbytek se holt přizpůsobí nebo probije na whitelisty, stejně jde jen o ty největší poskytovatele, greylisting stejně není nic víc než dynamický whitelist s odkladem komunikace s těmi, co na whitelistech nejsou, takže je to dost jedno).

To je pro mne závažný problém greylistingu.

Teoreticky ano, v praxi se naštěstí stihl GL rozšířit natolik, že málokoho (tedy kromě vás) napadne úmyslně tvořit mailserver, který s GL maily nedoručí.

Takže ano, problém existuje, ale řekl bych že s nulovým dopadem.

[Filip Jirsák]

S rozšiřováním cloudů bude přibývat těch případů, kdy se e-maily posílají z různých míst – a provozovatel aplikace to nijak nebude moci ovlivnit.

Druhá věc je, že odesílat e-mail znova ze stejného serveru je „přirozené“ chování klusteru/cloudu za normální situace. Může ale nastat nějaká nenormální situace – výpadek jednoho stroje, odříznutí části infrastruktury od sítě, přetížení nějakého uzlu – a teprve v tom okamžiku se doručování přenese na jiné servery. Pro greylisting je to horší situace – kdyby se správci ztrácelo systematicky velké množství e-mailů od Google, nejspíš to zjistí a bude to řešit. Když se ale ztratí sem tam nějaký, je mnohem těžší to vůbec zjistit, a pak určit, co je příčinou.

[VSi]

Proč pořád řešíte, že by měl být problém, když se zpráva podruhé odesílá z jiného uzlu? Která implementace greylistingu s tím má problém? V tom, co používám já, se opakované doručení téže zprávy rozpozná ne podle zdrojové adresy, ale podle Message-Id - viz 151. Jediná vevýhoda je, že se musí přijmout celé tělo zprávy (nevím, jestli jde odmítnou mail po přijetí hlaviček jestli to nějaká implementace umí). Ale reálně to podle mě zásadně nevadí, SPAMy nebývají velké.

Co jsem pozoroval, tak u Googlu bylo téměř pravidlem, že druhé doručení jde z jiné IP adresy než první. A zkoušel to podruhé velmi rychle.

[Filip Jirsák]

Která implementace greylistingu s tím má problém?

Trekkerova.

Jediná vevýhoda je, že se musí přijmout celé tělo zprávy (nevím, jestli jde odmítnou mail po přijetí hlaviček jestli to nějaká implementace umí).

Akorát mi pak není jasné, k čemu je to celé vlastně dobré. Zvětšíte tak provoz na svém serveru, zvýšíte riziko nedoručení regulérního e-mailu a zahodíte nějaký ten spam, který byste stejně rozpoznal i jiným způsobem.

[VSi]

Akorát mi pak není jasné, k čemu je to celé vlastně dobré. Zvětšíte tak provoz na svém serveru, zvýšíte riziko nedoručení regulérního e-mailu a zahodíte nějaký ten spam, který byste stejně rozpoznal i jiným způsobem.

Ta kontrola proběhne po přijetí těla zprávy, ale před odesláním SMTP Response Code. Server klidně může po přijetí těla vrátit klientovi 4xx Temporary Failure. K čemu to je? Je to prostě greylist se všemi jeho kontroverzemi, ale není tam problém s těmi různými odesílacími servery pro stejný mail, za cenu toho, že se trochu zvýší zátěž linky na serveru.

U nás tohle pomohlo odstranit SPAMy, které ostatní metody nezachytily. A že by se nedoručil nějaký regulérní mail kvůli tomuto Greylistu, to se nestává (co sledujeme logy a co říkají uživatelé). Na rozdíl od některých ostatních metod, kde se to občas objeví. Každopádně žádné maily nezahazujeme, některé jsou dočasně/trvale odmítnuty a o tom se odesílatel dozví, a zbytek co server přijme je doručen do inboxů.

[pavlix]

Trekkerova.

Citation needed.

[pavlix]

Proč pořád řešíte, že by měl být problém, když se zpráva podruhé odesílá z jiného uzlu? Která implementace greylistingu s tím má problém? V tom, co používám já, se opakované doručení téže zprávy rozpozná ne podle zdrojové adresy, ale podle Message-Id - viz 151. Jediná vevýhoda je, že se musí přijmout celé tělo zprávy (nevím, jestli jde odmítnou mail po přijetí hlaviček jestli to nějaká implementace umí). Ale reálně to podle mě zásadně nevadí, SPAMy nebývají velké.

Mail lze odmítnout dřív než se přijmou hlavičky, a greylisting se tak standardně implementuje. Jestli máte implementaci, která přijímá celé maily, tak bych hádal, že je to výjimka.

Aneb dáváte Jirsákovi nesmyslný argument a on ho pak bude používat ve všech případech, kdy nebude vědět jak něco lépe vyvrátit.

[pavlix]

S rozšiřováním cloudů bude přibývat těch případů, kdy se e-maily posílají z různých míst – a provozovatel aplikace to nijak nebude moci ovlivnit.

A greylistingu nějak vadí, když se maily posílají z několika míst?

Druhá věc je, že odesílat e-mail znova ze stejného serveru je „přirozené“ chování klusteru/cloudu za normální situace. Může ale nastat nějaká nenormální situace – výpadek jednoho stroje, odříznutí části infrastruktury od sítě, přetížení nějakého uzlu – a teprve v tom okamžiku se doručování přenese na jiné servery.

Greylistingu nijak nevadí, že se druhá strana pokusila doručit mail z více míst.

Když se ale ztratí sem tam nějaký, je mnohem těžší to vůbec zjistit, a pak určit, co je příčinou.

Legendy o ztracených mailech už jsem od vás slyšel kdysi... a to bylo v souvislosti s odmítnutými maily na základě DNS. A taky se neztrácely.

Přijde mi, že ty nesmysly píšete naschvál, protože opět nemáte žádný skutečný argument. A doufáte, že se najde alespoň jedna neznalá ovečka, která si opravdu bude myslet, že Greylisting zahazuje e-maily.

[trekker.dk]

Druhá věc je, že odesílat e-mail znova ze stejného serveru je „přirozené“ chování klusteru/cloudu za normální situace. Může ale nastat nějaká nenormální situace – výpadek jednoho stroje, odříznutí části infrastruktury od sítě, přetížení nějakého uzlu – a teprve v tom okamžiku se doručování přenese na jiné servery.

...takže dojde k jednomu neúspěšnému pokusu navíc. Ó, jak velký to problém. A jen tak mimochodem, tvé pojetí "přirozeného" chování úplně neodpovídá realitě. Minimálně gmail (a nejenom gmail) to tak nedělá.

[Filip Jirsák]

Doporučuju trochu sledovat dění v IT. Pak si všimnete, že při nečekaném problému v nějakém systému se ten systém zpravidla začne chovat dost divně. Například při nedávném výpadku Amazon cloudu se kvůli chybě začaly jednotlivé uzly odpojovat a následně masivně replikovat na jiné uzly.

Takže to, co za normálního provozu funguje tak, že e-mail doručuje jeden uzel a při výpadku to převezme jiný, se v případě chyby může snadno začít chovat tak, že každý pokus o doručení půjde z jiného uzlu. Ostatně, vám to má být jedno, zda je to v důsledku chyby nebo zda je to standardní chování – je to chování zcela v souladu se standardy, ničemu to nevadí, takže pokud takové e-maily zahazujete, je to problém na vaší straně. Který ovšem odnese někdo úplně jiný, než vy.

Minimálně gmail (a nejenom gmail) to tak nedělá.

Vy víte, jak se GMail chová v nestandardních situacích? A jak se bude chovat v situacích, které ještě ani nenastaly? To byste měl říct inženýrům z Googlu, ti budou za takové informace určitě vděční.

[trekker.dk]

Nauč se číst a nevytrhávat z kontextu. Abych ti do začátku trochu pomohl, přihodím ti sem ten kontext.

Druhá věc je, že odesílat e-mail znova ze stejného serveru je „přirozené“ chování klusteru/cloudu za normální situace.

A jen tak mimochodem, tvé pojetí "přirozeného" chování úplně neodpovídá realitě. Minimálně gmail (a nejenom gmail) to tak nedělá.

Tvoje reakce - Vy víte, jak se GMail chová v nestandardních situacích? - je zjevně úplně mimo mísu.

Ostatně, vám to má být jedno, zda je to v důsledku chyby nebo zda je to standardní chování – je to chování zcela v souladu se standardy, ničemu to nevadí, takže pokud takové e-maily zahazujete, je to problém na vaší straně.

Ještě jednou, protože některým to zjevně nedochází: greylisting maily nezahazuje

[Filip Jirsák]

Ještě jednou, protože některým to zjevně nedochází: greylisting maily nezahazuje

Je jedno, jestli e-mail zahodíte, nebo jestli jej opakovaně odmítáte přijmout. V obou případech se nedoručí a odesílatel nemá reálnou možnost s tím něco udělat.

[pavlix]

Je jedno, jestli e-mail zahodíte, nebo jestli jej opakovaně odmítáte přijmout.

Tohle si dejte do CV a už nikdy vás nikdo na pozici, která zahrnuje administraci e-mailu, nepřijme.

[trekker.dk]

Toho bych se nebál - "expertů", kteří nerozlišují odmítnutí a zahození, je bohužel hodně.

[Filip Jirsák]

Máte pravdu, úplně stejné to není. O zahozeném e-mailu se nikdo nedozví, takže je to nakonec všem jedno. O odmítnutém e-mailu se odesílatel dozví, takže učiní ještě několik zoufalých neúspěšných pokusů e-mail odeslat znova. Takže výsledek je sice stejný (adresát e-mail nedostane), ale v případě odmítnutí je tam navíc frustrovaný odesílatel, který ztrácí čas marnými pokusy e-mail doručit.

[trekker.dk]

O odmítnutém e-mailu se odesílatel dozví, takže učiní ještě několik zoufalých neúspěšných pokusů e-mail odeslat znova. Takže výsledek je sice stejný

Nebo použije jinou odesílací adresu (= jiného poskytovatele služby), případně telefon a informace o tom, že se mail nepodařilo doručit, se nakonec dostane i k příjemci. Výjimkou jsou samozřejmě případy, kterým greylisting vadí natolik, že když se jim zpráva vrátí zpátky, tak nic neřeší, aby mohli nadávat...

[Filip Jirsák]

Takže e-mail nakonec máme k tomu, abychom místo něj raději použili telefon? Není pak lepší použít telefon rovnou?

Jinak na spoustu lidí nemusíte mít jiný kontakt, než 1 e-mailovou adresu. Posílat e-mail od jiného odesílatele pro většinu lidí není řešení, protože e-mail jinde nemají a nevědí, že by to mohlo pomoci.

[trekker.dk]

Takže e-mail nakonec máme k tomu, abychom místo něj raději použili telefon?

Ok, vysvětlení jako pro idiota, protože nic náročnějšího prostě asi neklapne:

1. e-mail není doručen, protože greylisting
2. odesílatel se dozví, že e-mail nebyl doručen
3. odesílatel použije jiný prostředek, aby dal příjemci na vědomí, že e-mail nedošel
4. příjemce se obrátí na svého poskytovatele služby
5. poskytovatel služby - pokud byla chyba na jeho straně, např. ten tvůj oblíbený rozesílací cluster - upraví nastavení greylistingu
6. příští e-mail je doručen

Je to už jasné, nebo mám kreslit obrázky?

Jinak na spoustu lidí nemusíte mít jiný kontakt, než 1 e-mailovou adresu. Posílat e-mail od jiného odesílatele pro většinu lidí není řešení, protože e-mail jinde nemají a nevědí, že by to mohlo pomoci.

Víš co je zajímavé? Že přestože podle tvé teorie nic nejde a všechno je špatně, praxe nakonec ukazuje, že jde leccos a nakonec to funguje.

[Filip Jirsák]

odesílatel použije jiný prostředek, aby dal příjemci na vědomí, že e-mail nedošel

Pokud bude těch překážek čím dál víc, zvolí příště jiný prostředek hned v bodu 1. Pro soukromou korespondenci třeba Facebook. A zatím budou někde v koutku někteří správci nasazovat greylisting a pochybné blacklisty, a o přestávkách si budou navzájem stěžovat, jak ti hloupí uživatelé používají Facebook.

poskytovatel služby - pokud byla chyba na jeho straně, např. ten tvůj oblíbený rozesílací cluster - upraví nastavení greylistingu

To udělá hloupý poskytovatel služby. Chytrý poskytovatel nebude záměrně rozbíjet funkční systém a pak čekat na hlášení uživatelů, aby to zase opravil.

Víš co je zajímavé? Že přestože podle tvé teorie nic nejde a všechno je špatně, praxe nakonec ukazuje, že jde leccos a nakonec to funguje.

Ano, funguje. Lidé si zvykají, že se e-maily občas nedoručí, protože je správce systému příjemce nechce přijmout, a hledají si jiné způsoby komunikace. Čímž se opět vracíme na začátek – kdybyste ten e-mailový systém rovnou vypnul, bude tenhle přechod rychlejší a bude to bez obelhávání uživatelů o tom, že děláte všechno proto, aby se jim e-maily doručily.

[trekker.dk]

Chytrý poskytovatel nebude záměrně rozbíjet funkční systém a pak čekat na hlášení uživatelů, aby to zase opravil.

Systém, ve kterém se doručuje spousta spamů, není funkční.

Lidé si zvykají, že se e-maily občas nedoručí, protože je správce systému příjemce nechce přijmout, a hledají si jiné způsoby komunikace.

Taková je tvoje teorie. Praxe - opět - ukazuje něco jiného.

[Filip Jirsák]

Systém, ve kterém se doručuje spousta spamů, není funkční.

Oprava ale spočívá v tom přesouvat spam do příslušné složky, ne bránit doručování normální pošty.

[trekker.dk]

No a teď zpátky do reálného světa (kde mimo jiné greylisting z drtivé většiny brání hlavně doručování spamu a ne normální pošty)

[pavlix]

Máte pravdu, úplně stejné to není. O zahozeném e-mailu se nikdo nedozví, takže je to nakonec všem jedno.

Tvrzením, že je to jedno, jste tomu zase tak moc nepomohl.

[VSi]

To přece nemusí vadit. Nevím, nad jakou implementací greylistu uvažujete, ale v tom co používám já, se e-mail identifikuje podle hashe ($sender_address, $recipients, $header_message-id). Takže vůbec nevadí, že ten samý mail podruhé posílá stroj s jinou IP adresou - a že třeba Google to dělá. Samozřejmě se zdrží trochu větší počet mailů, ale postupně se do tabulky "zdravých" IP adres dostanou všechny odesílací mailservery z případného clusteru.

[pavlix]

Tak on se hlavně e-mail vůbec neidentifikuje.

[trekker.dk]

Vynechal jste, že odesílatel musí splňovat vaše pravidla (která nazýváte normálem)

Ještě jednou a tentokrát tučně, třeba si to konečně přečteš: jsou to pravidla odpovídající chování drtivé většiny mailserverů, nikoliv "moje" pravidla. Nebo ještě názorněji:

1. vezmi chování drtivé většiny mailserverů

2. nastav greylisting tak, aby maily z těchto serverů bez problémů prošly

Ano, maily z Jirsákova mailserveru™ naschvál nakonfigurovaného tak, aby pro něj byl greylisting nepřekonatelnou překážkou, to opravdu nevezme. Přiznám se, že mi to žíly netrhá, protože s tímhle přístupem ten server nikdo používat nebude.

co vidíte nenormálního na clusteru odesílajících klientů

a) nic, pokud při odmítnutí mailu odesílají ten samý mail, ne nějaký jiný

b) ještě jednou tučně: lze je uvést ve whitelistech

nebo na odesílajícím klientu bez pevné IP adresy

Totéž - neposílá stejný mail. A jestli někdo chce mít vlastní mailserver na reálné používání a ne kvůli pochybné argumentaci v diskuzích, určitě pro něj nebude problém koupit si od ISP tu adresu napevno. (Nebo rovnou pronajmout nějakou VPS.)

[cynic_asshole]

Nemůžu si pomoci, ale pan Jirsák mi připomíná jistého Kolesu, který položí dotaz a pak si vymýšlí důvody, proč navrhovaná řešení není možno aplikovat.

[Heron]

Totéž - neposílá stejný mail. A jestli někdo chce mít vlastní mailserver na reálné používání a ne kvůli pochybné argumentaci v diskuzích, určitě pro něj nebude problém koupit si od ISP tu adresu napevno. (Nebo rovnou pronajmout nějakou VPS.)

To je ale přece jen něco jiného. Daný klient klidně může mít svůj echt server pro příjem pošty, ale pro odesílání své pošty na svém (například) notebooku může požívat lokální smpt, které se potom postará o doručení na cílový server příjemce.

[cynic_asshole]

No to bys těch e-mailů moc neposlal. Spíš ten lokální MTA bude používat jako relay ten svůj echt server pro příjem pošty.

[Heron]

No dnes již ne, před pár lety to fungovalo skvěle. Potom někteří správci začali nějak konfigurovat své servery a nutili celý okolní svět se jim přizpůsobit.

[trekker.dk]

Zase jsi vynechal jeden krok.

Před pár lety to začalo fungovat skvěle, pak se začala šířit spamovací havěť a PAK teprve správci začali konfigurovat své servery tak, aby jim ten spam nechodil.

Pokud přijde mail z rozsahu, ze kterého Telekom přiděluje IP pro svoje ADSL, téměř na 100% je to spam. Pokud nutně někdo potřebuje svého vlastního SMTP démona, tak si může snadno poradit tak, aby ty maily chodily zdánlivě odjinud.

[Heron]

Jasně zrovna tady jsem taky váhal, jestli ten komentář mám odesílat (ale pro úplnost jsem si jej nemohl odpustit ), protože tohle vím (pracoval jsem u ISP a také jsme s tím bojovali). Nikdy jsem ale odchozí pětadvacítku neblokoval a snažil jsem se radit jednotlivým klientům, jak to dělat správně (tedy poštu odesílat přes nějaký jejich server).

Zrovna ADSL subnety jsou ihmo na blacklistech automaticky a dávají je tam samotní adsl poskytovatelé. Nepřijde mi to úplně košér, ale pokud je o tom klient takového "připojení" informován, tak proč ne.

[pavlix]

Zrovna ADSL subnety jsou ihmo na blacklistech automaticky a dávají je tam samotní adsl poskytovatelé.

Zapomněl jsi zmínit, že jsou na samostatných blacklistech, takže provozovatel může a nemusí ADSL blokovat.

[Heron]

Nezapoměl. Když dovolíš, nebudu do svých komentářů psát úplně všechno.

[pavlix]

Takže to bylo úmyslné zamlčení, mystifikace?

[Heron]

Skutečně argumentace na úrovni. Jsou na blacklistech? Jsou. Co na tom není pravda? Uvádíš ty ve svých komentářích všechno? Nevádíš, není to v lidských silách a i kdyby, tak by to nikdo nečetl.

To, že existují různé blacklisty, které obsahují různé IP je snad taky jasné.

To je ale nakonec úplně jedno, jaký je to BL. Pokud daný server blokuje z libovolného důvodu emaily z IP daného klienta, tak ten klient má problém.

[pavlix]

Skutečně argumentace na úrovni

Neútoč :), nepomůžeš si.

Uvádíš ty ve svých komentářích všechno?

Snažím se nemystifikovat. A pokud mě někdo doplní, slušně poděkuju.

[pavlix]

Potom někteří správci začali nějak konfigurovat své servery a nutili celý okolní svět se jim přizpůsobit.

Holt, když SMTP pošta nebyla připravená k použití na Internetu, tak se musely standardy doladit. Ať už na papíře nebo de facto.

[trekker.dk]

+1

Spousta ISP a správců sítí blokuje port 25, protože na odesílání pošty máš používat jejich server. (Většinou s autentizací, aby ho nemohla jen tak zneužít spamovací havěť.)

[Heron]

Hmm, jeden by si myslel (samozřejmě opět špatně), že ISP je tu pro poskytování IP konetivity. Spletl jsem se, ISP je tu zřejmě pro blokování IP konektivity.

[trekker.dk]

Když se podíváš do podmínek poskytování služby, tak tam určitě najdeš i něco v tom smyslu, že nesmíš dělat bordel, porušovat zákony a tak dál. To přesně rozesílatelé spamů dělají, takže se nemůžou divit, že jim ISP něco zablokuje.

Samozřejmě bys mohl namítnout, že to zablokuje všem včetně nevinnných, bla, bla, bla - ano, smůla. Když někdo (spammeři - a teď myslím iniciátory, ne BFU se zavirovaným kompem) škodí, někdo utrpí škodu a musí si (třeba) koupit VPS

[Heron]

Když se podíváš do podmínek poskytování služby, tak tam určitě najdeš i něco v tom smyslu, že nesmíš dělat bordel, porušovat zákony a tak dál. To přesně rozesílatelé spamů dělají, takže se nemůžou divit, že jim ISP něco zablokuje.

Tak to jsi ty podmínky pochopil špatně. Ten blábol o zákonech tam samozřejmě je, o tom žádná (sice nemáš žádnou zákonou možnost zjistit, zda ten klient to porušuje, ale ok).

Já jsem ty podmínky psal také (a není to tak dávno, loni na podzim) a "nesmíš dělat bordel" jsem klientů, vždy vysvětloval jako nesmítě dělat bordel na síti, tedy posílat cíleně upravené packety narušující infrastrukturu sitě (všechny ty DOS, poisoningy apod.). Pokud ten packet z IP A na IP B je formálně OK, tak je mi (jakožto ISP) jeho obsah putna.

[trekker.dk]

Záleží na poskytovateli. U mého je třeba tohle: Zákazník je povinen užívat Službu tak, aby nebyl porušován nebo obcházen zákon, nezpůsoboval škody třetím osobám, nebo aby užívání Služby nebylo v rozporu s dobrými mravy.

Samozřejmě v praxi těžko budou zkoumat, co dělám (to stejně v mnoha případech ani nesmí), ale je to tam. A když si potom někdo stěžuje, že z adresy té a té chodí spam, tak už není problém párovat to se zákazníkem.

[cynic_asshole]

Na odesílání pošty z MUA na MTA/MSA máš používat submission (tcp/587). Nesetkal jsem se s tím, že by byl někde blokovaný. Více viz RFC5068

[trekker.dk]

To jo, nicméně většina poštovních klientů má přednastaveno 25.

[cynic_asshole]

Když je tedy podle Vás greylisting tak špatný, můžete nám říci Váš názor na to, proč takovou špatnou techniku používá i gigant jako je Google?

[Heron]

Ať si používá co chce. Zrovna u GMailu jsem zaznamenal nejvíc false positives případů, co se týče emailů označených jako spam. (Což samozřejmě není nic moc statistika.) A od té doby si fetchmailem vybírám i gmail složku [Gmail]/Spam, protože to vymysleli fakt chytře a při nastaveném přeposílání všeho na jiný účet se tohle nepřeposílá.

[pavlix]

Ať si používá co chce. Zrovna u GMailu jsem zaznamenal nejvíc false positives případů, co se týče emailů označených jako spam.

Za to ale asi greylisting nemůže :).

[Heron]

Píšu snad někde něco takového?

[pavlix]

Kdybys zmínil, že se odkláníš od tématu greylistu, neměl bych potřebu tě doplňovat :).

[SPM]

Většina lidí taky používá Windows a neznamená to, že by to byl nějakej super skvělej OS :)

[Filip Jirsák]

Protože ji nepoužívá. Ostatně už jsme to psal výše – jak je možné, že takový gigant, jako Google, který se se spamem dokáže vyrovnat daleko lépe, než všichni zastánci greylistingu dohromady, žádný greylisting nepotřebuje?

[trekker.dk]

Tenhle příspěvek ve spojení s #110 dává dohromady docela zajímavou informaci...

[pavlix]

Jsem rád, že mám svého soukromého psychologa.

Na to nemám kvalifikaci :).

To bys s klidným svědomím napsat mohl ve chvíli, kdy bych něco takového vyplodil. Což se nestalo.

Vždyť ty jsi hbitě odsouhlasil následující názor:

Mno, osobně shledávám greylisting stejně užitečný, jako automat na kondomy ve Vatikánu... ještě lepších výsledků člověk dosáhne, když si zadropuje port 25 na mailserveru (tam neprojde spam žádný ) :)))

Slovy:

Jsem skutečně rád, že v této diskusi nejsem první, kdo tohle napsal . Minule to mělo poněkud neblahé konsekvence.

Nediv se, že jsem tomu rozuměl tak, že se s tím vyjádřením plně ztotožňuješ.

[Heron]

Vždyť ty jsi hbitě odsouhlasil následující názor:

Kurňa, odvolávám co jsem odvolal. Jsem se tak moc soustředil na to blokování TCP/25 až jsem úplně přehlédl tu první část. Teď už se ničemu nedivím, ale bylo tím myšleno skutečně jen to blokování pětadvacítky.

[Filip Jirsák]

Téměř nikdy nevede na nedoručění mailu z jiného mailserveru.

To o svém řešení antispamu tvrdí skoro každý. A skoro nikdo to nedokáže obhájit ničím jiným, než že si myslí, že to tak je.

A ta metoda má oproti žádné metodě obrovskou účinnost

Záleží na tom, jak se ta účinnost měří. Většinou se účinnost antispamového řešení posuzuje počtem zadržených spamů, a ignoruje se, kolik bylo zadrženo „normálních“ e-mailů. Pak má ale pravdu Heron, protože nejúčinnější je zablokovat port 25 nebo vypnout poštovní server – pak neprojde žádný spam. Pokud tedy chceme účinnost počítat jinak a zahrnout do ní i počet e-mailů, které byly chybně odmítnuty, je potřeba u každé metody – tedy i u greylistingu – popsat, jaké je riziko odmítnutí „normálního“ e-mailu.

[trekker.dk]

To o svém řešení antispamu tvrdí skoro každý. A skoro nikdo to nedokáže obhájit ničím jiným, než že si myslí, že to tak je.

V tomto případě to lze snadno obhájit znalostí toho, jak funguje SMTP. Správně nastavený server se má o doručení pokoušet opakovaně.

[Filip Jirsák]

To ale nestačí. Problém není na straně serveru, ale na straně greylistingu – nemusí pokaždé správně poznat, že jde o opakované doručení. Doručení na záložní server nebo doručení z jiného serveru je totiž také opakované doručení, ale greylisting to nemusí poznat.

[asfethan]

Ah ano a potom je to o spravnom nastaveni greylistingu vsakze Cize sa stale tocime v koliecku bez poriadnych argumentov...

[Filip Jirsák]

Jaké je tedy to správné nastavení greylistingu, které přijme e-mail při opakovaném pokusu o doručení, ať je ten druhý pokus učiněn kdykoli a odkudkoli?

Pořádný argument by bylo „nasadil jsem antispamové řešení a měřením jsem zjistil, že zadrží 83 % spamu a 3 % ‚normálních‘ e-mailů“.

[trekker.dk]

a) druhý pokus nemá být učiněn kdykoliv, ale v nějakých rozumných intervalech

b) mail odeslaný z jiného serveru můžu s klidem považovat z jiný mail (jiná hodnota hlaviček Received) a budu mít pravdu. Což samozřejmě neznamená, že se nemůžu pokusit přenastavit ten GL tak, aby i takové maily přijal, nicméně jsem z obliga, když to neudělám.

[Filip Jirsák]

Když ty rozumné intervaly nejsou nikde nadefinovány, hrozí, že si pod nimi každý představí něco jiného – tudíž SMTP nezaručuje, že dojde k opakovaném pokusu o doručení „v rozumném intervalu“, tudíž nemáte žádnou záruku, že greylisting nebude zahazovat i normální e-maily.

Mail odeslaný z jiného serveru můžete s klidem považovat za jiný mail, pak se ho ale nikdy nedočkáte, protože pro greylisting to bude pokaždé nový e-mail, který odmítne – a odesílající cluster to za týden přestane bavit a e-mail prohlásí za nedoručitelný.

[trekker.dk]

První odstavec - naštěstí většina správců nejsou idioti, takže ty intervaly jsou opravdu nastavené rozumně a GL funguje. Ty ostatní řeší slovo téměř ve větě "Téměř nikdy nevede..." výše.

Druhý odstavec - opakuji ještě jednou: dá se to řešit nastavením

[Filip Jirsák]

Jakým nastavením? Jak nastavíte greylisting, aby jím prošel e-mail, který se odesílá z clusteru o desítkách či stovkách počítačů?

[cynic_asshole]

Povolením rozsahu IP či celé domény, pokud je to možné (spam s podvrženou adresou odesílatele by měly zlikvidovat další techniky). Nicméně jsem se setkal už s tím, že v případě, kdy odesílající server dostal 4XX odpověď a při pokusu o druhé doručení z jiného stroje dostal opět stejnou chybu, třetí pokus o doručení se provedl opět ze stroje prvního.

[Filip Jirsák]

Povolením rozsahu IP či celé domény

To u cloudu nemusí stačit. Navíc zjišťovat on-line při SMTP spojení rozsah IP taky nebude zrovna jednoduché (nebo tam dáte natvrdo třeba /24, ale to už je zase věštění z křišťálové koule).

Nicméně jsem se setkal už s tím, že v případě, kdy odesílající server dostal 4XX odpověď a při pokusu o druhé doručení z jiného stroje dostal opět stejnou chybu, třetí pokus o doručení se provedl opět ze stroje prvního.

Což ale vyžaduje úpravy na straně odesílatele, což je přesně to, co se mi na tom „řešení“ nelíbí. Kde kdo si navrhne nějaké svoje geniální protispamové řešení, a starosti s doručováním pak mají ostatní. Kdyby to dotyční alespoň přiznali, že jim nevadí odmítat neznámé množství regulérních e-mailů… Ideálně nějak strojově zpracovatelně, že by byl registr domén, jejichž správci e-mailových serverů mají vlastní pravidla pro příjem pošty a nějaký zahozený regulérní e-mail je netrápí, takže používají greylisting, pochybné blacklisty, kontrolu reverzních DNS záznamů. Pak by stačilo na straně odesílatele se podívat, zda je server na takovémhle seznamu, a pokud ano, rovnou e-mail zahodit. A všichni by byli spokojeni.

[trekker.dk]

Kdo chce, hledá způsob. Kdo nechce hledá důvod, viď?

To u cloudu nemusí stačit.

Co je na cloudu tak výjimečného, že nestačí, když povolím doménu toho, komu ten cloud patří?

Navíc zjišťovat on-line při SMTP spojení rozsah IP taky nebude zrovna jednoduché

Ajaj, to je obrovský problém. On se totiž seznam rozsahů nedá nikde stáhnout. Nechceš doufám tvrdit, že se musí pracovat s naprosto aktuálními údaji a maximálně 24 hodin staré nestačí...

Což ale vyžaduje úpravy na straně odesílatele

Viz výše - pokud odesílatel chce odesílat stejný mail, je to na něm. (Na kom jiném taky?)

Kdyby to dotyční alespoň přiznali, že jim nevadí odmítat neznámé množství regulérních e-mailů...

Asi tomu nebudeš věřit, ale to množství není tak neznámé. Oni lidi totiž většinou mají za to, že zprávy, které jim někdo posílá, jsou důležité - když jim nepřijdou, tak mají tendenci si stěžovat.

[Filip Jirsák]

Kdo chce, hledá způsob. Kdo nechce hledá důvod, viď?

Tak proč nezablokujete ten port 25? To je přece taky způsob, a daleko účinnější.

Co je na cloudu tak výjimečného, že nestačí, když povolím doménu toho, komu ten cloud patří?

Jakou doménu? Reverzní k IP adrese? Co když si takovou doménu nastaví i spammer?

Ajaj, to je obrovský problém.

Není to obrovský problém. Jenom to musíte zpracovat v rámci SMTP relace a klient se musí dočkat odpovědi v rozumném čase.

Viz výše - pokud odesílatel chce odesílat stejný mail, je to na něm. (Na kom jiném taky?)

Odesílatel chce poslat e-mail, dodrží všechna ustanovení RFC, a vy ten e-mail stejně opakovaně odmítáte – protože nevyhovuje nějakým vašim pravidlům, které dotyčný nemá šanci zjistit. To není problém na straně odesílatele.

Oni lidi totiž většinou mají za to, že zprávy, které jim někdo posílá, jsou důležité - když jim nepřijdou, tak mají tendenci si stěžovat.

Teď si protiřečíte. Na jednu stranu vás nedoručené zprávy nezajímají, a teď je zase považujete za důležité. Jak se vůbec adresát o těch nedoručených zprávách dozví?

[cynic_asshole]

Proč je nemáte jak zjistit? Logovat chybové hlášky a pak to prohnat skriptem. Většinou je v popisu chybky slovo greylist.

[Filip Jirsák]

A jak poznáte, zda šlo o spam?

[trekker.dk]

Tak proč nezablokujete ten port 25? To je přece taky způsob, a daleko účinnější.

Pod slovem účinnost antispamových opatření si zjevně představujeme každý něco jiného.

Jakou doménu? Reverzní k IP adrese? Co když si takovou doménu nastaví i spammer?

Tu doménu, jejíž pošta se odtud odesílá. Co je na tom k nepochopení?

Není to obrovský problém. Jenom to musíte zpracovat v rámci SMTP relace a klient se musí dočkat odpovědi v rozumném čase.

Hm, jeden select do DB... no jo, to se nedá stihnout...

vy ten e-mail stejně opakovaně odmítáte – protože nevyhovuje nějakým vašim pravidlům, které dotyčný nemá šanci zjistit.

Pokud nevyhovuje těm pravidlům, nechová se odesílatel podle RFC nebo se přinejmenším nechová normálně. A moje pravidlo je jednoduché: pokud je zpráva odmítnuta s dočasnou chybou, má se jí odesílatel pokusit odeslat znovu (tu samou, ne nějakou jinou). Tak by se měl chovat bez ohledu na greylisting.

Na jednu stranu vás nedoručené zprávy nezajímají, a teď je zase považujete za důležité.

Zkus si ještě jednou přečíst, na co reaguješ.

Jak se vůbec adresát o těch nedoručených zprávách dozví?

Kdo chce, hledá způsob...

[Filip Jirsák]

Pod slovem účinnost antispamových opatření si zjevně představujeme každý něco jiného.

To jsem psal už dávno. Pro mne se účinnost snižuje s každým spamem, který projde, a také s každým normálním e-mailem, který neprojde – přičemž ty ztracené normální e-maily mají daleko větší váhu. Pro vás je účinnost jenom to, kolik spamu to zastaví, nedoručené regulérní e-maily vás nezajímají. Proto vám radím zablokovat port 25, tím dosáhnete ve vašem pojetí 100% účinnosti.

Tu doménu, jejíž pošta se odtud odesílá. Co je na tom k nepochopení?

Takže to, co je v MAIL FROM za zavináčem. No, to si pomůžete.

Pokud nevyhovuje těm pravidlům, nechová se odesílatel podle RFC nebo se přinejmenším nechová normálně.

Přičemž co je „normálně“ definujete vy. Takže se nechová podle vašich pravidel, která dotyčný nemá šanci zjistit.

A moje pravidlo je jednoduché: pokud je zpráva odmítnuta s dočasnou chybou, má se jí odesílatel pokusit odeslat znovu (tu samou, ne nějakou jinou).

To je sice hezké pravidlo, ale i když ho někdo splní, vy mail stejně v některých případech odmítnete.

Kdo chce, hledá způsob...

Třeba bych si ke každému e-mailu mohl zjišťovat nějaké telefonní číslo, a s každým odeslaným e-mailem jim zavolat, že posílám e-mail…

Kdo chce doručit takřka všechny regulérní e-maily a minimum spamu, hledá způsob, jak to udělat. Někdo jiný chce zahodit co nejvíce e-mailů, a taky si k tomu hledá způsob.

Mně by ty různé antispamové kontroly nevadily, ale problém je, že neschopností správce serveru příjemce trpí nevinní odesílatelé a správci jejich serverů. A bohužel tyhle kontroly jako agresivní blacklisty, greylisting nebo kontrola reverzního DNS záznamu nasazují především právě ti správci, kterým to moc nejde. Je zajímavé, že existují řešení, která jsou zadarmo, která greylisting, agresivní blacklisty ani kontrolu reverzního záznamu nedělají, a přesto při desítkách e-mailů doručených denně do jedné schránky zařadí mezi spam desetiny až jednotky e-mailů ročně (a i ten je stále možné vyzvednout z příslušné složky), a do spamu nezařadí jednotky e-mailů měsíčně. Mají tedy nesrovnatelně vyšší účinnost, než tyhle zoufalé pokusy s greylisty a dalšími „ochranami“.

[trekker.dk]

Pro vás je účinnost jenom to, kolik spamu to zastaví, nedoručené regulérní e-maily vás nezajímají.

Hmmm... máš tam ještě nějakou blbost, kterou bys o mě chtěl tvrdit?

Přičemž co je „normálně“ definujete vy.

Ne, co je normálně, definuje drtivá většina provozovatelů poštovních serverů.

Někdo jiný chce zahodit co nejvíce e-mailů, a taky si k tomu hledá způsob.

Nikoho takového neznám, ale připouštím, že takoví mohou existovat.

[Filip Jirsák]

Pro vás je účinnost jenom to, kolik spamu to zastaví, nedoručené regulérní e-maily vás nezajímají.

Hmmm... máš tam ještě nějakou blbost, kterou bys o mě chtěl tvrdit?

Pokud by to byla blbost, daly by se tady dohledat vaše příspěvky, ve kterých řešíte, kolik regulérních e-mailů se tímhle způsobem odmítne a jak ten počet snížit na minimum.

Ne, co je normálně, definuje drtivá většina provozovatelů poštovních serverů.

No jo, ale každý to definuje jinak. O něčem svědčí i to, že co je to to „normálně“ pro jistotu nikdo nenapsal ani sem do diskuse.

[trekker.dk]

Pokud by to byla blbost, daly by se tady dohledat vaše příspěvky, ve kterých řešíte, kolik regulérních e-mailů se tímhle způsobem odmítne a jak ten počet snížit na minimum.

Tak tenhle, ehm, argument je hodně velká slabota...

No jo, ale každý to definuje jinak.

...přičemž na nějakém společném průniku se ta drtivá většina (já nikdy nepsal, že každý), shodne.

[Heron]

První odstavec - naštěstí většina správců nejsou idioti, takže ty intervaly jsou opravdu nastavené rozumně a GL funguje.

Jinými slovy ale potvrzuješ to, co psal Filip níže. A sice, že ty si zvolíš nějaké svoje řešení a pokud to někdo neakceptuje, tak ho pro jistotu onálepkuješ slovem idiot.

V emailové komunikaci je potom neskutečný bordel, každý si nasazuje ten svůj nejlepší antispam (řešení, na které často ani není platný standard) a nutí celý okolní svět se zrovna mu přizpůsobit. V podstatě to popírá onu myšlenku "buď tolerantní na vstupu, ale přísný na výstupu".

[trekker.dk]

A jak bys ty onálepkoval člověka, který si na mailserveru nastaví, že opakované odesílání zpráv se děje vždy v 5 hodin ráno a jenom tehdy? (Hint: co se asi stane, když má někdo jenom jeden mailserver a ten se v danou dobu automaticky odstavuje kvůli zálohování např.)

V podstatě to popírá onu myšlenku "buď tolerantní na vstupu, ale přísný na výstupu".

Klidně se té myšlenky drž, já se u pošty budu s dovolením držet toho, že spam nechci a když proti němu něco funguje, tak to použiju.

[asfethan]

Co je to za blbost ze moze byt druhy pokus vykonany odkialkolvek a kedykolvek? Nezijeme predsa vo svete mytov...A ked si nevie odosielatel poriadne nastavit svoj server tak nech sa necuduje ze jeho maily koncia v ...

Proste uz vymyslate nezmyselne konstrukcie... STOP!

[Filip Jirsák]

Není to žádná blbost. Druhý pokus může být za 30 sekund nebo za 30 minut, obojí jsou rozumné časy. Druhý pokus může přijít z úplně jiného klienta, než první, protože existují i trošku větší systémy než takové, které doručí pár stovek e-mailů denně.

Odesílatel může mít servery nastavené přesně podle RFC, ale váš greylisting bude jeho e-maily stejně odmítat. A vy o tom nechcete vědět. Pak se nedivte radě zablokovat port 25 – tím se spamu zbavíte úplně. O nedoručování regulérních e-mailů přece nechcete nic vědět – a koneckonců, ať si odesílatel nastaví pořádně svůj server (tj podle vašich představ), pak mu nějaký zablokovaný port 25 nebude vadit.

[trekker.dk]

Druhý pokus může být za 30 sekund nebo za 30 minut, obojí jsou rozumné časy.

Hint: druhý pokus není nutně poslední.

[Filip Jirsák]

To ale nijak nepomůže. Pořád může nastat případ, že otevřené okno pro příjem začne až po n. pokusu a skončí před n+1. Ano, záleží na tom, jak jsou nastavené časy. Pro jaké časy je tedy jaká pravděpodobnost přijetí normálního e-mailu?

[trekker.dk]

Pořiď si mailserver, nasaď greylisting, podívej se do logů a uvidíš. Pro časy, se kterými mám zkušenosti já, je ta pravděpodobnost 99,999... a ještě spousta devítek za tím.

[Filip Jirsák]

Jak z logů poznám, kolik regulérních e-mailů bylo odmítnuto?

[trekker.dk]

Tvůj boj.

[trekker.dk]

Doručení na záložní server

A jak si přesně představuješ, že by tohle nefungovalo? Jako že odesílatel zkusí primární server (4xx), pak sekundární (4xx) a tím končí? Ano, pak se ten mail opravdu nedoručí, jenže tohle je chyba odesílatele, který se má pokoušet doručovat v nějakých intervalech po rozumně dlouhou dobu.

nebo doručení z jiného serveru je totiž také opakované doručení

Což se samozřejmě nechá ošetřit.

[Filip Jirsák]

Mě by právě zajímalo, co je to to „nějaký interval“, „rozumně dlouhá doba“ a „samozřejmě nechá ošetřit“. Protože to jsou právě ty hodnoty, které určují, kolik „normálních“ e-mailů odmítnete.

[trekker.dk]

První dva: RFC2821. To třetí: whitelist (třeba), mimo jiné byl zmíněn i v původním blogpostu.

[pavlix]

Díky za všechno, vysvětlovat panu Jirsákovi opakovaně notoricky známé věci mě docela unavuje.

[pavlix]

To o svém řešení antispamu tvrdí skoro každý. A skoro nikdo to nedokáže obhájit ničím jiným, než že si myslí, že to tak je.

Jiní snad už dávno pochopili, že nejsem ten typ člověka. Navíc, jak už psal trekker, stačí využít znalost fungování mailu. Druhý pokus o doručení není poslední. A tak dále, a tak dále.

Mě někdy přijde, že ani nejste až takový amatér, že si jen na něj hrajete.

Záleží na tom, jak se ta účinnost měří.

Já účinnost měřím počtem ručně mazaných spamů :).

[brk]

A nebo prostě přes normální mail servery, což už se částečně děje.

Tam do jisté míry pomáhají blacklisty.

Ba naopak, tady už je to fakt problém. Nedávno mi přišla od kolegy z práce nabídky na iPad 2. Krajně podezřelá mi na tom byla angličtina, ale jinak tomu mailu nebylo moc co vytknout a další lidé se ho ptali osobně i na podrobnosti.

Kolegovým bezpečnostním prohřeškem bylo to, že se do své pošty na Gmailu přihlásil z nějaké "neznámé" mašiny u zákazníka a nějaké breberka z toho compu rázem odeslala pryč jeho přihlašovací údaje. Takřka okamžitě dostali všichni adresáti, se kterýma kdy přišel do styku z daného účtu, nabídku právě na iPad. Žádná viagra a nabídka od známé osoby, takže z pohledu spamera ideální stav a ze strany správce mailserveru takřka neřešitelný problém. Ruku na srdce, kdo se občas takhle někam nepřihlásí?

Kolega měl docela štěstí. Google ho upozornil na podezřelou událost a spambot mu neukradl další hesla stylem zaslání zapomenutých hesel. Kolik služeb ale na něco takového upozorní jako Google?

Něco v podobném duchu v podstatě padlo i onehdy na Rootu v článku Spam se mění a filtrace přestává být efektivní.

[Max]

Ahoj, bohužel klienti mají jiný názor. Obyčejný uživatel si myslí, že email je něco jako pošta s tím, že když si zaškrtne potvrzení o doručení, tak je to něco jako doporučený dopis s tím, že adresát to musí mít u sebe do 5min.
Když klientovi začneš vysvětlovat, že nemůžeš nikdy zaručit 100% doručení, protože to nezávisí jen na tobě, tak ti navrhne, abychom maily přesunuly na jiný mailhosting, který bude toto podporovat.
Uživatelé vidí email jako třeba takovou sms.
Faktem je, že přes maily lítají hodně důležitý věci, vyřizuje se přes ně i to, co by se nemělo, ale je to prostě tak. Buď fax, nebo mail. Faxy ustupují a zůstávají na všechno jen ty maily. Osobně raději nechám projít 20spamu/den uživateli místo toho, abych si komplikoval život a řešil případné zpožďování emailů, které nemohu moc dobře ovlivnit.
A další věc je, že takovou věc nelze ani obhájit. Proč se u nás musí emaily zpožďovat a přitom na seznamu se doručí hned? Apod. dotazy.
V tomto jsem skeptický.
Zdar Max

[pavlix]

Uživatelé vidí email jako třeba takovou sms.

A že už mi těch sms taky pár nedošlo, zvlášť na roamingu.

protože to nezávisí jen na tobě, tak ti navrhne, abychom maily přesunuly na jiný mailhosting, který bude toto podporovat.

Tak mu zajistím přesun na jiný mailhosting a pošlu fakturu za zajištění přesunu :). Neumím si představit, že bych mailhosting provozoval jako výdělečnou službu.

A další věc je, že takovou věc nelze ani obhájit. Proč se u nás musí emaily zpožďovat a přitom na seznamu se doručí hned?

I to lze řešit i obhájit. Já jsem ještě nikdy nikomu greylisting nenutil, ale několikrát jsem no nasazoval po vysvětlení možností a umožnění výběru.

[Luk]

I to lze řešit i obhájit. Já jsem ještě nikdy nikomu greylisting nenutil, ale několikrát jsem no nasazoval po vysvětlení možností a umožnění výběru.

Optimální je greylisting nasadit a umožnit každému uživateli, aby si vybral, jestli ho bude používat.

[pavlix]

Pokud to není firemní mailserver s jednotnou politikou, že.

[Luk]

Uživatelé vidí email jako třeba takovou sms.

Zrovna SMS někdy chodí až za několik hodin, případně vůbec.

[asfethan]

Ahoj, bohužel klienti mají jiný názor. Obyčejný uživatel si myslí, že email je něco jako pošta s tím, že když si zaškrtne potvrzení o doručení, tak je to něco jako doporučený dopis s tím, že adresát to musí mít u sebe do 5min.

To by ma zaujimalo odkial mate takyto skresleny nazor. Velka cast aj mladych ludi ma schranku na roznych tunajsich freemailoch ktore ani zdaleka nedosahuju kvality sluzieb napr. gmailu. Maily bezne prichadzaju s 5-30min oneskorenim a to je este lepsi pripad.

Tiez sa mi castokrat stalo ze som si nechal vygenerovat automaticky mail (odoslany ihned) a kym dorazil ubehla taktiez nejaka doba. A to siel na moj server vtedy este bez greylistingu. Tym chcem povedat ze oneskorenie sa neda predvidat a nemusi byt nutne sposobene len GL alebo inym overovanim.

Když klientovi začneš vysvětlovat, že nemůžeš nikdy zaručit 100% doručení, protože to nezávisí jen na tobě, tak ti navrhne, abychom maily přesunuly na jiný mailhosting, který bude toto podporovat.

Ukazte prstom kto na svete dokaze zarucit 100% dorucenie akehokolvek mailu!!!

Uživatelé vidí email jako třeba takovou sms.

Potom je chyba prevadzkovatela ze uzivatelom neposkytol spravnu osvetu a neoboznamil ich napr. s IM a VoIP.

Faktem je, že přes maily lítají hodně důležitý věci, vyřizuje se přes ně i to, co by se nemělo, ale je to prostě tak. Buď fax, nebo mail. Faxy ustupují a zůstávají na všechno jen ty maily. Osobně raději nechám projít 20spamu/den uživateli místo toho, abych si komplikoval život a řešil případné zpožďování emailů, které nemohu moc dobře ovlivnit.

Ako som uz pisal, prvy uspesne overeny mail otvara "vrata". A potom uz zavisi len od nastavenia GL a frekvencie komunikacie ci skoncite aj na whiteliste. A pokial to potrebujete mat IHNED tak pouzite kua Instant Messaging!!!

A další věc je, že takovou věc nelze ani obhájit. Proč se u nás musí emaily zpožďovat a přitom na seznamu se doručí hned? Apod. dotazy.
V tomto jsem skeptický.

A preco dobry mail skoncil medzi spamom (content filtering)?
A preco mi mail nebol vobec doruceny? (nevhodny zdroj RBL, alebo nejaky omyl v db RBL)
A preco mi mail nebol vobec doruceny? (blbo nakonfigurovany server odosielatela ktory neprejde ani zakladnymi overeniami)

Odpoved je jednoducha na vsetky otazky tykajuce sa takychto opatreni... Niektori ludia su svine bez chrbtovej kosti a preto musime riesit SPAM.

Netvrdim ze greylisting je idealne riesenie pre kazdeho, to vobec nie. Ale v mojom pripade sa zredukovalo mnozstvo spamu o 99%. Cize zatial vysoka spokojnost. A pokial mate klientov ktori poznaju rozdiel medzi IM a Mailom tak si myslim ze GL a jeho prinos uvitaju.

[Heron]

Už to napsali +- ostatní. Emaily mají zpozdění, či zůstávají nedoručeny zcela běžně i na tom seznamu. To nebyl dobrý příklad. Pokud na tom trvají, tak jim ty emaily můžeš dát na seznam a ukázat jim ty případy, kdy lidé a firmy přišli na seznamu o veškerou poštu. To by je možná vrátilo zpět na zem.

tak ti navrhne, abychom maily přesunuly na jiný mailhosting, který bude toto podporovat

No výborně. Tak ať klient vybere hosting, který tohle podporuje .

Uživatelé vidí email jako třeba takovou sms.

Z vlastní zkušenosti musím říct, že SMS jsou možná ještě méně spolehlivé než emaily.

A další věc je, že takovou věc nelze ani obhájit.

Já bych to vůbec neobhajoval. To co potřebují, na emailech prostě nelze dosáhnout a neumí to nikdo na světě. Pro dané potřeby zaručeného doručení v pořadí s určitým zabezpečením se emailový systém vůbec nehodí a nebyl na to navržen.

[SPM]

Jsem skutečně rád, že v této diskusi nejsem první, kdo tohle napsal . Minule to mělo poněkud neblahé konsekvence.

U toho jsem naštěstí nebyl :)

Hmm, něco podobného zde uvedlo více lidí, což je poněkud zvláštní vzhledem k tomu, že u emailu není vůbec zaručeno jeho doručení (dnes je spíše zázrak, že nějaký email přes tyhle konstrukce projde), natož pak jeho doručení v nějaké garantované době. Osobně email považuji za komunikaci, kde je na reakci několik dnů čas a nějaká ta minuta nehraje roli.

Tim že není zaručeno, že dojde, ještě neznamená, že mu budu házet další klacky pod nohy aby tim spíš nedošel... druhej důvod je ten, že o některém mailu typicky vím, že má dojít a tu informaci v něm potřebuju typicky co nejrychleji... ale takhle si počkám, než se to pošle podruhé... no a dalším důvodem může být to, kde do toho zasahuje více lidí - už jsem takhle jednou byl za kreténa. Jedna společná schránka (mohl by být i mailing list) a moje odpověď spadla do GL. Mezitím odpověděl někdo jiný, vyměnilo se 10 mailů a po 10 mailech došel konečně ten můj...

A nebo prostě přes normální mail servery, což už se částečně děje.

Nebo tak... ať se na to dívám jak chci, tak mi to připadá, že je to technologie, která víc problémů způsobí než vyřeší :)

[asfethan]

potřebuju typicky co nejrychleji...

viete ze existuju rozne IM protokoly a siete (napriklad jabber)? alebo dokonca VoIP?

Tim že není zaručeno, že dojde, ještě neznamená, že mu budu házet další klacky pod nohy aby tim spíš nedošel...

bezvyznamny kec

kde do toho zasahuje více lidí

vyssie spominany jabber pozna aj konferencie.. a ak je to nutne riesit mailom, par minut na viac nikoho nezabije kedze podstatou mailu nie je aby fungoval ako IM

Jedna společná schránka (mohl by být i mailing list) a moje odpověď spadla do GL

GL overuje vacsinou server a jeho adresu, prva overena sprava vam automaticky zaruci priepustnost a pri dlhsej komunikacii aj pridanie na whitelist, cize toto je dalsi kec..

[Ondrej 'SanTiago' Zajicek]

viete ze existuju rozne IM protokoly a siete (napriklad jabber)?

A on existuje jediny technicky duvod, proc by IM protokoly (treba Jabber) mely dorucovat zpravy rychleji nez e-mail?

[pavlix]

Třeba protože už je navázaná komunikace a určitý vztah mezi odesilatelem a příjemcem. Není to důvod teoreticky podložený, ale ve srovnání třeba jabberu a smtp mailu to tak platí už jenom kvůli nešikovnému řešení spamu v smtp.

[Ondrej 'SanTiago' Zajicek]

Třeba protože už je navázaná komunikace a určitý vztah mezi odesilatelem a příjemcem.

To tak u unixoveho talku. Ale treba jabber technicky funguje take zcela asynchronne, vicemene stejne jako e-mail.

ale ve srovnání třeba jabberu a smtp mailu to tak platí už jenom kvůli nešikovnému řešení spamu v smtp

A on je Jabber proti spamu nejak principielne odolnejsi? AFAIK ne.

[pavlix]

Ale treba jabber technicky funguje take zcela asynchronne, vicemene stejne jako e-mail.

To ledaže by server ukončoval spojení po každém odeslání zprávy a to by byly logy daleko větší než v reálu jsou.

A on je Jabber proti spamu nejak principielne odolnejsi? AFAIK ne.

AFAIK významně. Doména je na jabberu daleko více spjata s konkrétním jabber serverem nebo konkrétními jabber servery.

[SPM]

AFAIK významně. Doména je na jabberu daleko více spjata s konkrétním jabber serverem nebo konkrétními jabber servery.

Což po pár hacknutých accountech bude v blacklistu většina existujících větších jabber serverů... :/

[pavlix]

Což po pár hacknutých accountech bude v blacklistu většina existujících větších jabber serverů... :/

Jasně, a ty největší jabber servery budou na whitelistu :).

Nicméně pokud se někdo dostane na černé listiny, bude se starat o to, aby se dostal i z nich a aby se na ně nedostal znova. Navíc půjde blacklistovat víceúrovňově. Nejdřív JID, potom doménu a potom třeba celé servery. Na mailu to nemá velký úspěch, ale jabber je přecijen jiný.

[SPM]

viete ze existuju rozne IM protokoly a siete (napriklad jabber)? alebo dokonca VoIP?

Jo, takže když se registruju někde na stránkách kde chtěj ověřit funkčnost mailu, tak mi to pošlu přes IM nebo Voip co? :) A když mi někdo volá, že mu nefunguje tohle a tohle a pošle aspoň screenshot, tak ho taky pošle přes VOIP? Přes IM asi taky ne, protože v roce 2011 stále používáme všude IPv4 s NATem a ty P2P přenosy souborů jaksi moc nefungují (nehledě na to, že tohle bych fakt nechtěl aby v IM skončilo, ačkoliv ho jinak hodně používám)

bezvyznamny kec

Jak pro koho. Vážně nevidím důvod proč bych měm maily úmyslně zdržovat nebo nedoručovat.

vyssie spominany jabber pozna aj konferencie.. a ak je to nutne riesit mailom, par minut na viac nikoho nezabije kedze podstatou mailu nie je aby fungoval ako IM

Tam nešlo o to zpoždění. Tam šlo o to, že z daných účastníků jsem do GL spadnul jenom já a vypadal jsem jako hovado, když jsem poslal odpověď na první mail v době, kdy už problém byl vyřešen.

GL overuje vacsinou server a jeho adresu, prva overena sprava vam automaticky zaruci priepustnost a pri dlhsej komunikacii aj pridanie na whitelist, cize toto je dalsi kec..

To jo, ale ve chvíli kdy ta moje první odpověď vítězoslavně došla, tak už nebylo co řešit...

[trekker.dk]

Vážně nevidím důvod proč bych měm maily úmyslně zdržovat

Tak si přečti ten blogpost: je to opatření proti spamu.

[SPM]

Jo, takže analogicky pro snížení úmrtí na dálnicích postavíme před každým nájezdem bránu a budeme pouštět auta jenom taky, aby měly od sebe rozestup 5km :) Mně osobně se prostě opatření proti spamu, které omezuje většinu i normálního provozu prostě nelíbí - a opravdu tu pak kvůli tomu musíš dělat blbce, který neví co má GL dělat? :)

[trekker.dk]

Ta analogie je úplně mimo.

[SPM]

Úplně ne... kvůli boji proti něčemu obtěžuji všechny slušné.

[asfethan]

Jo, takže když se registruju někde na stránkách kde chtěj ověřit funkčnost mailu, tak mi to pošlu přes IM nebo Voip co? :) A když mi někdo volá, že mu nefunguje tohle a tohle a pošle aspoň screenshot, tak ho taky pošle přes VOIP? Přes IM asi taky ne, protože v roce 2011 stále používáme všude IPv4 s NATem a ty P2P přenosy souborů jaksi moc nefungují (nehledě na to, že tohle bych fakt nechtěl aby v IM skončilo, ačkoliv ho jinak hodně používám)

Ked viete z akych domen ocakavate mail, dajte si ich do whitelistu. Nie je problem si spravit trebars web rozhranie k db, alebo suboru ktore bude toto vykonavat. Potom nebudete mat zdrzanie na svojej strane. Lenze realita je taka ze castokrat je napisane ze za niekolko minut vam dorazi sprava. Ono totiz niektore servery to tiez neposielaju hned

Co sa tyka IM, taku vymozenost ako proxy pre prenos suborov nepoznate? xmpp to ma vo svojej specifikacii uz velmi dlho... Staci pouzit rozum a akykolvek screenshot mate u seba hned, bez nejakeho zdrzania. A uz ked si mozete (ne)nastavit sam GL, tak si mozete sam spravit aj taketo proxy

Tam nešlo o to zpoždění. Tam šlo o to, že z daných účastníků jsem do GL spadnul jenom já a vypadal jsem jako hovado, když jsem poslal odpověď na první mail v době, kdy už problém byl vyřešen.

Tak slo ci neslo o zpozdenie? Prvou vetou vyjadrujete ze nie, nasledne komentujete ze vasa odpoved dorazila neskoro... Kto sa ma v tom vyznat? A btw stale trvam na tom ze akutne problemy sa riesia bezprostredne online. Tzn jabber/webchat supportu/irc/...

To jo, ale ve chvíli kdy ta moje první odpověď vítězoslavně došla, tak už nebylo co řešit...

Takze nakoniec islo o zpozdenie, lol...

[SPM]

Ked viete z akych domen ocakavate mail, dajte si ich do whitelistu. Nie je problem si spravit trebars web rozhranie k db, alebo suboru ktore bude toto vykonavat. Potom nebudete mat zdrzanie na svojej strane. Lenze realita je taka ze castokrat je napisane ze za niekolko minut vam dorazi sprava. Ono totiz niektore servery to tiez neposielaju hned

Nejsem si jist jestli vytvářet si stovkové seznamy whitelistů je to, co bych chtěl dělat :D

Co sa tyka IM, taku vymozenost ako proxy pre prenos suborov nepoznate? xmpp to ma vo svojej specifikacii uz velmi dlho... Staci pouzit rozum a akykolvek screenshot mate u seba hned, bez nejakeho zdrzania. A uz ked si mozete (ne)nastavit sam GL, tak si mozete sam spravit aj taketo proxy

Můžu, ale je k tomu potřeba další nastavení obou účastníků, a je to celé takové chuj... Navíc mi takhle pořád ten soubor skončí kdesi na FS a dost možná na něj zapomenu :)

Takze nakoniec islo o zpozdenie, lol...

Tak jinak - mějme jednu schránku, kam má přístup X lidí a funguje jako support něčeho. Do tý schránky chodí požadavky lidí, kteřím něco nejde a kdokoliv z těch x lidí co má zrovna čas, na ten mail odpoví (a pošle kopii třeba i zpět na sebe, aby o tom ostatní věděli). To jestli ten mail od toho, kdo ho tam posílal, přijde hned nebo za hodinu je úplně jedno, to nikomu žíly netrhá. Problém byl ten, že já jsem na ten mail odpověděl jako první, ale moje odpověď se zasekla v GL a zpět do schránky nedorazila. Takže odpověděl někdo jiný z x (který v GL neskončil) a když si ten někdo jiný s původnim pisatelem vyměnil dalších 10 mailů, tak konečně dorazila ta moje první. Takže jo - to zpoždění obecně tam problém nezpůsobuje, ale já pak takhle vypadám jako kretén co odpovídá na zodpovězené :)) Ale osobně je mi celkem jedno kdo si s mailama co dělá. Mě nikdo nepřinutí abych si to na svůj mailserver dal. Jenom jsem vyjádřil svůj názor, že to zadělává na spoustu jiných potíží a ve výsledku, až bude mít GL hodně lidí, tak to spameři jednoduše obejdou znova; tudíž mi to nepřijde jako vhodná technologie...

[trekker.dk]

ale já pak takhle vypadám jako kretén co odpovídá na zodpovězené

Jestlipak to náhodou nemáte blbě vymyšlené...

[SPM]

No, ideální to není... nicméně je to jeden z případů, kdy GL udělá slušné časové haluze...

[Heron]

To teda není moc dobrý systém. I bez GL přece jen chvíli trvá, než stihneš napsat odpovědní email a v tu dobu přece může někdo jiný ten problém začít řešit také.

Na tento typ práce se (i funkční) emailový systém vůbec nehodí. Mělo by být vždy jasně určeno, kdo daný problém řeší, pak se nemůže stát, že jej bude řešit současně více lidí.

[pavlix]

až takhle greylisting nasadí skoro všichni, tak se na to spameři připraví a budou ty maily prostě posílat 2x...

Což se týká drtivé většiny antispamových technik.

[trekker.dk]

Někteří nicméně zastávají názor, že protože by se na tu techniku spameři mohli připravit, tak je lepší ji nepoužívat vůbec, i když teď funguje. No, tím líp pro nás ostatní.

[pavlix]

No pokud by takový názor měla většina, tak můžeme s těmi stejnými technikami vydržet i desítky let.

[SPM]

Tak existujou i jiné filtrovací možnosti, které patrně vydrží déle... tim spíš mi přijde nasazování GL jako ztráta času, která navíc má vedlejší účinky...

[pavlix]

Tak existujou i jiné filtrovací možnosti, které patrně vydrží déle... tim spíš mi přijde nasazování GL jako ztráta času, která navíc má vedlejší účinky...

Každý má právo na názor.

[trekker.dk]

Přesně tak. Proto to nenasazuj, o to déle nám to bude fungovat...

[Radovan Garabík]

Odkedy som do whitelist_clients.local pridal cz a sk, s postgreyom (hlavne spomalením prijímania) prestali mať problémy aj tí najkomunikatívnejší kolegovia