Organizace Apache Software Foundation (ASF) vydala verzi 23 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.
Ve čtvrtek 3. října se v Red Hat Labu (místnost Q305) na FIT VUT v Brně uskuteční další Fedora Installfest. Od 10 do 16 budou v labu připravení odborníci na Fedoru ze společnosti Red Hat, kteří vám můžou pomoct nejen s instalací, ale taky pomoct s dalšími problémy a dotazy ohledně Fedory. Akce je primárně zaměřená na studenty FIT VUT, ale vítáni jsou i lidé, kteří tuto školu nenavštěvují.
Byla vydána nová verze 9.9 sady aplikací pro SSH komunikaci OpenSSH. Z novinek lze vypíchnout podporu hybridní post-kvantové výměny klíčů založené na FIPS 203 ML-KEM (Module-Lattice Key Enapsulation mechanism) v kombinaci s X25519 ECDH, tj. nový výchozí algoritmus "mlkem768x25519-sha256". Počátkem roku 2025 bude z OpenSSH odstraněna podpora DSA.
Interaktivní monitor zdrojů btop++, tj. C++ verze a pokračování monitorů bashtop a bpytop, byl vydán v nové verzi 1.4.0. Přináší podporu monitorování Intel GPU a NetBSD.
Byl vydán Nextcloud Hub 9. Představení novinek tohoto open source cloudového řešení také na YouTube.
Americký výrobce čipů Qualcomm se v minulých dnech obrátil s nabídkou na převzetí na konkurenční firmu Intel, která nyní prochází jednou ze svých největších krizí. Uvedl to list The Wall Street Journal s odvoláním na informované zdroje. Tržní hodnota Intelu se nyní pohybuje kolem 87 miliard amerických dolarů. Tržní hodnota firmy Qualcomm se pohybuje kolem 185 miliard dolarů.
Byla vydána beta verze Ubuntu 24.10 s kódovým názvem Oracular Oriole. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 24.10 mělo vyjít 10. října 2024.
Linux na 4bitovém mikroprocesoru Intel 4004 z roku 1971? Ale jistě: Linux/4004 (YouTube).
Google Chrome 129 byl prohlášen za stabilní. Nejnovější stabilní verze 129.0.6668.58 přináší řadu novinek z hlediska uživatelů i vývojářů (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube: DevTools Chrome 127-129).
BTW veci kolem prekladu jmen a "kompletni kompatibilita nezi dns/ipv4/dns6/ipv6" jsou duvod, proc nejde ipv6 naimplementovat plosne a "ihned".Můžu poprosit o trochu víc detailů?
Reverzní A v IPv4 se obvykle řeší tak, že i když máš rozsah, nemáš vlastní nameserver, ale říkáš si upstream providerovi o každou změnuStandardni reseni je to, ze provider (nebo ten, kdo ma nadrazeny /24 rozsah) zridi v rozsahy poddomenu a pro vsechna reverzni jmena v udela CNAME do dane poddomeny. Poddomena se pak deleguje na tvuj DNS server. Viz RFC 2317
Ta "obrana" samozrejme funguje.Jistěže funguje – způsobem, který jsem popsal v závorce.
Navíc když takhle e-maily zahazuje jen primární SMTP server,Tak je admin pako, na to se nedá nic jinýho říct. Pokud někdo neumí nastavit mailservery, tak je to jeho problém. A zvlášť blbě nastavenej backup mailserver je mnohem horší než žádnej.
Pokud někdo neumí nastavit mailservery, tak je to jeho problém.Právě že ne. Když někdo neumí nastavit mailservery, je to problém hlavně všech okolo. Dotyčný admin je zpravidla jediný, kdo je v klidu, protože o nedoručených e-mailech neví, a že jeho server rozesílá spam (jiný případ špatné konfigurace) ho netrápí. Já osobně považuji za špatné nastavení mailserveru i to, pokud se z existence či tvaru reverzního záznamu IP adresy jeho protějšku pokouší něco uhodnout. Většina spamu pochází z počítačů, které reverzní záznam mají.
Většina spamu pochází z počítačů, které reverzní záznam mají.Na mailserverech, které se nebaví se strojema bez reverzů určitě. Ale jinak bys musel tohle tvrzení nečím podložit, podle mě nemáš obecně pravdu. Já jsem většinu spamů odfiltroval na základě špatného chování při SMTP komunikaci.
Já osobně považuji za špatné nastavení mailserveru i to, pokud se z existence či tvaru reverzního záznamu IP adresy jeho protějšku pokouší něco uhodnout.To já taky, já radši, když nic nehádá a prostě všecky, co se nechovaj rozumně pošle do háje. Oni si to velmi rychle opraví a když ne, jejich smůla, každopádně nemůžou předstírat, že si toho nevšimli.
Ale jinak bys musel tohle tvrzení nečím podložit, podle mě nemáš obecně pravdu.
grep 'client=unknown' /var/log/mail/* | wc -l grep 'client=' /var/log/mail/* | wc -la obě čísla podělit. Na jednom serveru jsem napočítal ani ne 40 % bez reverzu. Test, kterým mi projde více jak 60 % spamu a nijak neovlivní další testy, který ale bez varování může likvidovat i ham, ten nepotřebuju.
Oni si to velmi rychle opraví a když ne, jejich smůla, každopádně nemůžou předstírat, že si toho nevšimli.Co by si opravovali? A proč by si toho museli všimnout? Myslíte si, že budu pokaždé pátrat po tom, zda můj e-mail došel? Většinou pokud není na e-mail adekvátní reakce, není problém obrátit se někam jinam, kde na e-mail zareagují.
$ grep "SA: Action: temporarily rejected message:" rejectlog | grep "host=NULL" | wc -l 8 $ grep "SA: Action: temporarily rejected message:" rejectlog | wc -l 12 $ grep "SA: Action: permanently rejected message:" rejectlog | grep "host=NULL" | wc -l 57 $ grep "SA: Action: permanently rejected message:" rejectlog | wc -l 85Jsme na malém serveru, kde neběží žádné komerční nasazení. Přesto v dnešním ani včerejším logu není jediný přijatý mail, který by byl doručen. Tedy přesněji každý den to byly 3. U všech třech se v logu píše:
SA: Action: flagged as Spam but acceptedZa celou historii logů nemám ani jeden přijatý mail bez reverzu. Jestli tohle vám nestačí, potom to asi umíte líp. Mě to stačí a dál to nepotřebuji řešit. Pokud uvažujete o reálném mailování, reverz prostě potřebujete.
bez varování může likvidovat i hamLikvidovat nemůže nic. A bez varování nemůže taky nic (nejen likvidovat).
chybové zprávy o nedoručeném e-mailu se dnes právě kvůli spamu a hlavně virům většinou neodesílajíChybové zprávy o nedoručení mailu se podle mě odesílají.
A
má zavirovaný počítač, nějaký vir si vybere z jeho adresáře kontaktů náhodně uživatele B
a na adresu C
pošle sám sebe nebo nějaký spam s adresou odesílatele B
(aby to vypadalo důvěryhodně, případně prošlo whitelisty založenými na e-mailových adresách odesílatele). Cílový server e-mail z nějakého důvodu odmítne a odešle zprávu o nedoručení e-mailu na adresu odesílatele – B
. Takže B
právě dostal další milý spam. Jenom si nejsem jistý, zda tohle bude účinná taktika proti spamerům. Obávám se, že je marné doufat, že se takhle vygeneruje spamu ještě daleko víc a spameři se půjdou do kouta stydět, jací jsou břídilové, a spamování nechají.
Hm, moje věta „… se děje ve vzácné shodě s …“ evidentně padla na úrodnou půdu.Evidentně vůbec. Bavili jsme se o konfiguraci našeho mailserveru... a tento spam náš mailserver neodesílá ani nepřijímá, tudíš to není tak úplně náš problém.
leda že by si u každé zprávy ve frontě pamatoval i to, odkud se tam ten e-mail vzal.To si samozřejmě pamatuje. A nejen to, přidává tuto informaci do hlavičky mailu.
Tedy kromě obálkového odesílatele, což je ta informaceCož je úplně jiná informace, která s tím nemá nic společného.
Právě proto mám například na mém serveru nastavení takové, že mailserver mail nepřijme od uživatele hned, ale antispamové prostředky použije ještě předtím, že uživateli potvrdí převzetí.Parse error.
To je pak ale v rozporu s tvrzením, že se uživatel dozví o odmítnutí e-mailu.Není.
novak@example.com
. Pepa Novák bude odesílat přes relay svého ISP e-mail, přihlásí se jménem a heslem, server si ho najde v databázi a k e-mailu ve frontě poznamená, že pokud by došlo k chybě, má se chybová zpráva odeslat na novak@example.com
. Při troše štěstí se bude relay ISP bavit přímo s cílovým serverem, ten e-mail odmítne hned během SMTP sezení, takže relay se podívá, kam má poslat chybovou hlášku a odešle jí. Teoreticky to bude v tomhle ideálním případě fungovat. Ale už jste někdy viděl takovéhle řešení použité v praxi?
A na to se nelze spoléhat, protože tam si odesílatel (vir) napíše, co ho napadne.Takže tebe trápí, že autor viru nedostane zprávu o nedoručení? No to je mi líto...
Opravdu jste tak naivníOdpověz si sám. Ad ostatní: to řešíš úplně jiný problém než o který šlo a než který se týká kontroly reverzních záznamů na cílovém serveru.
Jenomže pavlix neustále doporučujeLžeš.
Pokud chceš provozovat vlastní mailserver, je dobrý mít statickou adresu, MX záznam, A/AAAA záznam, reverzní záznam a dobře nakonfigurovaný mailserver.A hodinky s vodotryskem potřeba nejsou? K odeslání e-mailu není nic z vyjmenovaného potřeba. A nic z toho neodlišuje server rozesílající spam od serveru rozesílajícího normální poštu. Tak k čemu ty vaše dodatečné podmínky jsou?
Asi jsi zaspal dobu, když si myslíš, že jsou to naše dodatečné podmínky. Je milé, že chceš mě a Pihhanovi přiřknout vynalezení těchto věcí. Ale musím tě zklamat, náš vynález to není, je to běžný dnešní standard.Tak to jistě nebude problém odkázat na nějaký úplný seznam těch dodatečných podmínek, nejlépe i nějak specifikovaných (třeba jako RFC). A určitě tam bude i popsáno, k čemu jsou takové dodatečné podmínky dobré (i když to zvládnu napsat sám – „aby to vypadalo, že se něco dělá“).
A až vynalezneš způsob, jak filtrovat spam bez heuristiky,Heuristické filtrování spamu znamená analyzovat několik faktorů, zejména obsah e-mailu, a podle toho rozhodnout. Náhodné odmítání různých zpráv nemá s heuristikou nic společného, to je loterie.
Náhodné odmítání různých zpráv nemá s heuristikou nic společného, to je loterie.Právě proto se to náhodně nedělá.
Jestli máte o hodně vychytanější metodu, jak se zbavit spamuK tomu mám jedině to, že tohle nepovažuju za metodu, jak se zbavit spamu. U mne by to např. eliminovalo ani ne 40 % spamu, takže na zbytek stejně musím nasadit něco jiného. Maximálně bych to mohl použít jako určitou váhu do celkového hodnocení, zda jde o spam – ale jinak mi ten test přijde zbytečný. Kdybych odmítal náhodně 40 % spojení, vyjde to nastejno.
Kdybych odmítal náhodně 40 % spojení, vyjde to nastejno.To si nemyslím :). Btw, už jsi psal klukům od abclinuxu, že to maj špatně? :D Přesněji řečeno... už tě s tím poslali do háje? ;)
Na to, že by se Linux choval k IPv6 adresám jinak než k IPv4 jsem zatím nenarazil.A on snad Linux v IPv4 dela to, co popisujes v druhem odstavci?
It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below.Takže situace, kdy jediná globální adresa je na loop backu nebo dummy rozhraní je oficiálně posvěcena. Ovšem situace, kdy router nemá žádnou globální adresu (kdo by to dělal, když by přišel o možnost přihlásit se tam po síti), nemá žádné uspokojivé řešení. Takže se omlouvám za zmatení. Zdá se, že koncept globální adresy náležící stroji a nikoliv rozhraní i někdo jiný považuje za rozumný.
Tiskni Sdílej: