Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.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.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Ve správci balíčků APT, používaném v Debianu a odvozených distribucích, byla nalezena a opravena kritická zranitelnost CVE-2026-109518. Vzdálený útočník může obejít ověření stažených balíčků pomocí přesměrování a dočasných chyb HTTP serveru.
... blablabla ... Bohuzial, Vami odoslane emaily nesplnaju nalezitosti, ktore musia splnat, aby boli prijate nasim mailserverom bez problemov. Konkretne neobsahuje plain-text part, kvoli comu su mnohymi mailservrami ( vratane nasho ) oznacovane ako podozrive. Mnoho emailovych klientov takisto ma ( z objektivnych dovodov ) zakazane prijimat spravy v HTML. V pripade, ze v sprave chyba textova cast, zakaznik nema moznost si tento email vobec precitat. Poprosim Vas o napravu tohoto stavu, aby sme mohli tieto informativne email-y od Vas prijimat bez zbytocnych problemov. Dakujem. ... blablabla ...
From: postmaster@_domena_.cz Doručení těmto příjemcům nebo distribučním seznamům se nezdařilo: postmaster@_domena_.cz V e-mailovém systému příjemce nebyla nalezena adresa tohoto e-mailového příjemce. Server Microsoft Exchange se nebude pokoušet tuto zprávu znovu doručit. Zkontrolujte e-mailovou adresu příjemce a pokuste se tuto zprávu odeslat znovu nebo předejte správci systému tento diagnostický text. ________________________________ Odesláno serverem Microsoft Exchange Server 2007Az na par pismen je obsah oboch mailov uplne identicky.
Tiskni
Sdílej:
Nemam s tim problem a nechapu proc nekdo jo.
Bohuzial, Vami odoslane emaily nesplnaju nalezitosti, ktore musia splnat, aby boli prijate nasim mailserverom bez problemov.Jen tak dál. Čím víc správců si stanový nějaká interní (a nejlépe tajná) pravidla pro příjem e-mailů, tím dříve se stane e-mail pro takovýto druh komunikace nepoužitelný. Třeba pak všichni tihle odesílatelé a příjemci, kteří si stanovují vlastní pravidla, přestanou e-mail používat, a ti ostatní ho zase budou moci používat jako e-mail, se všemi pravidly dle RFC.
2.9 BAD_ENC_HEADER Message has bad MIME encoding in the header 0.0 HTML_MESSAGE BODY: HTML included in message 1.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headersJa za to, ze je niekto prasa, nemozem. Co sa tyka RFC, tak pokial sa bavime o 821, to pojednava len o transportnej vrstve. Takze kludne tade mozem poslat domace porno encodovane do base64 telnetom a pokial dodrzim tych par pravidiel, tak to v pohode odoslem. A to, ze to prijemca neprecita, je smtp uplne fuk.
Co sa tyka RFC, tak pokial sa bavime o 821, to pojednava len o transportnej vrstve.Ale máme také například RFC 2822, kde jsou pravidla pro vlastní zprávy (ať už se přenášejí pomocí SMTP nebo jinak). Tam je kupříkladu napsáno: A date-time specification MUST be semantically valid. That is, the day-of-the-week (if included) MUST be the day implied by the date, the numeric day-of-month MUST be between 1 and the number of days allowed for the specified month (in the specified year), the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of seconds allowing for a leap second; see [STD12]), and the zone MUST be within the range -9959 through +9959. Toto jsou zrovna pravidla, která bývají často porušována. Jinak se dá říct, že když se bavíme o zprávách a jejich vyhodnocování ve Spamassassinu, jde v první řadě o RFC 2822 (formát zpráv) a až následně o RFC 2821 (SMTP).
Teď tedy úplně přesně nevím na co si autor článku stěžujě. Koukal jsem teď na zdroj jednoho informačního emailu právě z Alza a všechno je podle RFC v pořádku. V hlavičce je správně "MIME-Version: 1.0" a jsou tu dokonce i dvě části, jedna s "Content-Type: text/plain;" a druhá s "Content-Type: text/html;".
To by si taky třeba mohl začít stěžovat, že jsem tenhle komentář nenapsal v ASCII.
To že si někdo stanoví svá pravidla pro SPAM ještě neznamená, že zpráva je špatně.
To že si někdo stanoví svá pravidla pro SPAM ještě neznamená, že zpráva je špatně.Jenže ony mnohdy ty zprávy špatně jsou. Například když mi chodily od Seznamu zprávy, na něž Amavis reagoval takto:
X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char F8 hex): Subject: Zat\370\355zen\355 z\341pisu v ...a Spamassassin takto:
X-Spam-Status: Yes, score=5.11 tagged_above=2 required=5 tests=[DNS_FROM_RFC_ABUSE=0.374, MSGID_FROM_MTA_ID=1.704, NO_REAL_NAME=0.178, SUBJ_ILLEGAL_CHARS=2.854]Prostě naprasili osmibitové znaky do předmětu a více se tím netrápili. Ony byly navíc osmibitové znaky i v těle zprávy, aniž by tam byla hlavička
Content-Transfer-Encoding: 8bit. To je další prasárna a současně porušení RFC 2822 ("If the body contains data in any bit-width other than 7-bit, the appropriate bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" for unencoded 8 bit wide data).").
+1
text/plain část.