Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Asi tak poslední rok, dva se na mě valí spam v češtině ve větším množství.
Jde o takové ty maily s předměty:
Mají několik vlastností:
Zatím jsem to řešil zásahem vždy v Postfixu, kdy nejdřív zabanuju jednu, dvě IP adresy a pak rovnou celý blok daného hostingu. Docela se to nastřádalo na to, že to posílá jen jeden jediný šmejd.
95.140.38.0/23 REJECT 95.140.32.0/24 REJECT 107.182.132.44 REJECT 212.129.32.0/19 REJECT 212.83.128.0/19 REJECT 212.129.0.0/19 REJECT 212.83.160.0/19 REJECT 185.80.50.0/24 REJECT 185.140.109.0/24 REJECT 185.140.111.0/24 REJECT 185.140.110.0/24 REJECT 91.236.116.38 REJECT 185.51.66.201 REJECT 185.140.108.0/24 REJECT 109.169.66.241 REJECT 173.212.224.0/24 REJECT 185.2.102.126 REJECT 81.30.158.127 REJECT 216.158.227.152/29 REJECT 174.138.190.83/25 REJECT 173.212.255.160/28 REJECT 66.45.255.214/24 REJECT 64.20.41.0/24 REJECT 66.45.252.41 REJECT 217.79.178.144 REJECT 66.45.255.208/28 REJECT 142.54.177.230 REJECT 174.138.190.0/24 REJECT 146.0.32.48 REJECT 109.169.53.97 REJECT 204.12.202.234 REJECT 67.211.219.242 REJECT 109.169.53.0/24 REJECT 142.54.177.226 REJECT 67.211.219.0/24 REJECT 142.54.177.228 REJECT 85.114.142.72 REJECT 93.186.200.55 REJECT 66.37.19.0/24 REJECT 134.255.239.0/24 REJECT
V poslední době se snažím kontaktovat hosting přes abuse kontakty, ale zjišťuju, že to je naprosto marné. Přijde maximálně automatická odpověď. Občas s linkem do ticketovacího systému, kde obvykle hned další den zjistím, že ticket rovnou zavřeli. Prostě nezájem. Náš zákazník, náš pán. Napadlo mě začít jim psát, že se ze serveru rozesílá CP, na to by možná mohli slyšet 
Ví se obecně, kdo za tím je? Máte nějaké lepší rady, jak postupovat?
Tiskni
Sdílej:
28.7.2017 11:57
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
X-Spam-Status: No, score=2.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_IMAGE_ONLY_24, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.5 HK_RANDOM_ENVFROM Envelope sender username looks random * 0.0 HK_RANDOM_FROM From username looks random * 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.7.2017 16:35
Subject: Chceš kutit? Sada nářadí MÖLLER uspokojí všechny požadavky
X-Spam-Score: 6.016
X-Spam-Status: Yes, score=6.016 tagged_above=-9999 required=6.0
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_IMAGE_ONLY_24=1.282, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.105,
RDNS_NONE=1.274, T_REMOTE_IMAGE=0.01, URIBL_BLACK=1.7,
URIBL_SBL=0.644, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Subject: NĚMECKÉ kvalitní nářadí - 188 kusová souprava v efektním kovovém kufru
X-Spam-Score: 6.006
X-Spam-Status: Yes, score=6.006 tagged_above=-9999 required=6.0
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_IMAGE_ONLY_24=1.282, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.105,
RDNS_NONE=1.274, URIBL_BLACK=1.7, URIBL_SBL=0.644, URIBL_SBL_A=0.1]
28.7.2017 13:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.7.2017 13:37
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
/etc/spamassassin/init.pre.
28.7.2017 14:25
Petr Tomášek | skóre: 39
| blog: Vejšplechty
28.7.2017 15:24
otasomil | skóre: 39
| blog: puppylinux
Zdravim
Mam dve domeny, nastaveny domenovy kos a zadny spam. Taky mam jeste adresu na Seznamu a taky nic.
Tak teda nevim...
Tyhle rozsahy nepoznávám, ale zase mám jiné. :-)
Svého času mi dost pila krev jakási "Firma 2.0 s.r.o." nějakého Davida Kirše. Ti rozesílali těžko autodetekovaný spam z domén jako
sekuq7.cz sedoa9.cz sew7dr.cz sew4sw.cz sen6te.cz sewra5.cz sew6ra.cz smarta5a7.eu smarth5h6.cz
Poslední dobou je zase hodně aktivní spammer mailforce.cz, ale ti se naštěstí tolik nestěhují. První taková vlna sofistikovaných spamů byla z domén typu
slevimti.cz slevy247.cz slevy27.cz vas-slevicek.cz slevmeto24.cz slevy-vsude.cz ... kupomania.eu miluj-nakupy.cz chci-nakupovat.eu nejlepsi-nakupy.eu miluju-nakupovani.eu nakupuj-online.eu nejnakupak.cz nakupcik.cz
Z těch jsem byl tenkrát docela zoufalý, protože každé 2-3 dny přidávali novou doménu. Nakonec pomohlo identifikovat jejich rozsahy u hostingů (používali asi tři) a blokovat to natvrdo podle nich už na úrovni netfilteru.
28.7.2017 18:36
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
https://www.youtube.com/watch?v=pJcz2KidgoE
28.7.2017 18:27
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
Jakkoli je takové jednání určitě nemorální a dost možná i nelegální, podvod jako takový by na to asi napasovat šlo dost těžko, protože příslušný paragraf začíná slovy
Kdo sebe nebo jiného obohatí tím, že…
To obohacení tu při nejlepší vůli nevidím.
28.7.2017 19:09
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
28.7.2017 19:57
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
30.7.2017 16:39
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
28.7.2017 18:48
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
4.8.2017 13:21
<a href=3D"http://bcz14.imadetoast.com/"><img src=3D"http://img.imadetoast.com/00bcz14.jpg" /></a> tedy obrázek z kódem 00xxxnn.jpg a odkazovaný server s adresou xxxnn.doména a několikrát. Zatím to mají všechny maily. Víš jak to zformalizovat?
29.7.2017 21:51
Agent
| blog: Life_in_Pieces
| HC city
29.7.2017 21:55
Agent
| blog: Life_in_Pieces
| HC city
30.7.2017 16:35
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
Dnešní standard je SPF+DKIM+DMARC+ADSPTak tohle tvrzení mi přijde poměrně odvážné.
U nás mám nasazeno vše a zatím to je udržitelné, ale pravdou je, že občas o vypnutí greylistingu přemýšlím. Zatím dle dostupných stats se ještě vyplatí.Automatický whitelisting + výjimky na velké poskytovatele (mají sice hromadu serverů, ale taky dobře nastavené DNS, podle čehož je lze poznat) a v podstatě není problém.
Ono je úplně jedno, na jaký whitelist se velcí poskytovatelé dávají.Tak to je pěkná pitomost. Pokud mám whitelist k nějaké funkcionalitě, tak umístěním subjektu na ten konkrétní nedávám najevo nic jiného, než že pro dané subjekty není potřeba danou funkcionalitu aplikovat. Greylisting nedělá nic jiného, než že ověřuje, že odesílatelem zprávy je funkční mailserver, který se opakovaně pokusí o doručení. U velkých poskytovatelů je toto splněno a greylisting na ně tedy není potřeba aplikovat, protože zbytečně zpožďuje zprávu. Plus, jak je napsáno výše, opakované doručení může přijít z jiného serveru. Ve zkratce u takto velkých poskytovatelů greylisting otravuje život uživatelům a pokud od nich jde spam, tak mi nakonec přijde. Proto není potřeba dělat greylisting. Pro ostatní stačí automatický whitelisting pro IP adresy, které greylistingem úspěšně prošly - to se vztahuje na ty malé poskytovatele, kteří žádnou SMTP farmu s balancingem jednotlivých zpráv neprovozují. Takže příště než začnete mektat něco o podřezávání větví, tak si o tématu něco nastudujte. Pořádně si přečíst vlákno, na které reagujete, taky pomáhá.
Takže příště než začnete mektat něco o podřezávání větví, tak si o tématu něco nastudujte. Pořádně si přečíst vlákno, na které reagujete, taky pomáhá.No, zatím to vypadá, že toho o tématu pořád vím víc, než vy. Nejen, že vím stejně jako vy, jak greylisting funguje, ale na rozdíl od vás si také uvědomuji, že nasazení whitelistu není zadarmo, že tedy asi má předcházet nějakým problémům, a že tedy nasazením whitelistu děláte ze serverů, které na tom whitelistu nejsou, a hlavně z jejich uživatelů, servery/uživatele druhé kategorie, u kterých případné problémy nevadí tolik, jako u serverů/uživatelů, které jsou ručně přidané na whitelist.
Malý má v případě greylistingu výhodu, protože má většinou jeden serverJenže vy na ten whitelist nedáváte všechny poskytovatele, kteří mají více odchozích IP adres, dáváte tam jen známé velké poskytovatele.
A v tomto případě pak greylisting plní fci, kterou od něj nechceme.Plní funkci, kterou od něj nechceme, ale pro kterou jsme si ho nakonfigurovali… Když si ho nakonfigurujete tak, aby e-maily identifikoval podle trojice odesílatel, adresa odesílatele, adresa příjemce, bude zpoždění také jen pár minut (přičemž „odesílatel“ znamená odesílající systém, poznáte ho třeba třeba podle DKIM). Že v graylistu používáte zrovna IP adresu, přičemž nikde není řečeno, že se má o opakované doručení pokoušet zrovna ta samá IP adresa, je váš problém.
Taktéž bych si nebyl tolik jistý v tom, že bych měl něčemu věřit na 100%.Což ale znamená, že o e-maily od těch menších poskytovatelů nestojíte tolik, jako o e-maily od těch velkých. To je samozřejmě legitimní postoj, akorát úplně nechápu ten způsob uvažování, kdy někdo ostatním malým provozovatelům říká „o vaše e-maily tolik nestojíme, pokud chcete, abychom je začali brát vážněji, přejděte ke Googlu nebo Microsoftu“ – a zároveň provozuje svůj malý server, místo aby přešel ke Googlu nebo Microsoftu.
Aby fungovalo DKIM, tak nejen, že to musíš mít nastaveno na serveru, ale musíš mít i záznam v DNS.Já jsme ale nepsal nic o fungování DKIM nebo jeho validaci. Psal jsem o tom, že podle DKIM můžete poznat systém odesílatele. Když má v DKIM hlavičce
30.7.2017 14:53
1.8.2017 00:58
d=gmail.com, odesílá to asi systém GMailu, a když příště přijde požadavek na doručení e-mailu od stejného odesílatele pro stejného adresáta, z jiné IP adresy, ale pořád bude mít d=gmail.com, je to nejspíš pořád stejný odesílající systém. Teď vám ten e-mail prošel greylistem, a teprve teď můžete dělat validaci DKIM a další kontroly, a pokud e-mail projde, přidat automaticky odchozí IP adresy na whitelist.
neříkal nám stále dokola, jak jsme hloupýTo jsme napsal kde?
neříkal nám stále dokola, jak znevýhodňujeme malé poskytovateleProč bych to nemohl říkat, když je to pravda?
i když nevím, jak by tím měl být ten malý poskytovatel znevýhodňovánTak proč velké poskytovatele na ten whitelist dáváte, když v tom podle vás není žádná výhoda?
právě on má u greylistingu oproti velkým poskytovatelům výhoduVýhodu nemá žádnou. Pouze vy máte problém, když máte greylist postavený výhradně na IP adresách, pokud někdo opakované doručování e-mailu dělá z jiné IP adresy. Což není výsada velkých poskytovatelů, to způsobí klidně i to, že se jednou použije IPv4 a podruhé IPv6. Ale hlavně pochybuju o tom, že má někdo na whitelistu všechny poskytovatele, kteří používají cloud nebo cluster. Spíš tam má pár největších, a pak je hromada menších, kteří e-maily klidně rozesílají z více serverů, ale na typických whitelistech nejsou – třeba český Seznam v zahraničí. Nejde o znevýhodňování malých, ale o znevýhodňování všech, kteří nepatří mezi těch pár největších.
já tedy nedávám v případě greylistingu do whitelistu velké poskytovatele, ale přemýšlím, že tam ten cloud od MS nakonec dámA teď si představte, že takhle přemýšlejí i ostatní. Jaký to má smysl provozovat vlastní řešení, když vás lidé, kteří uvažují jako vy, tlačí k tomu, abyste použil GMail nebo Outlook?
K čemu je dobrý dělat validaci na základně takového neověřeného/smyšleného záznamu?Netuším, k čemu je to dobré. On někdo psal, že je to dobré? Když jsme nepsal o validaci, pak jsem znovu explicitně napsal, že nepíšu o validaci, myslel jsem tím, že nepíšu o validaci. Napsal jsem, že ten neověřený text použiju jako klíč pro greylisting. Myslíte, že spameři používají k rozesílání e-mailů cloud stejným způsobem, jako GMail nebo Outlook? Že se pokusí odeslat e-mail, a když se jim vrátí měkká chyba, uloží si ho a později to zkusí odeslat jiný uzel cloudu? Já všude čtu, jak je greylisting výborný, protože spameři se nepokouší e-mail doručovat opakovaně.
a když příště přijde požadavek na doručení e-mailu od stejného odesílatele pro stejného adresáta, z jiné IP adresy, ale pořád bude mít d=gmail.com, je to nejspíš pořád stejný odesílající systémNebo je to jiný odesílací systém patřící spamerovi a greylistingem prošel, i když by neměl, protože hlavička je zfalšovaná. Čímž se vracíme k tomu, abyste si o tématu nejdřív něco nastudoval.
Je vtipné, že jste svůj komentář omylem vložil jako reakci na můj komentář, kde jsem zrovna tohle vysvětloval.Akorát jste to vysvětlení omylem zapomněl odeslat, holt stane se.
Což se ve vámi uváděném případě stalo.Zkusíme to ještě jednou, možná vám to dojde, když se budete hodně snažit. 1. Google odešle mail, který má odesílatele, příjemce a d=gmail - greylisting odmítne. 2. Spammer odešle mail, který má stejného odesílatele, stejného příjemce a také stejné d=gmail - greylisting přijme. Zpráva v bodě (2) není stejná zpráva jako v bodě (1), odesílatel není stejný a ani odesílací systém není stejný. Tohle je pro vás zřejmě těžko pochopitelné, takže extra pro vás to ilustruji velmi dopodrobna: v bodě (1) je odesílacím systémem infrastruktura Google, v bodě (2) není odesílacím systémem infrastruktura Google. Tudíž mnou popisovaný případ není situace, kdy se odesílatel pokouší doručit e-mail podruhé, a greylistingem tedy projít nemá.
Napsal jsem, že spousta lidí nepoužívá DKIM, takže z cloudu přijde email s DKIM podpisem, který neověříš, neb to konkrétní admin nehodil do dns.Myslíte, že je to častý případ, že si někdo nechá vygenerovat klíče pro DKIM, ale už je nenastaví do DNS? Nebo nějaký cloud podepisuje e-maily DKIM „preventivně“ klíčem, který zákazníkovi vytvoří automaticky?
Jenomže pokud si greylisting pomocí autowhitelistu vloží do své db kombinaci odesílatel+adresát+dkimNikoli, kombinace odesílatel+adresát+dkim se vkládá do greylistu a vydrží tam do té doby, dokud nevyprší timeout nebo dokud nedojde k úspěšnému doručení e-mailu. Jakmile dojde k úspěšnému doručení e-mailu, je zbytečné ten záznam dál držet v greylistu. Na autowhitelist se dostane (po případných dalších kontrolách) IP adresa odesílajícího serveru.
tak musíš mít lifetime takového záznamu né třeba 60dní, ale spíše tak den, protože pak by nebyl problém se trefit do této kombinace spammeremPro spammera by to byl dost velký problém. Musel by trefit odesílatele, jehož doména nepodepisuje DKIM, a zároveň takového, který je zrovna na greylistu.
provider generuje klíč a nutí uživatele, aby si ho nastaviliMůžete uvést příklad takového providera? Hodí se to vědět kvůli testování.
Dále těch největších cloudů moc neníNo právě. Největších. Všichni přesuneme poštu do největších cloudů, protože e-maily odjinud nikoho nezajímají…
A v poslední řadě, greylist je označován většinou seznam trojkombinací (ip serveru+odesílatel+adresát), nichž se zatím neověřilo správnost serveru(maily jsou zatímv šedé zóně), auto-whitelist je whitelist v rámci greylist db. Když tedy greylist provede auto-whitelist, tak je to whitelist v rámci greylistu. Tento whitelist má pak nějaký lifetime. A je to samozřejmě i logické, do jakého jiného whitelistu by jsi chtěl takový mail dávat, snad né do antispamového :).Greylist je seznam údajů, které mají identifikovat e-mail, který už se odesílatel pokoušel doručit, ale byl odmítnut s měkkou chybou. Když se odesílatel pokusí e-mail odeslat znovu a najde se příslušný záznam v greylistu, doručování e-mailu postoupí do dalšího kroku a záznam z greylistu se smaže. Protože greylist není úplně fér ani levná technika, dává se před něj whitelist – tj. když je odesílatel na whitelistu, nemusí do greylistu a rovnou postoupí do dalšího kola. Obvyklé je to, že pokud odesílatel jednou úspěšně projde greylistem, zařadí se na whitelist. Na witelistu ale nemusí být stejné údaje, jaké jsou na greylistu, není k tomu žádný důvod – a nevím o tom, že by to v praxi někdo dělal. Na whitelist se většinou dává IP adresa nebo celý blok, protože je velice rychlé to vyhodnotit. Vy znáte nějaký případ, kdy někdo na greylist dává triplet IP+odesílatel+adresát, a na whitelist pak dává ten samý triplet?
Nejedná se o žádné hypotetické argumentace.Tohle tvrzení by bylo dobré podložit třeba odpovědí na otázku z #86, jestli vůbec nějaký větší mailserver provozujete.
Vámi popisovaný případ je velmi nepravděpodobný – že by GMail odeslal e-mail, vy ho odmítnete kvůli greylistu, a než ho GMail zkusí odeslat podruhé, nějaký spamer si náhodně vylosuje stejnou kombinaci odesílatele a adresáta, a stihne e-mail odeslat dřív, než to GMail zkusí podruhé. Jak je to asi pravděpodobné?a) na "nepravděpodobné případy" si někde hrajete i v praxi, nebo je to jenom další teorie? b) spammer to nemusí stihnout dřív, dále příspěvek #81
No, a pak tu máme tu nemilou věc, že jste na sebe nechtěně prozradil, že vůbec nechápete, jak funguje DKIM.Ale ano, to chápu dobře. Ono je to trochu jinak, já vám to zkusím rozdělit do bodů, aby se vám snadněji chápalo, kde jste udělal chybu 1. Jirsákův greylisting dle #67 použije neověřenou informaci v hlavičce jako identifikátor systému, který odeslal mail 2. Já poukážu na slabinu tohoto řešení, které umožňuje vydávat se za cizí systém 3. Vy si z toho nějakým způsobem odvodíte, že předpokládám, že spammer vyprodukuje platný DKIM podpis. To jsem ale nikde nenapsal a není to vyžadováno, protože Jirsákův greylisting ten podpis použije před ověřením Pokud nedokážete udržet pozornost, zkuste si přečíst pár příspěvků zpátky, třeba vám to pomůže.
na "nepravděpodobné případy" si někde hrajete i v praxi, nebo je to jenom další teorie?Vážně byste si měl nejdříve nastudovat, o čem se tu bavíme. Řešíme tu greylisting, který má tu funkci, že má odfiltrovat e-maily od systémů, které se ani nepokusí doručit e-mail opakovaně. Co se stane, když takovým filtrem projde jeden e-mail navíc jednou za padesát let? Vůbec nic, přes greylist prochází spam běžně a odfiltrují ho následné kontroly. Vážný problém nastává v opačném případě, když přes greylist neprojde ani regulérní e-mail.
spammer to nemusí stihnout dřív, dále příspěvek #81Jak dlouho držíte triplet v greylistu? A proč tam ten triplet držíte i po úspěšném doručení e-mailu? Aby byl doručen rychleji následující e-mail, pokud bude stejný odesílatel posílat stejnému adresátovi? Není lepší po úspěšné verifikaci dát na automatický whitelist IP adresu odesílatele? Nebo čekáte, že jeden server se bude pro jednu dvojici odesílatel–adresát chovat správně, ale pro jinou takovou dvojici se nepokusí e-mail doručit opakovaně?
Jirsákův greylisting dle #67 použije neověřenou informaci v hlavičce jako identifikátor systému, který odeslal mailZa prvé, je jenom na vás, zda si tu informaci v hlavičce ověříte nebo neověříte. Jinak je od vás hezké, že potřebujete i pro greylisting mít DKIM ověřený, ale vůbec vám nevadí, že odmítáte e-maily, aniž byste si ověřil, zda už se je stejný systém nepokusil odeslat dříve.
Já poukážu na slabinu tohoto řešení, které umožňuje vydávat se za cizí systémA já jsem odpověděl, že i když ten podpis při greylistingu ověřovat nebudete, vůbec ničemu to nevadí, protože tím spammer nezíská žádnou výhodu.
Vy si z toho nějakým způsobem odvodíte, že předpokládám, že spammer vyprodukuje platný DKIM podpis. To jsem ale nikde nenapsal a není to vyžadováno, protože Jirsákův greylisting ten podpis použije před ověřenímJestli ten podpis využijete před ověřením nebo až po ověření závisí jenom na vás.
Škoda, že jsi to nenapsal hned od počátku místo hádání se šedá/bílá.Já jsem s hádáním se šedá/bílá nezačal. Když s tím začne trekker.dk, tváří se u toho jak mistr světa a trousí kolem sebe moudra, že si to mají ostatní nastudovat, přitom v tom plave sám, nemám důvod mu to podrobně vysvětlovat.
Ty to takto provozuješ? Můžeš tedy něco doporučit?Já greylist neprovozuju, protože si myslím, že provozovat ho pořádně je náročné a nestojí to za tu námahu. Pokud si s tím nějaký spammer dá práci, prostřelí greylist snadno, často snáz, než legitimní server (prostě pošle e-mail dvakrát ze stejného stroje). A pokud se na to spammer vykašle a prostě jede na co největší objem odeslaných e-mailů, většinou nebývá problém takové e-maily identifikovat i jinak. A provozovat greylist blbě nechci, protože jsem stará škola a myslím si, že poštovní server se má maximálně snažit e-mail doručit, ne udělat všechno pro to, aby se e-mail nedoručil.
ještě se musím podívat na pár mailů z cloudů, jak vypadají jejich hlavičky, když skáčou po serverech ...Překvapilo by mne, kdyby měly e-maily z jednoho cloudu různé
d tagy. Pak by museli klientům říkat „vy si nastavte a.gmail.com, vy si nastavte b.gmail.com“, při odesílání by museli rozhodovat, kterým klíčem to podepsat… Byla by s tím spousta komplikací a užitek žádný. Navíc k takovémuhle rozlišení slouží tag s.
že si to mají ostatní nastudovatZase jste špatně četl. Ostatní ne, jenom vy.
Poslední dobou je to hodně otravné. Ani bych se nedivil, kdyby někdo přešel do protiútoku – ať už fyzického nebo na síti. Pro začátek by mohl třeba zadávat falešné objednávky…
rawbody CZECH_SPAM3_OB /\.com\/ob\.php\?/ score CZECH_SPAM3_OB 0 2.0 0 2.0 rawbody CZECH_SPAM3_UB /\.com\/ub\.php\?/ score CZECH_SPAM3_UB 0 2.0 0 2.0Krome velikost kolem 5 kB je tenhle regex jeden z mala spolecnych znaku - vsechno odkazuje na
.com domenu.
Neni to optimalni, ale funguje to na 100%, zadny false positive jsem zatim nezaznamenal...
Jinak jeste zkousim bokem Rspamd, ten to zatim blokuje vicemene vsechno na zaklade ruznych blacklistu:
metric: default: [15.549 / 15.000], symbols: URIBL_SBL(6.50)[cjcarib.com], BAYES_SPAM(4.00)[100.00%], RBL_SENDERSCORE(2.00)[55.239.255.134.bl.score.senderscore.com], HTML_SHORT_LINK_IMG_1(2.00)[], DMARC_POLICY_ALLOW(-0.25)[cjcarib.com, none], FROM_EXCESS_QP(1.20)[], ONCE_RECEIVED(0.10)[], RCVD_COUNT_ONE(0.00)[1], HAS_REPLYTO(0.00)[alojzbsn3fkm@cjcarib.com], R_DKIM_ALLOW(-0.20)[cjcarib.com], MID_RHS_MATCH_FROM(0.00)[], MIME_HTML_ONLY(0.20)[], ARC_NA(0.00)[], TO_DN_NONE(0.00)[], PRECEDENCE_BULK(0.00)[], ASN(0.00)[asn:197071, ipnet:134.255.224.0/20, country:DE], FROM_EQ_ENVFROM(0.00)[], R_SPF_NA(0.00)[], RCVD_TLS_ALL(0.00)[], URIBL_BLOCKED(0.00)[cjcarib.com.multi.uribl.com], REPLYTO_ADDR_EQ_FROM(0.00)[], RCPT_COUNT_ONE(0.00)[1], TO_MATCH_ENVRCPT_ALL(0.00)[], FROM_HAS_DN(0.00)[]
A i tak jsme se dostali na blacklistA byl to b.barracudacentral.org?
2.8.2017 23:32
