Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Organizace Apache Software Foundation (ASF) vydala verzi 22 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
Po několikaletém používání webových mailových klientů jsem se rozhodl vyzkoušet, co umí mailový klient, který je součástí mého oblíbeného DE, tedy kmail. Nedá se říct, že bych byl s webovým klientem gmailu nějak nespokojen nabízí mi vše co potřebuji, navíc se pravidelně připojuji z několika počítačů, takže má webový klient výhodu v konzistentnosti. Přece jen ale převážila zvědavost, takže jsem se rozhodl dát KMailu šanci.
Po chvíli brouzdání na google help jsem si vybral jako preferované protokoly IMAP a SMTP. S nastavováním jsem měl pár menších problémů, které jsem vyřešil nějakým tím hledáním na googlu a zkoušením. Abych toto nemusel někdy v budoucnu absolvovat znovu, rozhodl jsem se své poznatky uložit tady.
Nastavit IMAP nebylo těžké. Něco se dá najít na google help, který ale neobsahuje konkrétní návod pro KMail. Jediné, co nemusí být z obecných údajů od google jasné, je metoda autentizace v záložce bezpečnost, kde se také nastavuje šifrování SSL. Dialog ale obsahuje šikovné tlačítko "Zjistit, co server podporuje," které toto řeší. Výsledkem byla volba Čistý text.
Pak zbývalo ještě nastavit SMTP. S tímto jsem nečekal velké problémy, avšak byl jsem trochu nemile zaskočen. Jednak už na google help se mluví o dvou portech, stejně jako se mluví o TLS i SSL (některé klienty podle googlu vydávají TLS za SSL). Hezké je právě to slovo některé, to se pak dobře vybírá.
Rozhodl jsem se ještě trochu zagooglit, zda nenajdu nějaký návod, přičemž jsem našel toto. Jazyku, ve kterém to je napsané sice nerozumím, ale přiložené snímky oken jsou všeříkající. Nastavil jsem tedy port 465, šifrování SSL a autentizaci PLAIN, jak obrázky doporučovaly.
Poté jsem se rozhodl vše vyzkoušet. IMAP fungoval krásně, ovšem odesílaný mail vyhodil jakousi hlášku s mými přihlašovacími údaji a oznámením, že dokud chybu neopravím, mail zústane v přihrádce k odeslání. Po několikanásobné kontrole, která mě ujistila, že se mé nastavení skutečně shoduje s návodem, že je heslo i uživatelské jméno stejně jako adresát správně, jsem se jal dál hledat na googlu.
Tentokrát jsem se dostal k několika hlášeným bugům, ze kterých tento pasoval nejvíce. Zkontroloval jsem tedy SASL, avšak vše bylo v pořádku.
V tuto chvíli mi už začínaly docházet nápady, zvláště poté, co jsem ještě zkusil druhý doporučovaný port a pak i TLS šifrování, ačkoliv jsem při hledání stále narážel na lidi, kteří tvrdili že správné nastavení je SSL.
Poté, co jsem objevil kdesi na třetí stránce výsledků hledání další návod, rozhodl jsem se tomu dát poslední šanci, tentokrát s heslem, když se něco nedaří, začni úplně znova.
Poté co jsem smazal příchozí i odesílací účty, vytvořil novou identitu, smazal tu původní a smazal i ./kde4/share/apps/kmail, jsem nastavil port na 587, šifrování TLS, autentizaci PLAIN a jméno v záložce všeobecné shodné s mou emailovou adresou.
A tentokrát se zpráva odeslala.
Tiskni Sdílej:
Zdá se že používají jiný port, právě ten 587.To jsem pochopil. Jen mě překvapuje, že to řeší takto, protože SSL/TLS na samostatném portu je spíš historický relikt (z dob, kdy nebylo rozšíření SMTP pro TLS), než aby mělo smysl to dnes používat (tím spíš na nestandardním portu - port 587 je sice podle RFC 2476 určen pro Message Submission, ale když už se používá 25, pak by se měl používat port 465).
protoze potom se pouzije i pro s2s komunikaci a pokud nemate certifikaty podepsane duveryhodnou autoritou, tak prestanou maily chodit.Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje). Navíc by to neměl být případ Googlu, pro něj snad není problém mít důvěryhodný certifikát.
Prave proto je tam dalsi port, ktery je urcen pro c2s komunikaci a dava mnohem vetsi moznosti vyhrat si s konfiugraci.Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).
Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje).Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?
Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).Myslel jsem 587, 465 je fakt artefakt. Na 587 zvladne starttls i ten outlook.
Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?Z hlediska bezpečnosti by bylo o něco lepší jet dál po nedůvěryhodném SSL (protože to může zabránit aspoň odposlechu na trase), ale na druhou stranu by to teoreticky mohlo někoho "ukolébat", že se použilo šifrování a všechno tedy musí být v pořádku. Např. Postfix to standardně řeší tak, že když se po STARTTLS objeví problém (ať už kvůli certifikátu nebo z jiných důvodů), tak to zkusí znovu v plain textu, čili to převede na situaci, jako kdyby cílový server TLS vůbec nepodporoval.
Myslel jsem 587, 465 je fakt artefakt.Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.
Na 587 zvladne starttls i ten outlook.To ano, ale musí se tam to číslo portu nastavit.
Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.Ano a tak je to asi i spravne. Nevim jestli v dobe, kdy se navrhoval design SMTP nekdo pocital s tim, ze klient neco posle pres port 25, tehdy se na to pouzival prikaz sendmail, ktery komunikoval s lokalnim sendmail demonem tak, ze injektoval zpravu do fronty, takze 25 mohla byt od zacatku zamyslena jen pro s2s a klientum to holt zapomeli rict Jinak rozhodne konfigurovat SASL a podobne vychytavky mi prijde mnohem cisti na 587, jediny problem je vysvetlit prumernemu uzivateli, ze si musi v outlooku zmenit cislo portu. Obykle to pochopi az kdyz narazi na nesolidniho providera, ktery mu blokuje porty.
Jinak rozhodne konfigurovat SASL a podobne vychytavky mi prijde mnohem cisti na 587To asi ano, ale SSL by bylo žádoucí používat i pro S2S komunikaci - čím méně "uší", tím lépe. Nic to samozřejmě nezaručuje (odposlouchávat se dá i na serveru, resp. je to ten častější případ), ale i tak.
Zadouci by to bylo, ale doba na to jeste nenazrala.Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.
A Verisign se na tom uzasne napakujeNaštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autority
Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.Kazde z tech reseni je urcene pro mirne odlisny okruh problemu. SMTPS teoreticky zajisti duvernost prenesene zpravy i v pripade, ze uzivatele nemeli moznost vymenit si klice a nebo v pripade, ze email je poslan na 1000 adres soucasne a nebylo by prakticke sifrovat kazdou z tech kopii zvlast.
Naštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autorityBavime se jiste o tech vlastnenych Verisignem Nepochybne to tak skonci, staci se podivat na EV certifikaty, ty vystavuje pouze exkluzivni klub Verisign a comp. a takovety petidolarove autority mezi sebe nepusti, i kdyby v prohlizeci byly 100x. Na druhou stranu i to EV dava smysl, protoze pamatuji doby, kdy uplne bezny serverovy certifikat byl vystavovan s validaci odpovidajici dnesnimu EV a potom uz ta pravidla jen erodovala a devalvovala. Dneska uz je to tak spatne, ze Thawte auditori u SSL Webserver vubec nevolaji zakaznikum a pokud ano, tak ne na cisla ziskana od treti strany, ale na cisla uvedena v zadosti.
Umí nějaký klient seskupovat přijaté i odeslané zprávy do jedné „konverzace“ tak jak to dělá gmail? Snažím se přestat používat webmail ale takovéhle věci mi chybí.Kmail to umí. Stačí se podívat do Složka/Vlastnosti.
Thunderbird umí něco podobného - stromová vláknaAle AFAIK jen v rámci složky.
Podle mne to dělá google pěkně blbě, protože to dělá podle subject.Ale fuj, to snad ne!