OCCT3D (Open CASCADE Technology) Open Source 8.0 bylo vydáno. OCCT3D (Wikipedie, GitHub) je objektově orientovaná knihovna pro 3D CAD, CAM nebo CAE. Používá se například v softwarech FreeCAD a KiCad.
Ve FreeBSD byla nalezena a již opravena 21letá zranitelnost CVE-2026-42511 v dhclient. Jedná se o vzdálené spuštění kódu (RCE). Útočník mající pod správou DHCP server může získat plnou kontrolu nad systémem FreeBSD pouze jeho připojením k místní síti.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.3. Současně oznámila, že nadcházející větší vydání 24.04-2.0 bude mít modernější webový prohlížeč.
Ploopy po DIY trackballech či sluchátkách představuje nový externí DIY trackpoint se čtyřmi tlačítky Bean. Obsahuje snímač Texas Instruments TMAG5273, spínače Omron D2LS-21 a řadič RP2040, používá firmware QMK. Schémata jsou na GitHubu; sadu lze předobjednat za 69 kanadských dolarů (bez dopravy a DPH).
Mozilla před dvěma týdny na svém blogu oznámila, že díky Claude Mythos Preview bylo ve Firefoxu nalezeno a opraveno 271 bezpečnostních chyb. Včera vyšel na Mozilla Hacks článek s podrobnějšími informacemi. Z 271 bezpečnostních chyb mělo 180 chyb vysokou závažnost, 80 chyb střední závažnost a 11 chyb nízkou závažnost. Celkově bylo v dubnu ve Firefoxu opraveno 423 bezpečnostních chyb. Čísla CVE nemusí být přiřazována jednotlivým chybám. CVE-2026-6784 například představuje 154 bezpečnostních chyb.
Před týdnem zranitelnost Copy Fail. Dnes zranitelnost Dirty Frag. Běžný uživatel může na Linuxu získat práva roota (lokální eskalaci práv). Na většině linuxových distribucí vydaných od roku 2017. Aktuálně bez oficiální záplaty a CVE čísla [oss-security mailing list].
Ačkoli je papež Lev XIV. hlavou katolické církve a stojí v čele více než miliardy věřících po celém světě, také on někdy řeší všední potíže. A kdo v životě neměl problémy se zákaznickou linkou? Krátce poté, co nastoupil do úřadu, musel papež se svou bankou řešit změnu údajů. Operátorka ale nechtěla uvěřit, s kým mluví, a Svatému otci zavěsila.
Incus, komunitní fork nástroje pro správu kontejnerů LXD, byl vydán ve verzi 7.0 LTS (YouTube). Stejně tak související LXC a LXCFS.
Google Chrome 148 byl prohlášen za stabilní. Nejnovější stabilní verze 148.0.7778.96 přináší řadu novinek z hlediska uživatelů i vývojářů. Vypíchnout lze Prompt API (demo) pro přímý přístup k AI v zařízení. Podrobný přehled v poznámkách k vydání. Opraveno bylo 127 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Tak jsem si nějak povšimnul, že veškeré moje maily, odeslané na nejmenovaný největší český freemail, skončí jako spam. Kupodivu u jiných příjemců se tento problém nevyskytuje, tak to asi nebude úplně triviální problém a stojí za prozkoumání.
Posílám si tedy mail na jedno z nepoužívaných kont, které tam mám a v hlavičkách vidím X-Spam-Status: score=14.2. No to je celkem slušné skóre, co za to asi může? Že by se tomu nelíbila moje adresa michal@cihar.com? Změna odesílatele na cosi@email.cz a hle, už mám jenom X-Spam-Status: score=8.2. Bohužel pořád dost na to aby to skončilo ve spamu.
Jako první mě samozřejmě napadl nějaký obskurní blacklist, ale jakékoliv online nástroje pro kontrolu blacklistů mi potvrzují, že můj server na žádném není, tak v tom snad problém nebude. Zkouším ještě poslat mail přímo ze serveru a najednou to projde ... tak že by se kontrolovaly Received hlavičky oproti blacklistům?
Vložení Received s IP adresou přes kterou se připojuju (kabelovka, NAT pro nepočítaně lidí, takže nejspíš je na všech možných i nemožných blacklistech) opravdu způsobí onen závratný růst skóre. Proč má jediná hlavička takový vliv netuším, ale jediná moje možnost je přenastavit si mailserver aby tyto adresu maskoval.
Naštěstí nalezení návodu pro Exim je otázkou jednoho dotazu na pana Googla a změna je na světě:
received_header_text = Received: \
${if def:sender_rcvhost {from ${if def:authenticated_id \
{127.0.0.1 (helo=authenticated.user.fuck.seznam)} \
{$sender_rcvhost}}\n\t}\
{${if def:sender_ident \
{from ${quote_local_part:$sender_ident} }}\
${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
by $primary_hostname \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
(Exim $version_number)\n\t\
${if def:sender_address \
{(envelope-from <$sender_address>)\n\t}}\
id $message_exim_id\
${if def:received_for {\n\tfor $received_for}}
O tom nakolik je takovéto chování od mailserveru korektní spekulovat nebudu a názor si vytvořte sami.
Tiskni
Sdílej:
s/authenticated.user.fuck.seznam/authenticated.user.fuck.nejmenovany_nejvetsi_cesky_freemail/
.
Proč má jediná hlavička takový vliv netušímHmm, blbej dotaz. Pokud se z nejake IP adresy posila spam, tak jde do blacklistu a to natvrdo. Napriklad na nasem serveru kontrolujeme IP adresy rovnou na postfixu, takze takovy klienti jsou rovnou odmitnuti a email se vubec neprijme.
ale jediná moje možnost je přenastavit si mailserver aby tyto adresu maskoval.No, sice presne netusim, co provede ten zaznam v eximu, ale nas server proste bere IP adresu toho klienta, se kterym prave komunikuje. Takze do Received by sis mohl cpat, co bys chtel a stejne by te postfix odmitnul. Je otazka, jak to dela seznam, spravne by mel v Received kontrolovat od posledni hosta jenom ty IP, kterym duveruje a u posledniho duveryhodnyho IP zkontrolovat client IP a podle toho se pak rozhodovat (tak to tusim dela i spamassassin). Ale podle toho popisu to vypada, ze seznam je hodne paranoidni a zkouma vsechny Received IP adresy. Co ta IP adresa kabelovky, je na nejakym blacklistu? Ona ani nemusi byt v blacklistu spameru, ale pouze v seznamu dynamickych IP nebo v seznamu IP, ze kterych majitel IP rozsahu zakazal odesilani emailu (coz je prave vetsina takovyhle klientskych IP).
raptor {notebook doma} --- [NAT na 212.24.157.193] --- mort.cihar.com {můj server} --- mx.seznam.cz
Mail posílám přes svůj server, ten přidá:
Received: from gw.kabelservis.cz ([212.24.157.193] helo=raptor)
by mort.cihar.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.69)
(envelope-from <michal@cihar.com>)
id 1Kab3P-00034O-T3
for michal.cihar@seznam.cz; Tue, 02 Sep 2008 20:56:39 +0200
A přepošle to seznamu. Ten se koukne do výše zmíněné hlavičky, uvidí IP adresu 212.24.157.193, najde jí na blacklistech a mail zahodí:
2.1 RCVD_IN_UCEPROJECT2 RBL: uceprotect2
[212.24.157.193 listed in dnsbl-2.uceprotect.net]
2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?212.24.157.193>]
2.1 RCVD_IN_UCEPROJECT1 RBL: uceprotect1
[212.24.157.193 listed in dnsbl-1.uceprotect.net]
1.0 RCVD_IN_PSBL RBL: Received via a relay in PSBL
[212.24.157.193 listed in psbl.surriel.com]
2.1 RCVD_IN_UCEPROJECT3 RBL: uceprotect3
[212.24.157.193 listed in dnsbl-3.uceprotect.net]
5.0 RCVD_IN_CBL RBL: Received via a relay in cbl.abuseat.org
[212.24.157.193 listed in cbl.abuseat.org]
Jak dobře je nastavený server, který to finálně odesílal v tomto případě vůbec nebylo relevantní (a myslím si, že je nastavený dobře
).
Navíc mne překvapuje, že Váš poskytovatel nechává stroje za NATem bez filtrace SMTP spojení.Proč by to měl filtrovat? Když chci využívat konkrétní SMTP server, tak mi do toho ISP nemá co kecat (a nutit mě, abych využíval jen ten jeho).
Proč má jediná hlavička takový vliv netuším, ale jediná moje možnost je přenastavit si mailserver aby tyto adresu maskoval.Protoze freemaily dostavaji obrovska kvanta spamu a udelaji cokoliv co aspon trochu pomuze. Kdyz mas denne v poste tisic spamu tak ti to muze pripadat jako kanon na vrabce, ale az jich budes dostavat terabajt uvidis veci jinak
. Ale odmítnout mail jenom podle blacklistu bez toho aby bylo cokoliv podezřelého v něm si nedovolím.
Ostatně oni se chlubívají i spoustou dalších věcí - nikdy nezapomenu na několik měsíců, než jsme ze svého domácího providera vydolovali reverzní záznam. Během té doby například vůbec nešlo posílat maily na MFF, jelikož tamní admini tyto maily odmítají, i kdyby neměly žádný další problém. Nechápu...
Jinak, my jsme vždycky kontrolu proti blacklistům nasazovali jako opatření z nouze, když chodilo tolik spamu, že to bylo poznat i na lince a mailový router měl frontu s tisícovkami mailů, ale vždycky jsme to brali jako prohru a snažili se vymyslet pro příště něco lepšího. Blacklist je pohodlné, ale velmi krátkozraké řešení...
Nicméně, někteří provideři si příliš neuvědomují, že existují uživatelé, pro které je e-mail hlavním pracovním nástrojem a false positive potenciální průšvih jak mraky. Naši uživatelé by nám to v případě potřeby možná dali najevo i plyšovým kladivem
Boj proti spamu přitom může být i kreativní činnost
nikdy nezapomenu na několik měsíců, než jsme ze svého domácího providera vydolovali reverzní záznam.A proč by si měla mít PTR záznam pro svou adresu, pokud ti na ni nesměřuje žádný áčkový (případně AAAA) záznam? Na to, že by měl mít mailserver PTR záznam je taky nějaké RFC?
Mně hlavně připadá hodně pochybné, že Seznam zahazuje maily jako spam i v případě, že mu e-mail sice přijde z "čisté" adresy, ale někdev trace fields se vyskytuje "závadná" adresa. U jednoho zákazníka už jsem s tím měl taky problémy: odesílající MTA je v pořádku, ale adresa, za kterou je maškarádovaná lokální síť, se dostala na blacklist (nejspíš kvůli nějakému hyperaktivnímu trojákovi) a od té chvíle jim nešlo poslat mail na Seznam. Proti spamu je to na houby, jediné, čeho tím docílí, bude to, že všichni radši před tím, než jim mail pošlou, budou nuceni vyházet trace fields, takže případná diagnostika půjde do háje.
:%s/Seznam/nejmenovany_cesky_freemail/g