Je třetí sobota v září a proto vše nejlepší k dnešnímu Software Freedom Day (SFD, Wikipedie).
Bogdan Ionescu rozběhl webový server na jednorázové elektronické cigaretě.
Byla vydána beta verze Ubuntu 25.10 s kódovým názvem Questing Quokka. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.10 mělo vyjít 9. října 2025.
Bola vydaná nová verzia 4.13 security platformy Wazuh. Prináša nový IT hygiene dashboard, hot reload dekodérov a pravidiel. Podrobnosti v poznámkách k vydaniu.
Americký výrobce čipů Nvidia investuje pět miliard dolarů (přes 100 miliard Kč) do konkurenta Intel, který se v poslední době potýká s vážnými problémy. Firmy to včera oznámily ve společné tiskové zprávě. Dohoda o investici zahrnuje spolupráci při vývoji čipů pro osobní počítače a datová centra. Akcie společnosti Intel na zprávu reagovaly výrazným růstem.
Dlouholetý balíčkář KDE Jonathan Riddell končí. Jeho práci na KDE neon financovala firma Blue Systems, která ale končí (Clemens Tönnies, Jr., dědic jatek Tönnies Holding, ji už nebude sponzorovat), někteří vývojáři KDE se přesunuli k nově založené firmě Techpaladin. Pro Riddella se již nenašlo místo. Následovala debata o organizaci těchto firem, které zahraniční vývojáře nezaměstnávají, nýbrž najímají jako kontraktory (s příslušnými důsledky z pohledu pracovního práva).
V Amsterdamu probíhá Blender Conference 2025. Videozáznamy přednášek lze zhlédnout na YouTube. V úvodní keynote Ton Roosendaal oznámil, že k 1. lednu 2026 skončí jako chairman a CEO Blender Foundation. Tyto role převezme současný COO Blender Foundation Francesco Siddi.
The Document Foundation, organizace zastřešující projekt LibreOffice a další aktivity, zveřejnila výroční zprávu za rok 2024.
Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 1.90.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.
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