Jihokorejská Národní daňová služba (NTS) zabavila kryptoměnu Pre-retogeum (PRTG) v hodnotě 5,6 milionu dolarů. Pochlubila se v tiskové zprávě, do které vložila fotografii zabavených USB flash disků s kryptoměnovými peněženkami spolu se souvisejícími ručně napsanými mnemotechnickými obnovovacími frázemi. Krátce na to byla kryptoměna v hodnotě 4,8 milionu dolarů odcizena. O několik hodin ale vrácena, jelikož PRTG je extrémně nelikvidní, s denním objemem obchodování kolem 332 dolarů a zalistováním na jediné burze, MEXC [Bitcoin.com].
Komunita kolem Linuxu From Scratch (LFS) vydala nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů Linux From Scratch 13.0 a Beyond Linux From Scratch 13.0. Pouze se systemd.
Byla vydána nová stabilní major verze 25.12 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Jedná se o nástupce předchozí major verze 24.10. Přehled novinek v poznámkách k vydání. Podporováno je více než 2200 zařízení.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za únor (YouTube). Odstraněn byl veškerý kód napsaný ve Swiftu. JavaScriptový engine LibJS byl reimplementován v Rustu.
Byla vydána verze 1.94.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example. Zveřejněny byly výsledky průzkumu mezi vývojáři v programovacím jazyce Rust: 2025 State of Rust Survey Results.
Google zveřejnil seznam 185 organizací přijatých do letošního Google Summer of Code (GSoC). Dle plánu se zájemci přihlašují od 16. do 31. března. Vydělat si mohou od 750 do 6600 dolarů. V Česku a na Slovensku je to 900 dolarů za malý, 1800 dolarů za střední a 3600 dolarů za velký projekt. Další informace v často kladených otázkách (FAQ). K dispozici jsou také statistiky z minulých let.
Byla vydána únorová aktualizace aneb nová verze 1.110 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.110 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Apple představil 13palcový MacBook Neo s čipem A18 Pro. V základní konfiguraci za 16 990 Kč.
Kalifornský zákon AB 1043 platný od 1. ledna 2027 vyžaduje, aby operační systémy požadovaly po uživatelích věk nebo datum narození a skrze API poskytovaly aplikacím informaci, zda je uživatel mladší 13 let, má 13 až 16 let, má 16 až 18 let nebo má alespoň 18 let. Vývojáři linuxových distribucí řeší, co s tím (Ubuntu, Fedora, …).
Konference LinuxDays 2026 proběhne o víkendu 3. a 4. října v Praze v areálu ČVUT v Dejvicích na FIT. Čekají vás desítky přednášek, workshopy, stánky a setkání se spoustou chytrých lidí.
Samotné podepisování odchozích e-mailů a jejich ověřování serverem příjemce (DKIM) je sice hezké,
ale nemá skoro žádné praktické přínosy – snad jen to, že ve webovém rozhraní GMailu se příjemci zobrazí:
podepsáno od naše-doména.cz nebo že si pokročilý uživatel může zobrazit zdrojový kód zprávy a v něm zkontrolovat
hlavičku Authentication-Results.
Praktických přínosů se dočkáme až po nasazení technologie ADSP, která na DKIM navazuje. ADSP je způsob, kterým vlastník domény může sdělit světu, jak je to s podepisováním jeho e-mailů. Na výběr má tři možnosti:
K čemu je tedy zavedení ADSP dobré?
Jako příjemce e-mailů se můžeme zbavit části spamu – nevyžádané pošty.
Nepodepsané e-maily tvářící se být z domény, která má discardable
politiku můžeme klidně zahodit/odmítnout a nemusíme jimi zatěžovat své uživatele.
Bohužel se zbavíme jen části spamu, protože spameři často využívají zavirovaných klientských počítačů (typicky s Windows),
ze kterých uživatelům ukradnou jejich jméno a heslo – a spam odesílají pomocí nich, takže může mít platný DKIM podpis.
Přínos je ale každopádně v tom, že víme, z jakého serveru spam pochází a vlastník tohoto serveru ví,
přes který uživatelský účet byl odeslán – je tak možné danému uživateli zablokovat SMTP,
nastavit mu kvótu na odchozí e-maily nebo ho vyzvat k nápravě (odvšivení počítače).
Nastavením discardable politiky se jako vlastník domény budeme bránit rhybaření resp. podvodným dopisům.
Nikdo pak nebude moci posílat e-maily, které se tváří, jako že jsou z naší domény.
Alespoň ne na servery, které respektují ADSP politiku ostatních domén.
Toho využívá např. platební systém PayPal.com.
Nasazením ADSP na straně serveru příjemce ochráníte své uživatele před těmito podvodnými e-maily.
Podepisování e-mailů máme zprovozněné už od minule, teď se proto budeme soustředit jen na změny související s nasazením ADSP, nikoli samotného DKIMu.
Jako vlastník internetové domény si definujeme ADSP politiku – to je velice jednoduché, stačí vytvořit příslušný DNS TXT záznam pro naši doménu:
_adsp._domainkey.example.com. IN TXT "dkim=discardable"
Místo discardable můžeme použít mírnější all (viz význam politik výše).
Politiku unknown nemá moc smysl nastavovat, protože stejně se interpretuje, i když ADSP záznam úplně chybí.
Pro ověřování podpisů a souladu s ADSP politikou použijeme stejný software jako pro podepisování odchozích zpráv: DKIM Milter (viz předchozí článek).
Jediné, co musíme udělat, je upravit konfigurační soubor /etc/dkim-filter.conf – přidáme do něj řádek:
ADSPDiscardyes
A restartujeme filtr:
/etc/init.d/dkim-filter restart
Po této úpravě bude náš server respektovat ADSP politiky ostatních domén a pokud se někdo pokusí odeslat nepodepsaný e-mail z domény, která o sobě tvrdí, že všechny její e-maily mají být podepsané, bude naším serverem odmítnut.
Poznámka: někdy můžeme narazit na výchozí konfigurační soubor dkim-filter.conf, který obsahuje chybný řádek
#ASPDiscardno místo správného #ADSPDiscard no – dáváme tedy pozor na překlepy.
DKIM/ADSP a SPF (Sender Policy Framework) jsou svým způsobem konkurenční technologie – obě mají podobné cíle a obě používají DNS.
Pro DKIM a ADSP v DNS nastavíme:
default._domainkey.example.com. IN TXT "v=DKIM1; g=*; k=rsa; p=MIGf...wIDAQAB" _adsp._domainkey.example.com. IN TXT "dkim=discardable"
A pro SPF:
example.com. IN TXT "v=spf1 mx ip4:146.102.….… ~all"
V obou případech definujeme v DNS záznamech jednak podmínky (u DKIM je to veřejný klíč, kterým mají být zprávy podepsané, u SPF jsou to IP adresy, ze kterých mohou e-maily odcházet) a jednak politiku, která říká, co se má dělat se zprávami, které podmínky nesplňují.
SPF je sice jednodušší (není potřeba pracovat s kryptografií – stačí zkontrolovat IP adresu),
ale trpí docela zásadním problémem při přeposílání zpráv.
Když si uživatel nechá přeposílat e-maily z jednoho účtu na druhý, zprávy z domény odesílatele najednou odcházejí z jiné IP adresy
a cílový server nemůže poznat, zda se jedná o přeposílání nebo třeba o spam.
DKIM/ADSP tímto problémem netrpí, protože elektronický podpis lze ověřit i u přeposlané zprávy – je jedno, odkud přišla, pokud je podpis platný.
SPF navrhuje, aby se u přeposílaných zpráv měnila adresa odesílatele (použít tzv. remailing a ne forwarding),
nebo aby si příjemci přidali přeposílající servery na bílou listinu.
To ovšem vyžaduje provést změny na všech přeposílajících nebo cílových serverech,
což činí ze SPF politiky -all (e-maily mohou odcházet jen z vyjmenovaných IP adres a žádných jiných)
prakticky nepoužitelnou záležitost.
Tuto politiku má nastavanou např. Česká národní banka (cnb.cz).
Takže pokud vám bude psát někdo z ČNB a vy si necháváte e-maily přeposílat na server, který respektuje SPF politiku, zpráva k vám nedorazí.
Když vám naopak bude psát PayPal (který má nastavenou DKIM politiku discardable), e-mail k vám dorazí, i když si ho přepošlete třeba desetkrát.
Mějme tři poštovní servery resp. domény:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
_adsp._domainkey.example.com. IN TXT "dkim=discardable"
ADSPDiscard yes.
Uživatel s adresou uzivatel@a.tld se pokusí odeslat e-mail ze své adresy pomocí nikoli svého domácího serveru (a.tld), ale pomocí jiného serveru (c.tld – např. server v práci nebo ve škole). Server c.tld nemá soukromý klíč domény a.tld a odchozí e-maily samozřejmě nepodepisuje.
Sep 24 13:31:13 vse postfix/smtp[22720]: [ID 197553 mail.info] 8DC611802: to=<uzivatel@b.tld>, relay=b.tld[2a01:430:...::...]:25,
delay=1.3, delays=0.01/0/0.63/0.65, dsn=5.7.1, status=bounced (host b.tld[2a01:430:...::...] said: 550 5.7.1
rejected due to DKIM ADSP evaluation (in reply to end of DATA command))
Uživatel má dvě adresy: uzivatel@c.tld a uzivatel@b.tld. Poštu z c.tld si nečte na tomto serveru, ale nechá si ji přeposílat na server b.tld.
Při použití technologie DKIM/ADSP tedy nemáme problémy s přeposíláním, jako je tomu u SPF.
Možná se teď chystáte nadšeně nastavit ADSP politiku pro svoji doménu, před tím je ale dobré se ještě zamyslet nad následujícími případy:
marketing.example.com,
která bude mít benevolentní podpisovou politiku.
Reply-To na adresu, kterou zadal uživatel – zpráva bude bezproblémů doručena (protože bude z vaší domény a vašeho sevreru)
a pokud na ni bude chtít příjemce odpovědět, odpoví na adresu odesílatele.
V případě firem lze doporučit discardable politiku.
Zřejmě nestojíte o to, aby zaměstnanci posílali firemní (důvěrnou) poštu přes nějaké pochybné cizí SMTP sevrery
– když už mají mít přístup k e-mailu i mimo firmu, tak jim poskytnete přístup na svůj SMTP server, webové rozhraní k poště nebo třeba VPN.
Díky ADSP snížíte pravděpodobnost, že bude někdo vaším jménem (z vaší domény) posílat např. falešné faktury nebo nějaké poplašné zprávy.
Pokud naopak spravujete školní nebo nějaký komunitní server nebo jste poskytovatelem e-mailových služeb,
není discardable politika moc dobrou volbou. Těžko donutíte uživatele, aby posílali e-maily výhradně přes váš SMTP server
– a ani to není žádoucí – uživatelé by pak asi danou e-mailovou adresu přestali používat.
Přesto je dobré nasadit DKIM a podepisovat e-maily – v případě nějakých incidentů půjde např. dohledat, zda daný e-mail odešel z vašeho serveru.
Také tím zvýšíte důvěryhodnost odchozích e-mailů – zde záleží na podpoře klientského softwaru – ten může uživateli signalizovat,
že e-mail obsahuje platný DKIM podpis (jako to dělá např. GMail).
SPF není na nic, jen jeho politika -all je takřka nepoužitelná.
Klidně ale můžete nastavit ~all politiku, která říká, že e-maily odeslané z jiných IP adres mají být přijaty, jen mohou být podrobeny důkladnější kontrole.
Naopak zprávy přijaté z vyjmenovaných IP adres budou důvěryhodnější.
Ještě jedno dobré využití má SPF: existuje poměrně dost domén, které se používají jen pro web nebo jiné služby, ale nikdy z nich žádné e-maily neodcházejí.
U takových domén nastavíme -all SPF politiku a tím zabráníme spamerům, aby naši doménu zneužívali jako odchozí.
Totéž můžeme udělat s ADSP – nastavíme discardable politiku (pro případ, že server příjemce podporuje ADSP, ale nepodporuje SPF).
Jako správci serveru přijímajícího poštu bychom měli respektovat politiky (jak ADSP, tak SPF), které si nastavili vlastníci jiných domén. Pokud někdo tvrdí: „všechny naše e-maily jsou podepsané tím a tím klíčem“, tak to berme jako fakt – a to i v případě, že by se nám jeho politika mohla zdát příliš přísná nebo špatná – jsou to jeho e-maily a jeho případná odpovědnost a chyba – ne naše. Navíc pokud si poštovní systém nastavíme tak, jak je uvedeno v návodu výše, nevyhovující e-maily budou odmítnuty ještě v rámci SMTP spojení (ne až následně), takže se žádné zprávy neztratí – e-mail se jednoduše vrátí ke svému odesílateli jako nedoručitelný.
DKIM a ADSP je přínosná technologie, která pomáhá v boji se spamem a podvodnými e-maily – i když samozřejmě nedokáže tyto problémy vyřešit zcela. Ideální by bylo, kdyby e-maily podepisovali sami uživatelé (ať už pomocí OpenPGP/GPG nebo S/MIME) a také je šifrovali, ovšem vzhledem k neschopnosti běžných uživatelů tyto technologie používat je fajn podepisovat zprávy alespoň na úrovni domény. Ruku na srdce: kolik už jste zaplatili faktur, které k vám dorazily nešifrovaným a nepodepsaným e-mailem nebo dokonce papírovou poštou?
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Pokud by se jednalo o podvrh – útočník by se snažil odeslat zprávu z adresy uzivatel@a.tld – uživatel by na to díky této chybové zprávě přišel (v ní by byl přiložen i přímo ten e-mail, který se útočník jeho jménem pokoušel odeslat).
Jinými slovy: nespamujete příjemce, ale "odesílatele" 
Jinými slovy: nespamujete příjemce, ale "odesílatele"To většinou nebude pravda: pokud je mail odmítnut už v SMTP relaci - v uvedeném příkladu to tak podle všeho je - pak není pravděpodobné, že by se rozesílající spamovací vir obtěžoval s tím zasílat zprávu o nedoručitelnosti.
6.10.2010 17:31
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Nezbavíme
1) Nikdy nepřinutíš všechny něco dělat.
2) Spamerovi nic nebrání to posílat podepsané (jak už bylo řečeno).
5.10.2010 13:47