Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
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 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
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!
Tiskni
Sdílej: