Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message. As with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review of the message and response and appropriate intervention.RFC 5321
E-mail má buď dorazit nebo se vrátit (být odmítnut ještě v rámci SMTP relace v odpovědi na RCPT TO nebo DATA …). Cokoli jiného je špatné řešení.Nevim, proč je to zrovna jako reakce na můj příspěvek...
Největší svinstvo je, když e-mail prostě jen tak zmizíObčas to je vcelku rozumné řešení - třeba když se jedná o poštu velký organizace a ten samej mail (spam) postupně přijde tisíckrát.
jenže pak je můžeš odmítat, není potřeba je v tichosti zahazovat, ne?... to by ale znamenalo pouštět spamfiltr ještě během SMTP relace, což nemusí být úplně žádoucí.
Když se tedy spustí ještě v rámci SMTP relace, můžou se sice e-maily odbavovat pomaleji (ve špičce), ale zase se neztratí žádný e-mail.... což znamená spoléhat se na to, že protistrana udělá správnou věc. Tj. že mi ten mail zkusí poslat znova a v dohledné době. Tak to rozhodně není pravidlem, jsou experti, co to zkusí za minutu a pak druhý den v půl šesté ráno. Popřípadě po prvním neúspěšném pokusu okamžitě odesílají zprávu o zpožděném doručení. Nebo dočasnou chybu rovnou vyhodnotí jako trvalou. Proto nevidím problém v tom zprávu, která vypadá, že to nebude spam (např. odesílatel není v blacklistech), přijmout a náročné věci řešit až následně.
bavíme se o případu organizace, ve které někdo zkontroloval mail, ví že jde o spamPokud to někdo ručně zkontroloval a jde evidentně o spam, tak budiž. Ale i tak mi přijde lepší e-mail odmítat, než zahazovat – při odmítnutí je nějaká šance, že tě spamer vyřadí ze svého seznamu, při zahazování je pravděpodobnější, že tě bude spamovat i příště.
což znamená spoléhat se na to, že protistrana udělá správnou věc.Je to úplně stejné jako u greylistingu, který se hojně používá. Přiznám se, že greylisting taky nemám moc rád, právě kvůli zpožďování e-mailů. Ale výše popsané řešení se celkem podstatně liší: nezpožďuje všechny e-maily z dosud neznámých domén/adres, ale jen ty, které dorazí při přetížení serveru (které by běžně nemělo nastávat).
telnet mail.nekde.cz 25 Trying 2a01:123:45:0:1::32... Connected to mail.nekde.cz Escape character is '^]'. 220 mail.nekde.cz ESMTP Postfix helo aa.bb.cz 250 mail.nekde.cz mail from: aa@bb.cz 250 2.1.0 Ok rcpt to: aa@jaros.org 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> Test . 550 Polib si se SPAMEM pozadi quit 221 2.0.0 Bye Connection closed by foreign host.
Ještě jednou: bavíme se o případu organizace, ve které někdo zkontroloval mail, ví že jde o spam a přichází to ve stovkách na různé adresy ve firmě.Prvotní kontrola ruční, posléze se maily se stejným obsahem odmítají/zahazují automaticky. Alespoň takto jsem pochopil zadání já. Představa, že by měla organizace extra člověka, který by prohlédl každý mail a rozhodl jestli jde o SPAM nebo ne, mi přišla natolik absurdní, že jsem o ní vůbec neuvažoval...
SPAMy se nam vesele mení, obsahují části které jsou nahodně generovanéTak ještě jednou a doufám, že tentokrát už to bude stačit, protože bych nerad maloval obrázky: v tomto konkrétním případě se jednalo o spam, který postupně přicházel ve stovkách stejných exemplářů. Už je to jasné? A můj server to nebyl.
Zeptam se někde se staráte o mail server, kde je aspon pár set uživatelů a dostanete denně několik tisíc mailůNaše mailservery nejsou případ uvedený v #42 (schránky nepatří zaměstnancům), takže se nás tam popsané řešení netýká.
a navíc to nijak netlačí na nápravuKdežto když nechám uživatelům chodit zavirované maily a milášek zákazníky, tak něčemu pomůžu...
Tvůj náhled na funkčnost a spolehlivost e-mailového ekosystému není moc praktickýMně přijde na dnešní zvyklosti až krutě moc praktický.
v podstatě říkáš, že všechno by měl být buď spam, nebo to má uživateli dorazit do schránkyJá bych to četl spíše takto, bez té škrtnuté části.jako čistý mail.
Jenže vzhledem k tomu, že kontroly dělají automtizované nástroje, nějaká šedá zóna (tohle teda přijmu, ale uživateli to do schránky dám tak, aby viděl, že je to pozdezřelé) existovat musí.Jakože budu uživateli schovávat netriviální množství legitimních mailů? To jde, ale taky to trochu skřípe, takže bych to rozhodně neprezentoval jako jediné a nejlepší řešení.
Kdežto když nechám uživatelům chodit zavirované maily a milášek zákazníky, tak něčemu pomůžu...Vtipné je, že současné praktické mailové standardy (tedy to, co se opravdu většinově používá), jsou úplně postavené na hlavu. Jako workaround se používají doplňkové způsoby komunikace, třeba telefon. Tady je hodně velký rozdíl mezi teorií a praxí ve prospěch teorie (víceméně se ví, jak to dělat správně, ale nikdo to nedělá a z důvodu vzájemné kompatibility to ani nikdo dělat nemůže).
Já bych to četl spíše takto, bez té škrtnuté části.Koš je taky ve schránce uživatele, což se ale předřečnkovi zjevně nelíbilo.
Jakože budu uživateli schovávat netriviální množství legitimních mailů?Jestli přesunutí do složky "spam" považuješ za "schovávání", ok. Nicméně většina uživatelů klinutí myší zvládá...
Jako workaround se používají doplňkové způsoby komunikace, třeba telefon.... prostě takové způsoby, které (v podstatě) netrpí spamem.
Tiskni
Sdílej: