Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Ř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: