106
Windows a jiné systémy / Re:Kontrola práce na home office
« kdy: 28. 02. 2022, 20:51:18 »
Hmm, tak za šmírování, by si zasloužil šmírovaný systém uzavřít do sandboxu a předstírat tam šum
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.
107
Hardware / Turris Omnia 2022 - nějaký posun?
« kdy: 28. 02. 2022, 20:50:27 »
Netušíte někdo, jaký je posun ve věci TURRIS OMNIA ´22? Na turris.cz jsem nenašel ani zmínku o tomto modelu, poslední zprávičku na root z podzima 2021.
108
/dev/null / nefungují stránky na wix.com
« kdy: 16. 02. 2022, 13:40:37 »
To jako kvůli mentálovi co usoudil že 2 roky starý prohlížeč nestačí na zobrazení dementí primitivní stránky kde je vše vycentrované vrchol stránky je nadpis v webovém fontu a tlačítko v v rámečku a vyjížděcí "div ze spoda" to vše v 800 kB na stránku v 70 requestech asi z 15 subdomén n 5 doménách (parastorage, wix.com, wixstatic.com wixpress.com
(a to vynechávám zablokované frof.wix.com, sentry.*.*, googletagmanager.com)
nebudou fungovat stránky na wix.com? Hlásí to
v starší prohlížeči to přesměrovává na https://static.parastorage.com/services/wix-thunderbolt/dist/deprecation-en.v5.html
(a to vynechávám zablokované frof.wix.com, sentry.*.*, googletagmanager.com)
nebudou fungovat stránky na wix.com? Hlásí to
Citace
Your Browser Is
No Longer Supported
To view this website and enjoy a better online experience,
update your browser for free.
v starší prohlížeči to přesměrovává na https://static.parastorage.com/services/wix-thunderbolt/dist/deprecation-en.v5.html
109
Server / Re:SMTP 550-5.7.1
« kdy: 12. 01. 2022, 21:00:58 »Protože jsem se v první fázi ptal co by mohl tento kód znamenat u googlu. A taky jsem automaticky pochyboval, jestli to odmítnutí tímto skutečně podle důvodu ze zprávy (důvodové zprávy).Nechapu proc dnesni decka neumi resit problemy postoupnym vylucovanim, a ocekavaj ze kdyz udelaj N chyb, tak bude jasny co pokazili :-)
Podle mého proto, že jsou zvyklé, že jim vždycky někdo řekně co špatně udělaly. Třeba Google. když na tom vyrostete, budete tak pak automaticky uvažovat i později, celkem logicky.
Až teď, v druhé fázi, mohu prozradit, že jsem odesílal mail z jiné IP, která nijak nebyla spjata s HELO ani MAIL FROM a porušila SPF. No a mě zajímalo, jestli důvodem mohlo být fail result SPF, nebo neshodu resolvování dns a záznamu a odesílající ip.
110
Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu. nestavit barák od střechy
« kdy: 12. 01. 2022, 00:01:37 »
A především (možná v rámci zjednodušení a pochopení) by bylo vhodné normalizovat hledané výrazy...
To znamená místo oddělených proměnných handles a topics mít
jedno pole [ *handles , *topics] neboli [john,johnathan, town, hometown] a k nim příslušně pole náhrad [href-h-john, href-h-jonathan, href-t-town, href-t-hometown]
Až pochopí tazatel, kde je problém, může pokračovat dál a pustit se do složitějších věcí, jako callbackové nahrazování
Mimochodem: není náhodou správně Jonathan (ostatně třeba i správně je errorneous). Tady je to snad jen pro příklad.
To znamená místo oddělených proměnných handles a topics mít
jedno pole [ *handles , *topics] neboli [john,johnathan, town, hometown] a k nim příslušně pole náhrad [href-h-john, href-h-jonathan, href-t-town, href-t-hometown]
Až pochopí tazatel, kde je problém, může pokračovat dál a pustit se do složitějších věcí, jako callbackové nahrazování
Mimochodem: není náhodou správně Jonathan (ostatně třeba i správně je erro
111
Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu
« kdy: 11. 01. 2022, 23:49:48 »Máš a nemáš pravdu. Pravděpodobně mu vznikne jiný než zamýšlený výsledek (smutně mu tam bude koukat "town"). A zároveň se to zacyklí. (ale to spolu nesouvisí, řekl bych že zjednodušeně zacyklení závisí na vztahu náhrada-pattern a neočekávané nahrazování shodou substringů patternů)SO odpoved ak by niekto potreboval do buducna:Než jsem vám stihl odpovědět, že máte neúplné zadání, tak jste si našel odpověď. Zrada, proč vaše zadání nebude fungovat je nejasná definice chování replace
112
Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu; programátor si musí určit pořadí
« kdy: 11. 01. 2022, 23:39:17 »
S dovolením jsem vynechal stranu 2 a stranu 3, takže jsem přišel o baladu o kalhotech a větrech ze severu. (Možná si to přečtu až budu potřebovat upustit páru)
Ale tohle má být nějaká vysokoškolská úloha, kdy máš vymyslet algoritmus, nebo jen potřebuješ poradit existující funkci z knihovny? (Klíčem implementace je nezamotat se v opakujících subvýrazech, jak v vyhledávacím kroku, tak v nahrazovacím kroku-v případě že by se nahrazovalo imperativně v cyklu. Radši bych slovo krok uplně vynechal)
MŮJ ROZBOR
Já bych přispěl druhým možným algoritmem - v první fázi provedu jen vyhledání. Vzniká problém, že může vzniknout víc řešení vyhledání výrazů. Nabízí se hledání podle nejdelšího, ale pak stále tu zůstane problém, co třeba s patterny "bene" a "nebe" pro slovo "benebe, be". Tohle pořadí musí si určit programátor sám. Jako bonus tam můžeme přihodit pattern "be"
Fáze nahrazovací musí proběhnout "transakčně". Třeba nejdřív určením ochranného znaku třeba #, potom nahrazením # třeba za #0. Pak nahrazením patternů za #1, #2.... (#N - N=přirozená čísla=bez nuly) Pak nahrazením #N za nahrazené varianty a nakonec vrácením #0 za #...
Ale třeba zadání může být i takové, aby se nahrazovalo donekonečna... V tom případě právě transakčnost je nežádoucí a může z toho vzniknout turingův stroj, pokud se nepletu. Radši to típnu
A jinak bych poradil funkci preg_replace_callback a její ekvivalenty. Možná by ani nebyla potřeba nahrazovací část řešena být callbackově.
Ale tohle má být nějaká vysokoškolská úloha, kdy máš vymyslet algoritmus, nebo jen potřebuješ poradit existující funkci z knihovny? (Klíčem implementace je nezamotat se v opakujících subvýrazech, jak v vyhledávacím kroku, tak v nahrazovacím kroku-v případě že by se nahrazovalo imperativně v cyklu. Radši bych slovo krok uplně vynechal)
MŮJ ROZBOR
Já bych přispěl druhým možným algoritmem - v první fázi provedu jen vyhledání. Vzniká problém, že může vzniknout víc řešení vyhledání výrazů. Nabízí se hledání podle nejdelšího, ale pak stále tu zůstane problém, co třeba s patterny "bene" a "nebe" pro slovo "benebe, be". Tohle pořadí musí si určit programátor sám. Jako bonus tam můžeme přihodit pattern "be"
Fáze nahrazovací musí proběhnout "transakčně". Třeba nejdřív určením ochranného znaku třeba #, potom nahrazením # třeba za #0. Pak nahrazením patternů za #1, #2.... (#N - N=přirozená čísla=bez nuly) Pak nahrazením #N za nahrazené varianty a nakonec vrácením #0 za #...
Ale třeba zadání může být i takové, aby se nahrazovalo donekonečna... V tom případě právě transakčnost je nežádoucí a může z toho vzniknout turingův stroj, pokud se nepletu. Radši to típnu
A jinak bych poradil funkci preg_replace_callback a její ekvivalenty. Možná by ani nebyla potřeba nahrazovací část řešena být callbackově.
113
Server / Re:Odchozí pošta padá do spamu ; guessSPF ; ? shoda From,MAIL FROM , HELO
« kdy: 11. 01. 2022, 23:18:23 »
No tak mě třeba překvapilo, že to vypadá, že seznam absolutně neprovádí žádné kontroly.
1.V hlavičce (v webovém rozhraní zkoušeno jen) jsou jen hlavičky od odesilatele a POUZE "RECEIVED: from+by". Žádné Authentication results, spam-score... (Vím že může prezentovat uživateli e-mail v originální příchozí formě, BFU by tomu stejně nerozuměli)
2. Zároveň projde i mail s porušeným spf, ale platným DKIM (ano vím, že se uvádí, že stačí aby prošlo jedno), nechce se mi to už testovat
Teorie 1(té benevolentnosti, ne absence hlaviček) je, že dokud mail nikdo neoznačí jako spam, tak daná IP/doména se vůbec nedostane do databáze a nedějí na ní žádné kontroly.... Což ale podle mě odporuje denodení realitě, kdy maily jsou posílané z napadených koncových stanic.
k google: (brát s rezervnou ; na základě 1 prošlého a 1 neprošlého mailu)
3. nevím to jistě, ale google mail si hlídá SPF (a zároveň platný DKIM není postačující podmínka). Byl tam ještě třetí faktor- špatné HELO (doména neodpovídala IP).
4. Ale zároveň google nekontroluje PTR kolečko (tedy neexistující PTR), ale bylo splněno MAILFROM+HELO->A
Kromě toho taky google dělá jakousi SPF kontrolu i když není definovaná. Pozná se to podle "best guess" - pravděpodobně jde o nepsané pravidlo jestli ip adresa domény (v tomto případě třeba bylinkyodsoudruha.cz) se rovná ip adrese (modulo /24) - skutečně se lišili v posledním bajtu)
Zvláštní praxe :
- (1) proč se uvádí "domain of wy1233@he-wd120.wedos.net" (ta část před @). V received je jen část za @. V return-path je celá adresa wedos.
- From a MAIL FROM se liší. Jako vím, že to je jasný příklad "outsourcingu posílání mailů/remailingu. Nic proti tomu nemám. Ale zaprvé proč (2) mě na to neupozorní Desktopový klient a taky proč (3)se napoužije na mail from: bylinkyodsoudruha.cz
(4) JE snad někde dané, že HELO a doménová část MAIL FROM se mají rovnat? Proč to tak je? Existují protipříklady, že HELO je interní název stroje (typicky mail.hosting.cz nebo ještě lépe název z PTR ) a From : & MAIL FROM jsou shodné skutečné adresy zákazníka hostingu. Jako jasné, je že HELO má být dohledatelný název stroje (což je ve všech případech splněno), volitelně(!!!) i rovný PTR záznamu.
1.V hlavičce (v webovém rozhraní zkoušeno jen) jsou jen hlavičky od odesilatele a POUZE "RECEIVED: from+by". Žádné Authentication results, spam-score... (Vím že může prezentovat uživateli e-mail v originální příchozí formě, BFU by tomu stejně nerozuměli)
2. Zároveň projde i mail s porušeným spf, ale platným DKIM (ano vím, že se uvádí, že stačí aby prošlo jedno), nechce se mi to už testovat
Teorie 1(té benevolentnosti, ne absence hlaviček) je, že dokud mail nikdo neoznačí jako spam, tak daná IP/doména se vůbec nedostane do databáze a nedějí na ní žádné kontroly.... Což ale podle mě odporuje denodení realitě, kdy maily jsou posílané z napadených koncových stanic.
k google: (brát s rezervnou ; na základě 1 prošlého a 1 neprošlého mailu)
3. nevím to jistě, ale google mail si hlídá SPF (a zároveň platný DKIM není postačující podmínka). Byl tam ještě třetí faktor- špatné HELO (doména neodpovídala IP).
4. Ale zároveň google nekontroluje PTR kolečko (tedy neexistující PTR), ale bylo splněno MAILFROM+HELO->A
Kromě toho taky google dělá jakousi SPF kontrolu i když není definovaná. Pozná se to podle "best guess" - pravděpodobně jde o nepsané pravidlo jestli ip adresa domény (v tomto případě třeba bylinkyodsoudruha.cz) se rovná ip adrese (modulo /24) - skutečně se lišili v posledním bajtu)
Kód: [Vybrat]
spf=pass (google.com: [b]best guess record[/b] for domain of wy1233@he-wd120.wedos.net designates 81.01.0.140 as permitted sender) smtp.mailfrom=wy1233@hc-wd120.wedos.netZvláštní praxe :
- (1) proč se uvádí "domain of wy1233@he-wd120.wedos.net" (ta část před @). V received je jen část za @. V return-path je celá adresa wedos.
- From a MAIL FROM se liší. Jako vím, že to je jasný příklad "outsourcingu posílání mailů/remailingu. Nic proti tomu nemám. Ale zaprvé proč (2) mě na to neupozorní Desktopový klient a taky proč (3)se napoužije na mail from: bylinkyodsoudruha.cz
(4) JE snad někde dané, že HELO a doménová část MAIL FROM se mají rovnat? Proč to tak je? Existují protipříklady, že HELO je interní název stroje (typicky mail.hosting.cz nebo ještě lépe název z PTR ) a From : & MAIL FROM jsou shodné skutečné adresy zákazníka hostingu. Jako jasné, je že HELO má být dohledatelný název stroje (což je ve všech případech splněno), volitelně(!!!) i rovný PTR záznamu.
114
Server / SMTP 550-5.7.1
« kdy: 11. 01. 2022, 22:41:23 »
Všiml jsem si, že smtp servery přijmou celou zprávu, a až na závěr se dozvím, jestli mail byl přijat(serverem.), i když teoreticky by mohly odpověd už na základě HELO,M-FROM, RCPT. Asi to je z důvodu vytěžit co nejvíc dat.
Dá se poznat z tohoto kódu, význam této chyby? Podle popisu vyplývá, že daná IP není způsobilá odeslat maily (bez ohledu na doménu MAILFROM) Ale je to skutečně tak? Mohlo jít totiž o dvě příčiny: nesouhlas domény HELO s odesílající IP a porušení SPF pro MAILFROM+HELO (našel jsem si v RFC, že SPF může kontrolovat obojí, ale je to tam psané schválně, že vlastní mechanismus SPF je obecně specifikovaný pro nějakou doménu <domain>, ale jen v sekce 2.x věnuje tomu, jestli kontrolovat HELO a MAILFROM, jakém pořadí a i docela rozumně zdůvodněné)
Dá se poznat z tohoto kódu, význam této chyby? Podle popisu vyplývá, že daná IP není způsobilá odeslat maily (bez ohledu na doménu MAILFROM) Ale je to skutečně tak? Mohlo jít totiž o dvě příčiny: nesouhlas domény HELO s odesílající IP a porušení SPF pro MAILFROM+HELO (našel jsem si v RFC, že SPF může kontrolovat obojí, ale je to tam psané schválně, že vlastní mechanismus SPF je obecně specifikovaný pro nějakou doménu <domain>, ale jen v sekce 2.x věnuje tomu, jestli kontrolovat HELO a MAILFROM, jakém pořadí a i docela rozumně zdůvodněné)
Kód: [Vybrat]
... po odeslání DATA :()
S:
550-5.7.1 [7.8.1.2] The IP you're using to send mail is not authorized to
550-5.7.1 send email directly to our servers. Please use the SMTP relay at your
550-5.7.1 service provider instead. Learn more at
550 5.7.1 https://support.google.com/mail/?p=NotAuthorizedError gsmtp
115
Sítě / Re:Může PTR záznam mířit na localhost?
« kdy: 07. 01. 2022, 22:46:02 »
To já vím, ale myslel jsem, že existují implementace, které zápis 12.22.3.45/20 vůbec nedovolí (třeba v inputu administračního rozhraní), Nebo ho auto-opraví na 12.22.0.0/20 před vložením, nebo ho nechají, ale provádějí ještě jeden AND (zbytečně,když to stačilo udělat ručně jednou předtím), nebo nedělají nic a pak hodnota 12.22.3.45/20 nikdy "nebude fungovat"
A druhá věc - ty rozsahy, to se mi zdálo, že je nějaká cisco notace. Nebo jsem to viděl jako možný formát nějakého blacklistu, kde bylo na výběr z možností formátů
1.2.3.11-1.2.3.26
1.2.3.11/255.255.255.240
1.2.3.11/28
(1.2.3.11/255.255.23.71 . snad jen tohle jsem neviděl )
A druhá věc - ty rozsahy, to se mi zdálo, že je nějaká cisco notace. Nebo jsem to viděl jako možný formát nějakého blacklistu, kde bylo na výběr z možností formátů
1.2.3.11-1.2.3.26
1.2.3.11/255.255.255.240
1.2.3.11/28
(1.2.3.11/255.255.23.71 . snad jen tohle jsem neviděl )
116
Server / Re: stejné reverzní DNS jméno pro víc IP , vysvětlení jedním strojem svíceIP
« kdy: 07. 01. 2022, 22:30:13 »
Teď mě to napadlo, hypoteticky, kdyby to byl jeden počítač (stroj, ne služba) co má více IP adres (klidně i na stejném rozhraní), tak by ta asimetrie více IP->jedno jméno asi dávala smysl (i když to je jen jedna půlka problému-druhá je vrácení jedné IP pro to doménové jméno). "Prostě by měl jedno hostname v /etc/hostname" (velké zjednodušení!)
Jinak moc pěkné vysvětlení, je vidět, že to jde, když chcete
Jinak moc pěkné vysvětlení, je vidět, že to jde, když chcete
117
Sítě / Re:Může PTR záznam X.Y.W.Z mířit na CNAME R.0/T.Y.X ? + bity v CIDR
« kdy: 07. 01. 2022, 21:58:21 »
_mbily, díky za vysvětlení, teď vidím, že to vlastně je smysluplné
No tím jsem chtěl říct,že samotné označení A.B.C.D/N může mít někdy různé(i neplatné interpretace, například 12.34.55.56/16 může být nevalidní nebo aspoň nikdy nematchující) a plus že může znamenat víc věcí - tys přidal další - specifikaci vlastní adresy stroje a sítě v jednom.
Tomuto vubec nerozumim. Mozna jen reknu, ze 12.34.56.3/24 se pouziva jako oznaceni IP adresy a site zaroven (sit je 12.34.56.3 oktetovyAND s 255.255.255.0, takze na poslednim oktetu nezalezi)
118
Server / neshody v PTR (N:1)
« kdy: 07. 01. 2022, 21:42:06 »
Našel jsem tedy jeden příklad:
{85.207.4.158+85.207.59.62} -PTR-> cnc2-smtp1.cncenter.cz -A-> 85.207.59.62 (-PTR-> cnc2-smtp1.cncenter.cz )
Takovéhle "smyčky" jsou povolené? (že víc IP má stejné reverzní jméno, smyčka to není, ale trychtýř)? Zajímá mě to na víc úrovních (například nikdo nebrání providerovi v Brazílii nastavit stejné doménové jméno jeho zákazníkovi jako má zákazník v hostingu v japonsku). To ale není tento případ očividně, když se shodují na /16,/15,/14.... (a ostatně v ASN blok je pro /16)
A nebo je tam chyba, že to vrací jen jednu IP adresu, ale mělo by (aspoň obě)?
Nebo je to situace naprosto v pořádku? Nebo může tato podivnost pramenit, že neexistuje na světě jen RR typu A?
{85.207.4.158+85.207.59.62} -PTR-> cnc2-smtp1.cncenter.cz -A-> 85.207.59.62 (-PTR-> cnc2-smtp1.cncenter.cz )
Takovéhle "
A nebo je tam chyba, že to vrací jen jednu IP adresu, ale mělo by (aspoň obě)?
Nebo je to situace naprosto v pořádku? Nebo může tato podivnost pramenit, že neexistuje na světě jen RR typu A?
119
Server / Re:Odchozí pošta padá do spamu
« kdy: 07. 01. 2022, 21:19:26 »... IP adresa přeložená na záznam... Nebo ho přeloží zpět na IP adresu a zkoumá, zda mezi přeloženými IP adresami je i ta původní IP adresa klienta.To mi nedává smysl, z logiky věci by reverzní doménové jméno se mělo přeložit vždy na tu stejnou IP, jako pro kterou bylo reverzní doménové jméno vyhledané. (Jsou ale IP adresy, které reverzní jméno nemají, tam ale chybí už první krok)
(Pokud ses neuklepl a nemyslel to jeden krok posunutě / záměna IP a jména: přeložení doménového jména na ip adresu a té reverzně na reverzní jméno.)
A nebo může ověřovat, zda doména z toho reverzního záznamu se objeví v EHLO hlavičce, kterou klient pošle. Asi protože pro spammera je hrozně obtížné zjistit si reverzí DNS záznam počítače, odkud zkouší spam odeslat – musel by udělat jeden DNS dotaz navíc…Čili kvůli tomuhle ty SMTP provádějí ty nestandardní filtrace na výskyt čísel s pomlčkami? (V kombinaci s tou kontrolou rovnosti, jinak by tam rovnou mohl napsat HELO domena.com)
Ten dotaz původně mířil na to, jestli je přípustné mít v HELO hlavičce například mailer.firma.cz, když její zpětné přeložené jméno (mailer.firma.cz -> IP -> reverzní jméno) je třeba s1.firma.cz nebo rovnou outbound.mailgun.net nebo outlook.com. Což podle mě ale je legitimní, když někdo posílá maily outsourcovaně.
120
Server / Re:Odchozí pošta padá do spamu
« kdy: 07. 01. 2022, 19:42:05 »
Pozor mám tam chybu! Zaměnil jsem HELO za MAIL FROM.
Jo a taky je mi divné, proč se uvádí pořád jako port (MSA-MTA/ MTA-MX) 25? Vždyť to snad nemůže být od roku 2016 pravda....
Jo a taky je mi divné, proč se uvádí pořád jako port (MSA-MTA/ MTA-MX) 25? Vždyť to snad nemůže být od roku 2016 pravda....
