Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Řešení dotazu:
ja sam jako administrator vim, z kterych systemu muzu cekat neco, co muze mit mou domenu jako senderaPři použití různých přesměrování toto nefunguje. To je přesně důvod, proč vzniklo DKIM, které funguje na kryptografickém základě a nikoliv na základě seznamu IP. Důležité je, který server mail podepsal, nikoliv který server mi ho zrovna doručuje.
Problem, ktery popisujes mel byt resen implementaci SPFSPF je systém, který trpí právě těmi problémy s přesměrováním, zatímco DKIM jimi netrpí, což je podle mě jeden z hlavních důvodů jeho existence.
DKIM v zdanem pripade neni nahrada SPFMě spíš přijde, že DKIM je validní řešení problému, zatímco SPF je od začátku z pohledu reálného mailového provozu nevhodné řešení se nepříjemnými vedlejšími efekty.
Při použití různých přesměrování toto nefunguje.Ano, to jsem zminoval minule.
To je přesně důvod, proč vzniklo DKIM, které funguje na kryptografickém základě a nikoliv na základě seznamu IP. Důležité je, který server mail podepsal, nikoliv který server mi ho zrovna doručujeNetusim, jestli tohle byl duvod, proc vznikl DKIM, u toho jsem nebyl. Kazdopadne, jak jsem psal minule, SPF se kouka na neco jineho, nez DKIM. Pokud se na to divas tak, ze je dulezite, kdo to podepsal, tak co je dulezite, kdyz to nepodepsal nikdo? Tyhle dve veci se mely doplnovat, ne nahrazovat jedna druhou. Zatimco SPF resi obalku, DKIM resi obsah. Co je mozne v te ktere "stage" je dano povahou SMTP protokolu. Neobhajuju jedno ani druhe, sam pouzivam pouze DKIM, nicmene to, co mi prijde na 25 a ma mou domenu jako sendera, rejectuju hned pred DATAma, protoze vim, ze to je jasny fejk (coz byl pripad zmineny H0axem, v pripade publikace SPF bych dal jasne najevo ostatnim, ze vsechno ode me jde pres ten dany server/servery) -- ano, nejsem korporace s 500k+ mailboxama a heterogennim prostredim ;)
SPF je systém, který trpí právě těmi problémy s přesměrováním, zatímco DKIM jimi netrpí, což je podle mě jeden z hlavních důvodů jeho existence.Ano, vim. DKIM netrpi tim stejnym, protoze "je jiny". DKIM resi integritu zpravy. Pokud je overeni OK, muzu si byt jisty, ze message je preste takova, jaka byla v momente odchodu (tedy body + ty headers, ze kterych se ta podepsana hash pocita). Naproti tomu SPF uz behem MAIL FROM muze pridat na vahu fakt, ze to prislo z mist, odkud nemelo... To, ze existuje rada sluzeb tretich stran mailujicich s danou domenou, popr. lidi forwardujici to ci o ono je fakt, reseni existuje v podobe SRS, nicmene v praxi je skoro vubec neimplementovano a tim pada cele SPF na hubu.
Mě spíš přijde, že DKIM je validní řešení problému, zatímco SPF je od začátku z pohledu reálného mailového provozu nevhodné řešení se nepříjemnými vedlejšími efekty.Muze byt, i kdyz v tomto pripade zde zadny realny problem prednesen nebyl. Jen jsem puvodne reagoval na to, ze proces overeni nebyl spravne popsan...
co mi prijde na 25 a ma mou domenu jako sendera, rejectuju hned pred DATAma, protoze vim, ze to je jasny fejkNemám problém takové pravidlo použít pro sebe, který znám důsledky.
Muze byt, i kdyz v tomto pripade zde zadny realny problem prednesen nebyl.Považoval jsem ho implicitně za zřejmý. Jedná se o možnost ověřit, zda byl e-mail odeslán pomocí k tomu určeného serveru, za pomoci údajů v DNS, a na základě této informace e-mail přijmout, odmítnout či postoupit dalším testům.
Jen jsem puvodne reagoval na to, ze proces overeni nebyl spravne popsan...Nemám pocit, že bys to nějak moc vylepšil. Původní popis byl možná nepřesný, ale tvůj komentář budí dojem, že nelze u vybraných domén odmítnout/zahodit mail na základě absence DKIM podpisu, a to by byl teprve nesmysl. Hlavní využití DKIM je takové, že u vybraných domén budou e-maily vždy správně podepsané, jinak je server má považovat za podvržené. Samozřejmě je to komplikovanější oblast, která se nedá shrnout do dvou vět a nesledoval jsem úplně aktuální vývoj.
Nemám pocit, že bys to nějak moc vylepšil. Původní popis byl možná nepřesný, ale tvůj komentář budí dojem, že nelze u vybraných domén odmítnout/zahodit mail na základě absence DKIM podpisu, a to by byl teprve nesmysl.V puvodnim popise sam xtas definuje:
ADSP nastavovat nebudu, tj bude defaultne na unknown - tedy by to nemelo nicemu uskodit, dle clanku tady: "unknown – neznámá politika, některé e-maily z domény mohou být podepsané, jiné ne. Tomu, zda jsou dopisy podepsané nebo nepodepsané, nebudeme přikládat žádnou váhu."nacez H0ax hlasi:
Pokud má doména dkim v dns a v mailu není, tak bude mail u příjemce discarded popř. se provede jiná akce nastavená na příjemcově mailserveru. Kdyby se nestalo nic, tak by byl dkim k ničemu a spamy se zfalšovanou doménou by procházely klidně dál.atd. Takze jsem vychazel z toho, ze xtas nepublikuje politiku (ADSP), mail neni podepsan. Netusim, co presne vybudilo dojem, ze neco "nelze". Lze cokoliv, otazkou zustava, jaky to ma smysl... Puvodni popis se mi zda vic nez jasny a na nej jsem taky reagoval, tedy porad trvam na tom, ze H0axuv post (vyse) neni korektni, protoze by se tak prijemce pripravil o dost velke procento legitimnich zprav, protoze pokud sender nezverejnuje svou politiku, vsechny zpravy bez DKIMu by byly pro prijemce podle H0axe "spatne", nehlede na to, ze jestli je neco ohledne DKIMu v DNS neni jak zjistit (ale to uz bylo popsano predtim). Jinak, jak je to momentalne se stavem ADSP: tady
nemuzu DKIM vubec pouzivat protoze je pro me v tu chvili nepouzitelnyZkus lepší zdůvodnění než je definice kruhem.
dkim= Outbound Signing Practices for the domain (plain-text;
REQUIRED). Possible values are as follows:
unknown The domain might sign some or all email.
http://www.rfc-editor.org/rfc/rfc5617.txt
_domainkey.domena.tld "o=~" (pripadne dalsi parametry)
bude to to co chci?
tedy:
- nepodepsany maily budou proste normalni maily jako byly doted, jakoby domena DKIM nemela
- podepsany maily budou dle selektoru overeny, a tedy bez problemu, na overeny se stejne zadna politika nevztahuje
takhle to mam na svy zkusebni domene (bez politiky) , a gmail hlasi ze je to v poradku overeny.
Takze jestli jsem to spravne pochopil server by mel verejny klic (nebo minimalne jeho existenci) zjistovat vzdyNesmysl, viz komentář alkoholika. Zjišťuje se politika, nikoliv existence klíče.
Tiskni
Sdílej: