Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Bylo vydáno Ubuntu 24.04.5 LTS, tj. páté opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na poznámkách k vydání.
Švýcarsko testuje přechod z Microsoft 365 na FOSS, konkrétně balík openDesk (Wikipedie) od německé státní společnosti ZenDiS (Wikipedie), s cílem posílit digitální suverenitu.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Sice jsem před časem napsal, že spam je překonaná záležitost, nicméně tak docela to pravda není. Stále ještě přidělává dost zbytečné práce a tak se hodí každá metoda, která účinně pomůže s bojem proti němu. Jednou z takových metod je právě graylisting.
Nejedná se o žádnou novinku. Pro toho, kdo by ho neznal, nejprve vysvětlím stručný princip. Greylisting (též "graylisting", používají se obě verze podle různých dialektů angličtiny) je založen na dočasném odmítnutí "neznámé" zprávy. Pracuje se s trojicí server-odesílatel-příjemce, a pokud přijímající server tuto kombinaci dosud nezná, dočasně odepře příjem zprávy (typicky SMTP kódem 450). Po nějaké rozumné době je přijetí umožněno a trojice je dočasně přidána do databáze - po dalších přijatých zprávách pro tuto trojici se záznam stane permanentním.
Technika vychází z toho, že podle RFC 2821 by měla odesílající strana, pokud obdrží kód dočasného odmítnutí, svůj pokus zopakovat. Slušné poštovní servery tak činí, spammeři obvykle nikoliv (pokud nezneužijí "slušný server" nakonfigurovaný jako open relay). Ti většinou chrlí poštu co nejvíc příjemcům najednou, jejich SMTP klienti (běžící na různých zombie strojích nebo na počítačích s dynamicky přidělovanými adresami) často jen kulometně posílají SMTP příkazy a odpovědi vůbec nezpracovávají - a když se to nepovede doručit, prostě to neřeší a jdou o dům dál.
Greylisting je z výše uvedených důvodů velice zajímavý, současně má ale dvě nepříjemné vlastnosti. Jednou je zpoždění první zprávy pro danou trojici, které je nedeterministické a záleží na nastavení obou stran. Druhým, ještě závažnějším problémem, je nedoručení zprávy při špatně nastaveném odesílajícím serveru (tedy ale upřímně řečeno, takový server musel nastavovat pořádný diletant, protože default nastavení všech běžných SMTP serverů takovou situaci vylučuje). Kromě toho je tu ještě další menší problém, o kterém se zmíním později.
S nasazením greylistingu na poštovní server jsem dlouho váhal, a to právě kvůli oním dvěma důvodům. Ostatně tato technika ani není obecně moc rozšířená, například z velkých českých providerů ji používá pouze Contactel (dnes již součást Radiokomunikací GTS Novera). Tím spíš, že jde o věc, která se nedá nějak předem otestovat. Nicméně stále rostoucí příval spamu, v kombinaci s poměrně značnou operační náročností antispamové kontroly, vyústil v logický krok - tedy instalaci greylistingu na server.
Jedná se konkrétně o aplikaci Postgrey, která funguje jako policy server pro Postfix. Může být řízena buď přímo Postfixem (podobně jako další podřízené služby) nebo ji lze spouštět samostatně (např. "redhatovským" stylem). Komunikuje přes unixový nebo internetový socket, z čehož vyplývají i možnosti použití (např. běh na jiném stroji, než běží Postfix). Pro úplnost ještě dodám, že se jedná o program napsaný v Perlu.
Dosavadní zkušenosti po několikatýdenním provozu jsou výborné. Víc než 95 % spamu je úspěšně odmítnuto, z přímo příchozího skoro 100 %. Problémy činí zprávy přeposílané odjinud, zejména z konferencí (např. LKML). Tam tato technika z pochopitelných důvodů selhává a musí nastoupit klasické antispamové mechanismy. I v takových případech se však určitý přínos projeví, protože se odesílající stroj může v mezidobí stihnout dostat do různých blacklistů a zpráva tedy následně získá vyšší skóre.
Velice pozitivní je také fakt, že s největší pravděpodobností nebyla odmítnuta žádná regulérní zpráva. Tedy že žádný odesílající server nebyl nakonfigurován tak, aby to při prvním odmítnutí vzdal. V této souvislosti připomenu, že Postgrey má k dispozici seznam serverů, ze kterých se má pošta přijímat rovnou (známé problematické servery a také různé mailové konference). Co se týká zpoždění první zprávy (timeout je nastaven na 120 sekund), pohybovalo se od času něco přes 2 minuty až po cca 30 minut (v jednom jediném případě to bylo přes 4 hodiny), s mediánem 11 minut.
Tento text píšu hlavně proto, aby se greylisting dostal do trochu většího povědomí, a aby ti, kdo o jeho nasazení uvažují, měli určité informace z praxe. Jistým problémem samozřejmě zůstává zpoždění (přece jen minuty až desítky minut mohou být docela nepříjemné), ale v ostatních ohledech se greylisting ukazuje jako bezproblémový a momentálně je velice zajímavou antispamovou metodou. Zbývá jen doufat, že jeho větší nasazení nepovede k tomu, že spammeři začnou správně pracovat s protokolem SMTP - to by byl začátek jeho konce.
UPDATE 29.7.2006: Už ani servery bývalého Contactelu nepoužívají greylisting. Zhruba před měsícem byl nahrazen ověřováním adresy odesílatele (zpětnou SMTP relací na MX pro příslušnou doménu). Jedna kontroverzní metoda byla tedy nahrazena metodou neméně kontroverzní.
Tiskni
Sdílej:
. toto sa da riesit napr. pre greylist-milter pre sendmail directivou "subnetmatch /24" (resp. ina rozumna hodnota) alebo rucne hladat problemove servery a robit to casto
mozno to niekomu pomoze
takyto sposobom sa odosielatel nikdy nedostane do autowhitelistu greylistuDostat se tam může, ale bude to trvat dlouho. Což při dostatečně velkém clusteru a dostatečně malé frekvenci zpráv znamená, že se tam nedostane vůbec. Jinak těch clusterů zase tolik není a v distribučním souboru
postgrey_whitelist_clients už jsou ty známé obsaženy.
I když je samozřejmě pravda, že je to komplikace, která může někoho od nasazení greylistingu odradit.
Jojo, jen kdyby tech mailovych clusteru nebylo vic, nezli si myslisJenže ono jich skutečně zase tak moc není (z celkového počtu mailserverů), byť tam všechny zanesené samozřejmě nejsou.
jakakoliv vetsi infrastruktura k tomu casem nejspis taky dojde.... jeden smtp server je dost malo na globalni spolecnosti... nemyslis? ;)Nemyslím. Často se totiž objevuje opačný trend, tedy pouze jediný výstupní SMTP server a další jsou jen jako zálohy. Provoz více rovnocenných výstupních serverů nepřináší žádné výrazné výhody, nevýhod ovšem řadu. Proto i ty největší firmy volí často jiné řešení.
--lookup-by-subnet strip the last 8 bits from IP addresses (default)
Toliko pouze na doplnění k úplnosti.