OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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