Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák (forum)

Stran: [1] 2 3 ... 20
1
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 17. 12. 2025, 15:43:28 »
Nevím, kdo z vás by co a kam řadil, ale veřte, že jen greylisting sám o sobě vyřeší vysoké desítky procent spamu.
Já nechápu, že pořád někdo tenhle argument může použít. Vytažení síťového kabelu ze serveru vám vyřeší 100 % spamu. proč se tedy takové řešení nepoužívá? Protože kritérium „kolik spamu to zastaví“ je samo o sobě k ničemu. Stejně důležité je i to, jaké to má negativní dopady – kolik legitimních e-mailů to zastaví, kolik jich to a o kolik zdrží. To zdržení začíná být podstatný faktor, protože se bůhví proč dostává do módy dvoufaktorová autentizace přes e-mail s krátkou dobou platnosti kódu.

Samozřejmě se ty poměry mohly za poslední roky změnit ale pochybuji, že se změnily nějak opravdu zásadně.
BobTheBuilder právě psal o tom, jak je to dnes. Oponovat tomu tím, že dříve to bylo jinak a pochybujete, že se to změnilo, je to trochu slabý argument.

2
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 17. 12. 2025, 15:36:18 »
Zatímco u papírové pošty to tak jak to popisujete zhruba odpovídá, u e-mailu ve většině případů komunikuje MUA odesílatele s MSA/MTA a ten přímo s MTA/MDA a ten pak s MUA příjemce. Samozřejmě tam může být nějaký mezikrok ale víc se tam dějí akce na straně MTA a MUA, než předávání mezi servery.
To přímé předání je ideální schéma, které je ale v praxi často komplikovanější. Může být komplikovanější i na straně odesílatele, a na straně příjemce je to velmi časté – e-mail přijme MTA, na který směruje MX záznam. Ale ten to klidně může přeposlat jinému MTA, protože první MTA může být jen nějaká brána vystavená do internetu. Druhý MTA je pak třeba antispam, předá to třetímu serveru a teprve ten třetí server doručuje do schránky.

Navíc tam hrají roli další protokoly, jako např. DNS, které v prostředí reálné pošty nemají přímou analogii.
Ano, ale to ve spoustě případů není podstatné. Analogie samozřejmě neznamená, že je to stoprocentní shoda. Pokud máte lepší analogii k e-mailu, než je pozemní pošta, sem s ní.

Zatímco fyzický dopis projde přes několik dopravních prostředků s různou mírou rychlosti a frekvence pošt/třídíren, v závislosti geografické lokalitě, tak e-mail jde ve většině případů (pohledem protokolu SMTP) napřímo bez ohledu na geografii.
Za prvé to obvykle není podstatné, za druhé i e-mail je navržen tak, že to může jít takto a často i jde.

BTW: Už se mi stalo, že pohled ze zahraničí dorazil s několikaměsíčním zpožděním (i víc než po roce). U e-mailu se tohle téměř jistě nestane.
Jistě, ale to snad každému dojde, že analogie je jen analogie a že tam žádné zdržené dané fyzickou přepravou na velkou vzdálenost není.

A pokud doručení e-mailu na server příjemce trvá víc než jednotky minut, tak je "něco špatně" a je legitimní řešit, kde je problém.
Však se to tu také řeší.

3
Pohled na e-mail jako na analogii papírové pošty silně nedoporučuji, protože na mnoha úrovních funguje hodně odlišně.
Mně teda naopak připadá užitečné tu analogii používat. Protože občas si někdo o e-mailu myslí bůhví co, přitom si to stačí představit jako klasickou poštu. Máte nějakou obálku, na té je adresa, tu předá odesílatel prvnímu pošťákovi, ten to předá dalšímu a takhle to putuje až k poslednímu pošťákovi, který vám obálku vhodí do schránky. To sedí i na e-mail a osvětlí to spoustu věcí – třeba to, že se doručování řídí adresou na obálce a ne tím, co je napsané uvnitř. Nebo to, že si e-mail může předávat několik „pošťáků“, než e-mail doputuje do cílové schránky. I to, že odesílatel speciálním způsobem předá e-mail prvnímu poštovnímu serveru, poštovní servery si to pak předávají pořád stejně, a až poslední server uloží e-mail do schránky (což je opět odlišná situace od předávání e-mailů mezi servery). Sedí i to, že doručený e-mail má adresát k dispozici ve schránce, a je na něm, kdy se do schránky podívá. Ta analogie funguje pro popsání základních principů e-mailu celkem dobře.

4
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 17. 12. 2025, 09:04:55 »
Ale greylisting v dnes moc nedává smysl - od potíží s velkými hráči, kteří druhý pokus nutně neudělají za stejné IP adresy, po časové limity (když druhá strana udělá druhý pokus moc brzo - měli jsme 30s a někdo měl v Kerio serveru 20s).
Spousta opatření tzv. proti spamu nedává smysl. A zrovna greylisting bych řadil k těm opatřením s menším smyslem, protože na straně spammera bylo triviální ho obejít.

Dnes se hraje na SPF a DMARC - a to ty hacknuté DSL modemy v Brazílii nebudou mít dobře.
Docela účinné je nepřijímat maily z neexistujících domén (to spolu se striktním SPF spam omezí na hacknuté účty legitimních serverů).
Kdo nemá podepsané maily DKIM a nastavené SPF, dostává od Googlu trestné body (jde do spamu, pokud se vůbec doručí), takže tyto požadavky můžete klidně aplikovat taky.
Doufám, že se dočkám toho, že půjde striktně aplikovat DMARC politiky a nebude člověk pořád narážet na to, že je to někde nastavené špatně.

Proti spamu raději DKIM, ten zajišťuje identitu odesílatele. SPF zajišťuje identitu „pošťáka“, posledního serveru zodpovědného za doručení e-mailu, který je uveden v obálkové adrese. Je to dobré k tomu, aby se e-maily o nedoručitelnosti neposílaly na falešné adresy. Ale používat SPF pro validaci From z e-mailu je historický omyl.

5
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 17. 12. 2025, 08:49:40 »
Ale taky to mohl napsat/rozepsat/uložit a poslat, až bude mít přístup k internetu.
To by mělo být vidět v hlavičkách e-mailu – první Received by měla být právě o tom, že první server přijal zprávu od klienta.

A tipoval bych, že i datum v hlavičce e-mailu (to, které se zobrazuje jako datum odeslání) bude datum prvního serveru. Protože klient může mít čas jakkoli špatně, u serveru je přeci jen daleko větší jistota, že bude mít čas správně. Hlavně dříve to tak bylo, dnes už má většina klientů také čas synchronizovaný.

Pozor také na různá časová pásma – musíte si všechny časy v hlavičkách převést na stejné časové pásmo. Každý server si tam dá časové pásmo, jaké se mu hodí – a i když odesílatel a příjemce jsou v ČR, časová pásma v hlavičkách mohou být různá.

Tak byl odeslán asi v 9 dopoledne (podle hlavičky), ale čas v přišlé poště je 18 hodin toho dne(je to v hlavičce a souhlasí s časem přišlé pošty), ale mě se zobrazil až večer. No tak na nového Asánže jsem zrovna narazil nemusel, dopr. to se mi nehodí:D.
Jestli tam je několikahodinová prodleva mezi odesláním e-mailu a jeho doručením vašemu serveru, a pak ještě několikahodinová prodleva mezi doručením vašemu serveru a doručením do schránky, máte fakt smůlu…

Jestli je dlouhá prodleva mezi tím, když e-mail přijme váš server, a okamžikem, kdy je pro vás e-mail dostupný v poštovním klientovi, zaměřil bych se na antispam a antivir na vašem serveru. Jestli tam není nějaká operace, která by neprocházela, timeoutovala, zkoušela se třeba opakovaně po nějaké době a e-mail by se dál propustil až po několika neúspěšných pokusech. Ale je divné, proč by se to dělo jen u některých e-mailů. Napadají mne jen hodně divoké scénáře.

Ideální by bylo, kdybyste sem mohl hlavičky nějakého takového zpožděného e-mailu vložit. S co nejmenší cenzurou, někdy může být stopa v něčem zdánlivě nepodstatném.

6
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 16. 12. 2025, 19:55:17 »
Greylisting je málokdy nastaven na víc, než nízké desítky minut. Ono ani nemá smysl nastavovat ho na víc; k odfiltrování velké části spammerů stačí těch minut klidně jen pět nebo deset. Z praxe. Navíc z greylistu odesílatel většinou přechází do whitelistu a minimálně v dohledné době pak už greylistován není.
Ono ani tak nejde o to, na jaký čas je nastaven greylisting – původně tam nebýval žádný čas, prostě stačil druhý pokus. Je možné, že někde už je greylist aplikován tak, že druhý pokus nesmí přijít rychle.

Podstatné je to, že odesílatel se zpravidla do opakovaného pokusu o odeslání nehrne hned, chvíli počká – aby cílový systém měl šanci se spravit a e-mail přijmout. A rozestupy těch pokusů se obvykle postupně prodlužují. Takže podruhé to odesílatel zkusí třeba za 5 minut po prvním pokusu o odeslání, potřetí za 15 minut a počtvrté za hodinu.

No a pokud těch odesílajících serverů je víc, tak se třeba s pěti odesílajícími servery rázem dostanete na několik hodin.

No a vhledem k tomu, že servery Googlu obvykle bývají whitelistovány, možná si Google zbytečně nekomplikuje život tím, aby byl hodný na uživatele greylistu.

Každopádně pro vyřešení tohoto problému je potřeba zajistit si přístup k logům přijímajícího MTA a porovnat časy, kdy byl server odeslán uživatelem GMailu (to bude čas v hlavičkách e-mailu), kdy došlo k prvnímu pokusu o doručení e-mailu MX serveru pro danou doménu, kdy byly další pokusy o doručení a kolik jich bylo, kdy MX server e-mail skutečně přijal, a kdy pak byl doručen do schránky uživatele. Protože ten problém bude někde na straně příjemce – nejspíš greylisting, ale také to může být třeba nějaká zasekávající se antispamová či antivirová kontrola nebo něco takového.

7
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 16. 12. 2025, 08:54:10 »
Není to na straně odesílatele (GMailu), je to na straně příjemce. Pravděpodobně greylist – poprvé e-mail odmítne a očekává, že legitimní odesílatel e-mail zkusí odeslat znovu, zatímco spammer se na to vykašle. Obvykle v datech, podle kterých se posuzuje, zda je e-mail stejný, figuruje i IP adresa odesílatele. Cloudoví odesílatelé se někdy snažili další pokusy o odeslání dělat z toho samého serveru, aby se přes greylist dostali brzy. GMail je ale u spousty serverů na whitelistu, tak je možné, že se o tohle nesnaží. Podobně by se to mohlo s greylistem stát i kdyby odesílatel zkoušel jednou komunikaci přes IPv4 a jednou přes IPv6. Případně kdyby měl příjemce více serverů se stejnou prioritou, ale to by pak byl problém u všech odesílatelů.

Se zabezpečením odesílatele to nemá nic společného. Pro odesílatele je naopak nejbezpečnější e-mailu se co nejdřív zbavit, tj. odeslat ho.

8
Je otázka proč používat Tailwind místo MUI
Vy jste psal, že používáte Tailwind. Použijte si, co chcete. Akorát je to každé něco jiného – Tailwind CSS je knihovna utilitních tříd a nástroje pro jejich zpracování, MUI je knihovna komponent.

Navíc kažý kus kódu z Tailwindu, který použíju, tak z něj ještě musím abstrahovat utility classes do globals, protože nemůžu mít napříč projektem rozházené na divoko třeba barvy, různé rozměry inputů a dalších prvků, padding atp. Uff...
Nebo se můžete naučit používat Tailwind správně.

9
PWA by už mělo jít dát do Google Play přímo, do Apple Store byste musel použít nějaký wrapper. Mikroanimace se s Tailwindem samozřejmě dělat dají.

10
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 28. 11. 2025, 16:08:11 »
Takže už jste vzdal snahu předstírat, že píšete něco k tématu, a už jenom trollíte. Hm, nepřekvapuje mne to.

11
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 28. 11. 2025, 12:52:03 »
O updatech jsem prave nic nepsal :)
Ano, updaty jsou jedna z mnoha věcí, na které jste zapomněl.

Smyslem me poznamky bylo podotknout, ze samotna velikost tabulky ani rychlost vyhledavani v ni nejsou argumenty proti podrobnejsimu/novemu/ja nevim jakemu parcelovani ipv4 adres.
Jenže jste to nijak nedokázal. Navíc se vaše teorie rozchází s realitou, kdy v době, kdy se začalo projevovat, že IPv4 adresy došly, se začal adresní prostor IPv4 rychleji fragmentovat – a některé páteřní routery v té době nebyly schopné pojmout takovou routovací tabulku, jakou by měly mít, protože se prostě do jejich paměti nevešla.

Každopádně i kdyby se dnes použily všechny IPv4 adresy, problém jejich nedostatku by to nevyřešilo. No a routovací tabulku po jednotlivých záznamech pro IPv6 tu snad nebude obhajovat nikdo, protože exabajtové paměti pro uložení 2×1018 záznamů se dnes stále shání docela špatně.

12
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 28. 11. 2025, 11:32:02 »
Proc se tak bojite si priznat, ze jste se mylil a postujete sem takove halucinace?
Co přesně je na mém komentáři halucinace? Proč se vy tak bojíte přiznat, že jste se mýlil?

13
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 28. 11. 2025, 10:39:10 »
Nepiste nesmysly. Sahnuti do pole, kdyz je k dispozici index je dostatecne rychle.
Když to nechápete u specializovaných routerů, třeba to pochopíte, kdyby to routování dělal klasický počítač s běžným procesorem. Bude stejně rychlé, když musí procesor načíst data z hlavní paměti, jako když je načítá z L1 cache, L2 cache? Nebude, že? A mají dnešní procesory L1 cache o velikosti 16 GiB (když jste si zvolil takovouhle nesmyslnou velikost)?

Historky Bedricha Krause von Zillerguta me nezajimaji.
Naštěstí jste nenavrhoval IPv6. Jeho autoři se na rozdíl od vás dokázali poučit z minulosti a navrhli IPv6, aby se chyby IPv4 neopakovaly.

14
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 28. 11. 2025, 08:29:31 »
Tudiz o velikosti tabulky ani o rychlosti prohledavani to neni.
Samozřejmě to o rychlosti prohledávání je. Také musíte počítat s tím, že se ta routovací tabulka mění. A hlavně – popisujete, že dnes máme technologii, která by to bez problémů zvládla – jenže ten problém nastal před více než dvaceti lety. Takže co máme dnes je irelevantní. Je ale logické myslet dopředu a nezadělat si na stejný problém do budoucna.

Jinak nekoliduje nahodou dnesni pozadavek na maximalni roztrideni vsech sitovych kramu do separatnich vlan s mechanizmem ipv6 pro delegaci prefixu? Jak pracne je nastavit si subdelegaci casti ipv6 rozsahu od poskytovatele do nekolika urovni vnitrnich segmentu site? Muzou ty kusy ipv6 rozsahu byt ruzne velke?
Nekoliduje. Snadné. Ano, můžou.

15
Sítě / Re:Jak získat vlastní IPv6 rozsah?
« kdy: 27. 11. 2025, 22:15:32 »
Začíná se to tu trochu přiostřovat, tak to pojďme nakolejit zpátky do věcnější diskuse:
Psaním nesmyslů to zpět do věcnější diskuse nenakolejíte.

Zopakuji že můj point je v tom, že IPv6 nic běžnému uživateli nepřináší a naopak pro něj přináší zbytečné komplikace navíc.
Nemáte pravdu.

Druhý point je v tom, že hlavní "selling point" IPv6 že každé zařízení může mít svou unikátní tralou veřejnou adresu bohužel nefunguje pokud neprovozujete vlastní AS.
Jenže hlavní selling point IPv6 je něco jiného – že každé zařízení může mít své veřejné adresy. To je hodně blízké  původnímu záměru IPv4 – liší se jen v tom, že IPv4 počítalo primárně s jednou IPv4 adresou na zařízení, IPv6 počítá s tím, že zařízení bude mít běžně IPv6 adres víc.

O trvalosti nikdy nebyla řeč. Naopak IPv6 přišlo s rozšířeními, které se používají aby/když IPv6 adresy nejsou přiřazené moc dlouho.

Unikátnost tak nějak plyne z té veřejnosti, mít duplicitní veřejné adresy by bylo trošku k ničemu.

Pane Jirsák, nic ve zlém, ale žádný router v internetu nedrží a ani nemůže znát celou routovací tabulku internetu. Ono totiž stačí u border routeru když zná tabulky vlastního AS a okolních AS ke kterým je připojený. Představte si že to fungovalo už v dobách kdy tyhle routery měly paměť v řádech jednotek kB.
Pokládal jsem za jasné, že píšu o nejhorším možném případu. Vy byste chtěl přidělování IPv4 adres dál dělit, přidělovat menší a menší rozsahy. (K tomu by vedlo to vaše rozdělování nepoužitých zbytků rozsahů.) Přinejhorším by tedy byly přiděleny jednotlivé IP adresy. No a teď si představte router někde na páteři, který má klidně jenom dvě rozhraní. Ale shodou náhod to vyjde tak, že všechny liché adresy vedou na jedno rozhraní a všechny sudé na druhé rozhraní. Takže by  ten router musel mít v routovací tabulce záznamy pro každou IP adresu. Nezapomeňte, že je to shoda náhod – takže to nejde popsat pravidlem, zítra se to může změnit a některé IP adresy, které vedly doprava, nově povedou doleva.

Ano, samozřejmě v praxi nic takového nikdy nenastane. Ale je to směr, kterým to přidělování stále menších a menších rozsahů vede. K růstu routovacích tabulek. A pamětí RPi opravdu neargumentujte – na páteřních routerech potřebujete řádově jiný routovací výkon, než který vám poskytne RPi.

A malý kvíz na závěr : Kolikrát je větší routovací tabulka se stejným počtem záznamů pro protokol IPv4 a IPv6 ?
Vy si představujete routovací tabulku jako seznam všech IP adres, kde je u každé položky uvedeno, kam se má routovat, že? Tak přesně takhle routovací tabulka nikdy nevypadá. Routovací tabulka může mít různé podoby, ale tu vaši ne.

To důležité, co byste si z toho měl odnést, je to, že v routovací tabulce nejsou konkrétní IP adresy, ale bloky IP adres, které mají společný prefix. Takže počet záznamů v routovací tabulce nezáleží na počtu přidělených adres, ale na počtu přidělených bloků a na tom, zda dokážete menší bloky sdružovat do větších, protože v daném routeru je shodou okolností cesta vedoucí ke všem blokům tvořícím větší blok stejná. No a abyste tohohle docílil, potřebujete přidělovat velké bloky, aby v nich byla rezerva do budoucna. Až budete potřebovat další IP adresy, vezmete je z té rezervy. A v routovacích tabulkách se to nijak neprojeví, protože routován bude pořád ten stejný blok.

Stran: [1] 2 3 ... 20