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 - Vietnamka

Stran: 1 ... 7 8 [9] 10 11 ... 13
121
Server / Re:SMTP 550-5.7.1
« kdy: 12. 01. 2022, 21:00:58 »
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.
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).


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.

122
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.

123
Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu
« kdy: 11. 01. 2022, 23:49:48 »
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
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ů)


124
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ě.

125
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)
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.net
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.

126
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é)
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
Čili mě zajímá kód samotný, nebo spíš jeho interpretace pro google mail. Jestli Pod tím se dá schovat víc důvodů nepřijetí správy(SPF, znamý spam), nebo striktně odpovídá významu v popisku - že daná IP není vítaná odesílat maily (ať už z různých důvodů - to se ostatně nedozvíme z hlášky)

127
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 )

128
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

129
_mbily, díky za vysvětlení, teď vidím, že to vlastně je smysluplné


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)
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.

130
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?

131
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ě.

132
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....

133
Snažím se porozumět celému tomuto ověřovacímu řetězu, podmínkám a vyvodit z toho pravidla , jaké proměnné mají být v DNS, EHLO, dál co v případě ,když odesílání mailu je delegováno na jiné "mailingové služby"( takové ty smartemailingy). Samozřejmě takové ty klíčové věci, jako že (TCP)komunikuje vždy IP adresa (a ne doména) nebo protokol SMTP nebo nutné záznamy v DNS a i princip SPF znám (tam trochu váhám, jestli platí striktní definice, že se kontroluje IP adresa komunikující strany v TCP spojení. Někde jsem četl že prý kontroluje i Envelope sender a že se doporujčuje i kontrolovat HELO).

Jako chtěl jsem si to vypátrat sám, ale má to dva háčky: jednak množství subjektů, které to mají správně je jak zrnko v poušti (ostatně stačí se podívat po pravici ) a za druhé bych musel někde zchrastit "tcpdump" komunikace někde (pro přečtení EHLO). Dokonce i nepřímou komunikaci(myslím, že server MX dělá souběžný doménový lookup, RBL check...)

Narazil jsem na toto:


Obecně je potřeba držet se následujícího:

* Čistá IP co není na blacklistu,
* ani IP z /24 rozsahu nebo /64 prefixu nesmí být na blacklistu,
** * reverzní záznam na této IP, **
** * doména z reverzního záznamu musí být v EHLO hlavičce,
**
* správně nastavené DKIM,
* správně nastavené SPF,
* odesílání pošty schované za ověřováním,
* neposílat emaily moc rychle,
* kontrolovat délku fronty,
* kontrolovat do narazí na limity.



Předpokládám že tím se myslel  jako objekt počítač (tedy konkrétní IP adresa) jakožto zdroj mailového provozu (oproti uživateli,doméně)

Tam mi nesedí že doména z reverzního záznamu musí být v EHLO.(Ano už se říkalo že jde o nesmyslnou buzeraci):
Citace: McFly
Pokud máš neexistující/špatné HELO/EHLO uvítání, třeba náš poštovní server tě odmítne. Je potřeba, aby minimálně existoval A záznam k HELO/EHLO. Nejlepší situace je mít v HELO/EHLO existující A záznam (+ odpovídající PTR záznam pro IP serveru). Jinak SPF záznam na HELO/EHLO máme nastaveno taky - SpamAssassin tě za to malinko odmění. :-)

Zrovna nyní řeším s jednou větší firmou, že jeden jejich server je "neoptimálně" nastavený - špatný PTR (neexistující A), taky chybné HELO/EHLO a třešnička na dortu je striktní SPF záznam, který ale neodpovídá tomu serveru, takže sami říkají, ať jejich poštu rovnou zahodíme... tak zahazujeme.
Tam mi nesedí že doména z reverzního záznamu musí být v EHLO.(Ano už se říkalo že jde o nesmyslnou buzeraci) . Není to moc přehnaný požadavek?


Jsou tu údaje: ip adresa, ze které mail odchází ("to si nevybereš", to se musíš přesunout k jinému počítači - hodnota určená ip protokolem)  a "textová hodnota" za MAIL FROM ("papír snese všechno"-tam lze napsat arbitrární hodnotu)

Z toho lze odvodit:
-z ("živé")ip adresy lze vyvodit PTR .
-z MAILFROM části za @ lze vyvodit vyhledat ip  adresu   a z ní následně druhé PTR.
Takže celkem 5 hodnot. Prozatím ani neuvažujeme SPF! Mailfrom je jasné. A co se tedy má s čím rovnat?




Hlavně pak bych chtěl rozebrat tu shodu HELO, MAIL FROM (část za @).

Mimojiné, DKIM záznam ležící přímo na doména.cz je asi špatně že? (Má být selektor._domainkey.domena.cz)

134
A je v pořádku  tento záznam ? (dotaz pro 12.40.244.63)
63.244.40.12.in-addr.arpa is an alias for 63.0/25.244.40.12.in-addr.arpa.
 ...  domain name pointer ferdamravenec.hostingos.es


Připadá mi to hodně divoké a i chybné . Dokážu si představit, co tím autor asi zamýšlel, ale je tam blok čísel navíc. Nebo je to nějaká über syntaxe a v pořádku?

Kromě toho jsou rozsahy typu 12.34.56.xx/24 validní všude ? (Myšleno to, že maska je "označuje" první tři bajty. Čtvrtý bajt je část za maskou . A řečnická otázka: ty by neměly být vždy nulové). Rozumím, že záleží na využití a mozná i na implementaci (významu):
1. vyznačení rozsahu (12.34.56.3/24 by  znamenalo 12.34.56.3 až 12.34.57.2)
2. matchování adresy na pattern : Pak je rozdíl mezi patterny 12.34.56.0/24 , 12.34.56.3/24 :
-  12.34.56.3/24  Může být vyhodnocen jako chybný pattern (nenulová část za maskou)
- Nebo Může mít matchovat  adresy 12.34.56.{3,7,11,15...255}
- Nebo nematchne žádnou adresu (v postatě chybný pattern, ale chyba je na straně uživatele) díky internímu algoritmu(adresa AND maska se nikdy nebude rovnat patternu protože 0 and cokoli nidky nemůže být jedna)

135
Asi každý ví, co se stane, když se multimetr v režimu proudu zapojí do smyčky (bez limitujícího odporu) - viz zde (SPOILER: wannabevtip)

Ale jak se chová multimetr v režimu ODPORU? Může se taky nevhodný zapojením zničit? Co vlastně fyzikálně měří za veličinu, kterou pak převádí na odpor? Například v návodu se píše, že v režimu odporu by nemělo být napětí větší než 2 nebo 4 Volty (nevím přesně) . Což je asi případ, když se měří "nevypojená součástka".

Stran: 1 ... 7 8 [9] 10 11 ... 13