Apple představil nový iPad mini, iMac s čipem M6, 14palcový MacBook Pro s čipem M6 a MacBook Pro s PROLED XDR displejem – první Mac s dotykovým ovládáním.
Nedávno představený projekt mapSTL.com řeší budoucnost. 𝕏: "Netušil jsem, kolik patentů na generování map existuje. Existují patenty na generování fantasy map 🫣. Cokoliv je na 3D tiskárnu a tvoří to produkt, bude to mít patenty. Tak bacha na to!" … více »
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.4 (𝕏). Přehled novinek a vylepšení v poznámkách k vydání.
Byla objevena zranitelnost Tailworm v Tailscale a Headscale umožňující lokální eskalaci práv přihlášeného uživatele. Následně byla v Tailscale v opravené verzi 1.104.4+ změněna architektura aplikace. Viz příspěvek na blogu Tailscale.
Byl vydán Mozilla Firefox 159.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 159 bude brzy k dispozici také na Flathubu a Snapcraftu.
Nasazení softwaru, který nyní používá ve svých autech pro čínský trh, zvažuje automobilový koncern Volkswagen také v Evropě, kde by se mohl používat v budoucích vozech značek Volkswagen, Škoda a Cupra. Základem pro budoucí evropské modely by se mohla stát takzvaná China Electronic Architecture, elektronická architektura vyvinutá pro čínské modely ve spolupráci s tamní automobilkou Xpeng.
Vedoucím brněnské pobočky Red Hatu se stal Radek Vokál [LinkedIn].
Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »I have not contacted the authorities, though maybe I should have done that.Uvazujes o bonzovani?
a pak jsou schopny identifikovat kupceA k čemu jim to je? Resp. jak mohou dokázat, že si autor nezměnil text sám? Buď má kniha DRM a pak je to jedno, nebo je to prostě jen text a ten si může modifikovat kdo chce jak chce.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V Thunderbirdu to jde dopsat ručně, ale mám pocit, že jsem to snad ještě ani jednou nepotřeboval. E-shopy jsou v pohodě s tím, když se zachová předmět (číslo objednávky) příp. message ID a From může být klidně jiná.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V NeoMutte to rieším takto:
set reverse_name = yes set use_envelope_from = yes alternates ^regex_mojich_adries$
k hledání úniků asi jako dobrý ale si myslim že uplně nejvíc spamu stejně de přímo z těch samotnejch různejch služeb kde byl mail použitej při registraci :O :/
nóó a když ty adresy boti jakoby parsujou co tam třeba jako zkusit strčit uplně nazačátek slovíčko 'noreply' třeba by takovej mail zahazovali :O :O :D ;D byl by problém s registračníma formulářema nebo to neřešej?? :O :O
Náhodné/unikátní adresy používám už dlouho, mám je třeba i na blogu nebo na stránkách svých projektů. Jinak to používám hlavně pro obchody a různé služby. Pár postřehů:
abc.iug30cs5@def.example.com nikoli jen abc.iug30cs5@example.com a asi tak jednou se mi stalo, že to neprošlo přes validaci v nějakém formuláři a jednou mi obchodník volal, že adresa je neplatná – tak jsem mu řekl, že nemůže být neplatná, kdy mi na ni od něj přišlo potvrzení objednávky. Nakonec mi tam fakturu poslal ručně a to taky prošlo.info, sales, atd.Nápad na zlepšení, který jsem zatím neimplementoval: Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru. Na to by stačilo sdílené tajemství a hash/hmac – měl bych offline aplikaci, které bych zadal vstup (název/doménu příjemce) a vrátila by mi platnou e-mailovou adresu. např. "franta.abclinuxu.cz." + hash("abclinuxu.cz", "tajemství") + "@example.com". Na poštovním serveru by bylo stejné tajemství a stejný algoritmus (jde to napsat v SQL), takže by server věděl, na jakých adresách má přijímat poštu. K tomu by byla samozřejmě černá listina adres, které sice algoritmu+tajemství odpovídají, ale přijímat na nich už nic nechceme.
Další věc je, jak tu hromadu aliasů dostat do e-mailového klienta, aby na ty zprávy člověk mohl odpovídat (u obchodů to obvykle není potřeba, ale jinak se to hodí). Tady by šlo udělat rozšíření do Dovecotu, ze kterého by si pak klient mohl přes zvláštní IMAP příkaz vytáhnout ty aliasy. U dnešních klientů je dost otravné a hloupé, že při odpovídání automaticky vyplní výchozí adresu (pokud daná adresa není nakonfigurovaná jako identita pro odesílání) a neupozorní uživatele na to, že odpovídá z jiné adresy, než na jakou zpráva přišla. Takže může dojít k nežádoucímu úniku soukromé/výchozí adresy k někomu, kdo měl znát jen tu unikátní, kterou měl přidělenou. Tohle by šlo řešit doplňkem do e-mailového klienta (provizorně je dobré si jako výchozí odesílací nastavit nefunkční adresu a účet, ze kterého nejde nic poslat).
Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru.Tomu se rika domenovy kos - mam takhle definovany email spamy@ a vsechny maily ktere prijdou na nezkonfigurovany alias skonci "v kosi". Diky tomu do formularu na internetu muzu napsat pred zavinacem cokoliv a vim ze to ve spamy@ najdu (a muzu odtud i poslat odpoved prostym prepsanim From: hlavicky (coz umi treba mutt)).
Doménový koš je něco jiného. Já chci spam1 okamžitě odmítnout ještě v rámci SMTP relace2 a ne se jím pak prohrabávat v nějakém koši.
[1] což zahrnuje i zprávy přicházející na neexistující adresy – podstata doménového koše
[2] aby odesílatel věděl, že jeho zpráva nebyla přijata – mimochodem, tohle by měl být standardní přístup – nesnáším současnou praxi, kdy někteří poskytovatelé hází náhodné e-maily do spamu nebo je rovnou mažou a odesílatel se o tom nijak nedozví – tohle ničí e-mailovou technologii jako takovou a dělá ji to nepoužitelnou
aby odesílatel věděl, že jeho zpráva nebyla přijataTo je celkem problematické. Může se stát to, že se informace o odesílateli ztratí nebo pochází z nedůvěryhodného zdroje (odesílatel, mezilehlý SMTP server, …), takže potom může být i tato odpověď nevyžádanou poštou. I jedna zpráva na schránku informovaného by mohla informujícímu způsobit škodu – například okamžité mazání budoucích zpráv od informujícího – protože informovaní mohou mít jednoho provozovatele, který by to mohl považovat za spam. Příklad: Odesílatel posílá zprávu na SMTP server A, ten ji pošle na server B a ten doručí zprávu Vám. Pokud si server A a B nemohou důvěřovat, hlavičky identifikující odesílatele (např.
From) se potom na serveru B nemohou použít pro adresování zprávy skutečnému odesílateli. Signalizace po SMTP také často není realizovatelná – spojení může být uzavřeno ještě před doručením.
.
Pro představu, jak se to provozovalo na matfyzu, kde strašně chtěli mezilehlý SMTP server: bylo několik možností, jak SMTP serveru říct, pro jaké uživatele poštu přijímáme (ručně, soubor pravidelně stahovaný přes nějaké API), a on pak pro tyto přijímal a pro ostatní odmítal.
Trochu jsem se na tohle téma rozepsal ve vedlejší diskusi: Reputační systém a vratné zálohy + anti-spam
Teraz som z toho už úplne mimo, veď VoIP by malo mať v sebe priamu funkcionalitu SMS.Má. SIP umožnuje posielať plain text správu cez MESSAGE príkaz. A ktomu špeciálne kvôli VoLTE bol vymyslený spôsob ako poslať RPDU obsah SMS správy ako binárku cez SIP MESSAGE. Oboje sa dá teda chápať ako "priama funkcionalita vo VOIP". Ibaže nič z toho nie je poskytované pre geografické/nomadické čísla na VOIP linkách v ČR. Čo sa týka funkcionalít geografických a nomadických čísel na VOIP/SIP linkách v ČR, tak tam je proste iba preklopená analógová časť na nasamplovaný zvuk v RTP zabalený do UDP paketov. A keď služby na analógovej linke behali in-band cez modem (ako FAX alebo SMS), tak patričný zvuk je rovnako prenášaný ako zvuk na VOIP/SIP linkách. Je tu ale jeden menší pokrok v oblasti FAXu cez VOIP. Na prenos FAX po VOIP existuje protokol T.38. Definuje ako zabaliť binárny FAX do UDP a teda už nepoužívať modem v hlasovej časti cez RTP. VOIP brány po ceste ho zvyknú podporovať.
Ak to teda poskytovatelia neblokujú kvôli spamerom, ale to by blokovali odosielanieJa som zatiaľ písal iba o prijímaní obsahu. Posielanie je naozaj zablokované a neposkytované z geografických a nomadických čísel asi u všetkých operátorov (analógových aj VOIP) až na výnimku, monopol O2-CZ. Tzn. funguje to iba pre analógové pevné linky, kde si užívateľ platí "vysoký tarif". Proste ak chce niekto poslať SMSku na ľubovoľné české geografické/nomadické číslo (či už zo sim karty nejakého mobilného operátora alebo cez nejakú webovú/komerčnú službu), tak SMSku normálne pošle a jeho operátor ju doručí operátorovi O2-CZ, ktorý sa ďalej postará o doručenie na konkrétne geografické/nomadické číslo jedným z tých haluzných spôsobov. A to bez ohľadu na to akého operátora má príjemca.
Tiskni
Sdílej: