Příspěvky

naposledy sa mi vratil cielovy mail server (BLABLABLA.prod.outlook.com "Office 365") email s hlaskou:
Remote server returned invalid or missing PTR (reverse DNS) record for sending domain -> 550 5.7.1 Message considered as SPAM (Score of 5.1/5.0 with DATE_IN_PAST_06_12, DMARC_REJECT, FREEMAIL_FROM, HTML_MESSAGE, KHOP_HELO_FCRDNS, MIME_HTML_ONLY, SPF_FAIL, SPF_HELO_NONE, SPOOFED_FREEMAIL) - ImprovMX v2026.10.12

To je chyba vrácená "mailserver testeru" na jeho testovací aktivitu?
Nebo jste tuhle hlášku od outlook.com dostal v odpověď na legitimní e-mail odešedší z Vašeho mailserveru, který se snažíte vymazlit?
Protože pokud je to reakce na legitimní provoz od Vás, tak špatně nastavený čas opravíte jistě snadno a DMARC a SPF by taky nemusely být tolik práce...

...hele... teď si rychle neposkládám v hlavě, jestli to může nějak souviset...

Svého času jsem narazil na to, že centrum.cz požaduje v SMTP relaci od odesílajícího MTA, který dle názoru Centrum.cz nemá úplně skálopevnou reputaci (tzn. kdokoli kromě cca Gmail a Outlook.com) povinně TLS. Tzn. STARTTLS. Takže jsem to u sebe v Postfixu zapnul, a mám klid.

Když mi část odchozí pošty na toto narážela (cokoli na Centrum.cz), chodily zpátky e-milem chybové hlášky od mého odesílajícího Postfixu. Není teoreticky možné, že na toto v některých případech narazíte, a související chybová hláška se k Vám zpátky z nějakého důvodu nedostane? Třeba protože zpáteční adresa nevede do schránky, kterou by někdo četl, nebo vůbec neexistuje...?

Mě tak ještě napadá, k čemu je ostré staré Cisco bez zaplaceného supportu / nových verzí IOSu.
Na nějaké domácí žvýkání asi OK, nejlíp pokud máte od ČEZu slevu protože elektřinou beztak topíte.
A základní features budou prostě fungovat v libovolně staré náhodné verzi firmwaru.

Malé Cisco (Linksys) má tuším updaty firmwaru i bez placeného supportu = jiný obchodní model.

Pokud je to jenom na neformální hands-on ošahání CLI za nula peněz, tak nemám.
Pokud by pro to bylo nějaké praktické uplatnění, takže na to jsou nějaké peníze, tak "malé Cisco" (switche) tzn. Catalyst 1200 series nejsou nutně drahé. Úplně jsem nepochopil, jestli ta produktová karta v Mironetu je čerstvá funglovka z distribuce, nebo nějaký ležák / nerozbalená vratka. Vedle fotky je tam vysvětlivka ohledně "Cisco refresh". Ale skutečná funglovka od TDčka (distributor) není o moc dražší, pokud je zákazníkem firma. V zásadě je to v podobné cenové kategorii, jako podobně velký D-Link. (A popravdě součástková základna napájecí kaskády uvnitř je možná dneska lepší u toho D-Linku.)
"Malé Cisco" znamená, že ten model je vlastně potomek Linksysu, tzn. nikoli tradiční košer Cisco. Má to použitelný příkazový řádek, který se chová velmi podobně jako "dospělý" IOS. Má to taky webové rozhraní (neznám, na webu výrobce je emulátor). Chybí tomu některé pokročilejší features.

Ještě tip: ten paper se mi dobře skimoval tím způsobem, že jsem hledal klíčové slovo "thalamus". Vždycky pár odstavců kolem byly trefa hodně do živého :-)

V kontextu toho, co o thalamu a thalamo-kortikální interakci publikovali Sherman a Halassa.

...Dneska mi totiž Google ukázal následující paper z letošního srpna:
"Learning Through Time in the Thalamocortical Loops"
https://arxiv.org/html/1407.3432v1    (dá se číst přímo v HTML, nebo si vpravo nahoře stáhnete PDF)

Aha. HTML text na Arxivu obsahuje hned pod titulem datum z letošního srpna.
Ale odkázané PDF je z 2014 - datum pod titulem se v tomto shoduje s metadaty PDF generátoru.
Asi budu muset obě verze porovnat :-D

Jinak Randall O'Reilly má na Youtubu kanál, a v něm dva dlouhé playlisty.
Playlist o Computational Cognitive Neuroscience je z roku 2020 a má asi 79 dílů - většinou krátkých, a komentář přednášejícího mi připadá poněkud povrchní, až populárně naučný... a protože ty díly nahrál "v pořadí za sebou", tak je teď YouTube přehrává pozpátku, protože od nejnovějšího :-(  -- zřejmě vleklá bolest a feature YT. Každopádně mi to za shlédnutí rozhodně stojí. Je tam spousta poznatků spíš "na okraj", které ve skutečnosti představují velice užitečný kontext, nasáklý selským rozumem. Dost to nastavuje zrcadlo mnoha paperům z oblasti AI, které jsou naschvál zahrabané ve spleti vzorců a ve finále se člověk nějakého prozření nedočká. Nastavuje zrcadlo též nesčetným mediálním vystoupením kapitánů dnešního AI/LLM průmyslu, kteří tím víc straší AI apokalypsou, čím víc jim finančně teče do bot... (a prozření se jejich shlédnutím také nedočkáte).

Sám R.O'Reilly zdůrazňuje, jak je užitečné ve smyslu vzdělání, hrát si se sítěmi v simulátoru. Obrázek je za tisíc slov, a pár hodin vlastnoručního hraní je za tisíc slajdů v powerpointu. Ho hum - tak daleko nejsem.

Ještě tip: ten paper se mi dobře skimoval tím způsobem, že jsem hledal klíčové slovo "thalamus". Vždycky pár odstavců kolem byly trefa hodně do živého :-)

[thalamu]

Dovolím si tohle vlákno ještě probudit.  ...  Měl jsem kolem Vánoc pár dnů volna, tak jsem zkusil trochu číst

Znovu navážu na svoje talamo-kortikální / neuro-bio ponorné téma, které jsem v tomto vlákně vykopl o vánocích.
Dneska mi totiž Google ukázal následující paper z letošního srpna:
"Learning Through Time in the Thalamocortical Loops"
https://arxiv.org/html/1407.3432v1    (dá se číst přímo v HTML, nebo si vpravo nahoře stáhnete PDF)
Tým autorů je partička okolo Randalla O'Reillyho z UC Davis.

Ta práce nespadla z nebe. Profesor O'Reilly se tímhle tématem zabývá přes 30 let. Jeho biologicky inspirovaný ANN model, kterému dal jméno LEABRA, byl zřejmě předmětem jeho Ph.D. dizertace obhájené v roce 1996, nebo v téže době vyvinutý. Tehdy studoval neokortex, bazální ganglia, později hippocampus, detailně přední lalok neokortexu. Leabra je dnes už historická záležitost, udržovaná ve zkompilovatelném stavu aby bylo možno provozovat starší ANN modely pro toto prostředí vyvinuté. Aktuální evoluční stupeň a následník Leabry se jmenuje Axon. Zároveň s těmito ANN modely či spíše frameworky, prof. O'Reilly píše a aktualizuje učebnici Computational Cognitive Neuroscience. Pokud mohu soudit, zdrojáky jsou na githubu s BSD licencí, učebnice je k dispozici zdarma online. Profesor O'Reilly se svým projektem zřejmě prošel už asi třemi nebo pěti univerzitami. Pokud jsem správně postřehl, nedávno v modelech přibyla nebo byla zdokonalena podpora "spiking" NN a zmíněný čerstvý paper se nově soustředí na interakci neokortexu a thalamu. Já bych svým povrchním pohledem řekl, že přihořívá :-)

Níže uvedu pár relevantních odkazů. Popravdě jsem zatím neměl čas to přečíst - prolétl jsem paper, spíš jenom názvy kapitol a namátkou pár odstavců. V dokumentaci Axonu a v učebnici jsem koukal víceméně na obsah... bože já chci víc času na čtení :-) a na hraní. Ta věc vypadá opravdu šťavnatě.

https://psychology.ucdavis.edu/people/randall-oreilly
https://en.wikipedia.org/wiki/Randall_C._O%27Reilly
https://en.wikipedia.org/wiki/Emergent_(software)
https://www.emersim.org/
https://github.com/emer/emergent
https://github.com/emer/axon
https://compcogneuro.org/
https://compcogneuro.org/axon
https://book.compcogneuro.org/

...a ten setrvalý souboj s výrobci HW komponent...

Ale NIC si přece dělá vlastní HW.

Jasně, OpenWRT komunita může "bojovat" s TP-Linkem, který nemusí mít radost, že někdo používá OpenWRT nebo DDWRT, ale NIC si dělá vlastní HW...

Jo, navrhnou si desku, mají svobodu v daném okamžiku si zvolit součástky.
Ale veškerý křemík peče a pouzdří někdo další - a co jsem viděl u jiné firmy, která si taky "dělá vlastní hardware", tak je neustálý boj s dostupností jak velkých švábů (třeba jenom konkrétní varianty pouzdra), tak prkotin typu konkrétní USB hub nebo regulátor napájení. I taková drobnost si třeba vynutí novou revizi plošáku. Během COVIDu / postCOVIDu to byl extrém, chyběly jednu chvíli i keramické kondenzátory a další banality - to už polevilo, ale třeba momentální "špatné počasí" kolem flash a RAM čipů (včetně starších modelových řad) taky není žádnej med.

Není vůbec jednoduché, vyrůst do velikosti, kdy Vaše počty kusů objednávaných součástek přitáhnou pozornost aspoň distributorů, neřku-li výrobců. A větší počty kusů čehokoli mimo naprostý mainstream nejspíš ani distributor nedrží skladem, takže pro Vás platí dodací lhůta od výrobce, což je běžně kvartál nebo půlrok... A pokud si desky neosazujete "doma", patrně máte logistiku nákupu té drobotiny a osazování desek outsourcovánu do Číny, takže zas o kousek dál mimo svoji kontrolu, z hlediska termínů a z hlediska substitucí...

K původnímu dotazu: Koukl jsem na to zběžně u sebe na Proxmoxu 9, provozuju zatím jenom tlusté VM (nikoli LXC) a řekl bych, že ten link state prostě není propojený zevnitř ven.

Zkusil jsem brctl show. To mi ukáže, jak jsou venkovní rozhraní tap<vm_id>i<int_number> přiřazena virtuálním bridgům. Příklad jména rozhraní: tap123i0 . Tato TAP rozhraní hlásí v hostitelském PVE nějaký link state. Ukazuje ho např. ifconfig nebo ethtool, mii-tool nepřekvapivě jenom vyplázne jazyk. A ten status je vždycky "up". Teda zkoušel jsem to uvnitř VM jenom ve vindózech: dal jsem na rozhraní "disable", ale zvenčí TAP interface v PVE dál hlásí "up". Potkal jsem v internetech sporadické zmínky, že někomu tento link-state-passthrough v QEMU fungoval... inu mně na virtio síťovce v Proxmoxu 9 ve VM nefunguje. On by to na rušnějším PVE mohl být dost hukot, dmesg by bylo plné "link up, link down" od TAP rozhraní. Mimochodem tyhle per-VM vnější TAP rozhraní se vytvářejí při startu VM a zanikají při ukončení=vypnutí VM. Pokud je VM vypnutý, hledal byste jeho TAP ve výpisu "brctl show" marně.

Pár odstředivých poznámek, exponenciálně off topic:

Standardně je v PVE vytvořen jenom defaultní bridge vmbr0, do kterého koukají všechny virtuály svými "tap" rozhraními. Malá nuance: pokud v konfiguraci síťového rozhraní VMka povolíte "firewall", je mezi tap123i0 a bridge vmbr0 v hostitelském PVE vřazena ještě dvojice virtuálních rozhraní, mezi kterými zřejmě číhá firewall - a aby to šlo zpřevodovat, je tam navrch ještě maličký dedicated bridge mezi dvěma porty... Podle mého hlavním účelem toho firewallu je NAT. Pokud v daném kontextu sítě není nouze o IP adresy (v prostředí privátní sítě není problém), podle mého není třeba nechávat ten firewall na TAP rozhraních zapnutý.

Ten velký globální bridge (vmbr0) forwarduje nastojato VLAN tagy, takže si VMko může vzít tag jaký chce, a otagovaný traffic prostě jenom propadne na venkovní fyzický VLAN trunk celého PVE. Tag je konfiguračním atributem VM v Proxmoxu, nalepuje ho QEMU. Uvnitř ve VM se virtio-net-pci tváří jako fyzická síťovka, o venkovním tagu nemá potuchy.

Věcně ta zpráva obsahuje naprosto banální pokus o podvůdek.

Všimněte si v textu těla zprávy (který jste zde neuvedl), že po Vás chtějí, abyste koupil jakousi poukázku za 1200 Kč, a poslal jim od toho "klíček". Naprosto přímočaře Vás chtějí pumpnout. Vaše zpáteční adresa pro odpověď se liší od té, kterou jsem viděl já = pokušitelé asi používají pro sběr medu více emailových schránek.

Ještě jeden alespoň minimálně zajímavý střípek informace je odesílající IP adresa, resp. údajná odesílající a pak ta co mi e-mail skutečně doručila. Vaše "Received" údaje se shodují s mou verzí:

Received: from vps.greenmediatechnology.com (vps.greenmedialead.in [103.154.184.159])
Received: from vps.greenmedialead.in (unknown [91.188.254.229])

Poslední potvrzený hop 103.154.184.159 je patrně skutečně v Indii. Zdálo by se, že funguje jako starý dobrý open relay.

Adresa 91.188.254.229 je podle traceroutu a podle AS-bloku (dle RIPE DB) patrně v Litvě. Teoreticky abuse@balt.net.
Ale pámbůh ví, jestli tahle hlavička není už podvržená, a i pokud není, tak odkud to přišlo ve skutečnosti, skrz to litevské mezipřistání.

Myslím, že Strážci Internetu toho teď budou mít plný inbox...

Dochází mi, že bych asi neměl přispívat k navádění začátečníků. Jsem trubka.
Zas na druhou stranu, když se člověk dočte, jak tato činnost kvete různě po světě v průmyslovém měřítku...
Celé tohle vlákno je zralé do /dev/null.

Tušímže s tímto algoritmem je problém u klientů sítě, kde nastavení čísla volajícího na "nevlastní" je žádoucí. Typu: volám ven skrz firemní PBX rovnou do JTS, ale chci aby jako číslo volajícího odcházelo číslo na můj mobil. V takových případech, na žádost klienta, umí operátor zmíněnou ochranu proti spamu potlačit...

@mzs24087 velice děkuji za uvedení na pravou míru :-)

Jenže tahle ochrana nezabírá na čísla v zahraničí. Roaming je případ, kdy hovor s CLIPem (identifikací volajícího) českého čísla přichází od zahraničního operátora a ona ochrana proti spoofingu by takový hovor zařízla.

Dovysvětlím, doufám že správně:

Podvrhy čísel se dějí skrz VoIPové operátory/gatewaye v banánových končinách. V určitém bodě seriózní telefonní síť přijme hovor, mířící do ČR, od neseriózního VoIP operátora, včetně podvrženého čísla volajícího.

Ochrana na našem území spočívá v tom, že operátoři zazdí hovor příchozí ze zahraničí s udaným číslem volajícího, o kterém místní trojka operátorů ví, že příslušný koncový terminál se v zahraničí nenachází, protože je přihlášený do některé sítě na našem území. Je to vlastně "dodatečně dodělaná autentikace volajícího čísla".

Když se SIMkou vycestujete, místní trojka v ČR Vás ve svých sítích nevidí, a spammeři v ČR mají tímto volné pole působnosti... :-(

Netvrdím, že je to tentýž problém, ale v jednom starším případě pomáhalo vypnout HW akceleraci... (konfigurovatelná volba LibreOffice)