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

Stran: 1 ... 24 25 [26] 27 28 ... 153
376
Sítě / Re:Heslo ke Greenpacket OH735 od O2
« kdy: 20. 09. 2022, 21:38:02 »
Jestli je ta antena pripojena pres Ethernet, tak tam dej do cesty komp se dvouma sitovkama v bridge a pust na tom Wireshark, pak zapni router a antenu.

378
Neviem ci len RDA alebo vseci ste asi zle pochopili - ja tu neriesim realne peniaze a pohyby na uctoch. Len virtualne sledovanie kto ma kolko "kreditov" v mojom systeme.

V tom pripade pro tebe navic plati ta ma rozsirena konstrukce s ruznymi menami - at je vetsina internich transakci v "kreditech", ale i/o s bankama pak v realnych menach. Jestli jsi nekdy pouzival PayPal, tak tam to meli hezky udelany ty konverze - v podstate to je transakce v ramci stejneho uctu, jen mezi jinymi menami. Tohle umim presne i ja, ale casteji ke konverzi pouzivam individualni virtualni ucet ("hromadku") pro dany pripad - protoze pak tam muzu nacpat volitelne i zisk/ztratu nebo provizi.

Citace: hknmtt
Uzivatel #1 si dobije penazenku tym ze zaplati kartou alebo mi posle peniaze na ucet v banke a ja do systemu tuto platbu zanesiem nasledovne:

A proc to nesledovat vcetne techto vstupu? (a predpokladam ze analogicky i vystupu)

379
Tvuj pristup je prilis akademicky - v praxi narazis pak na to, ze ti bude chybet nektery radek z paru ktery tvori prevod, takze vznikne nekonzistentni system a budes tezko hledat co se ztratilo.

Muj pristup (kdyz jsem delal vlastni sw na ucto) je tento:

TABLE users - id, .... ;
TABLE accounts - userid, typ, nazev-cislo;
TABLE transfers - src, dst, amount;

Kazdy uzivatel (u me subjekt) ma evidovany jeden nebo vicero uctu - uctem se mysli reference na externi ucet (lokalni, mezinarodni, paypal), pripadne docasne ucty - u tebe to jsou interni stavy.

V tabulce prevodu pak mas prevody mezi dvouma* uctama. At uz se jedna o externi platby (dobiti, vyplata), nebo interni platby (za zbozi a provize). *Ve tvem pripade bych se nebal to rozsirit na tristranny prevod 1-na-2 (platba na prijem a provize), udelat to sumarizaci slozitejsi, ale zas se nemusis starat o transakce a rollback pri castecnem selhani. V pripade potreby multi-menove obsluhy je potreba mit alespon 4 sloupce u transferu - zdrojova/cilova castka/mena (a dalsi metadata jako kurz, datum, puvod kurzu). Ja tam mam i reference na radek bankovniho vypisu (paypal, fio) pro snazsi trasovani.

Z takoveho modelu muzes vzdy nechat spocitat balance na kazdem uctu (a v kazde mene), pro kazdeho cloveka. Vse, co mas vedeno jako interni ucet, si pak muze nekdo z uzivatelu narokovat.

Pro pripad rucnich kompenzaci si samozrejme musis zalozit vlastniho uzivatele, s uctem, nabit ho z externiho, a pak delat az kompenzaci. Pripadne nabit muzes i dodatecne, pokud akceptujes zaporny zustatek u sebe.

380
Sítě / Re:Heslo ke Greenpacket OH735 od O2
« kdy: 20. 09. 2022, 12:27:47 »
Imho jedině se obrátit na O2, jestliže tam mají vlastní FW. Takže šance asi minimální.

Buď to používat jak to je, a nebo to poslat dál a pořídit něco normálního.

Jako kdyby to zarizeni nutili k zaplaceni uzivatelem, resp. povinnemu odkupu, tak by neco jako vlastni uzamceny fw nemel projit soudem.

381
Hardware / Re:Zabezpeční dat na serveru pro případ hacknutí
« kdy: 14. 09. 2022, 09:35:37 »
Co jsi nezminil:
- volba spravne distribuce, ktera aktivne dba na bezpecnost
- provadet aktualizace
- sledovat CVE

Taky je moznost:
- provozovat alternativni instanci (heterogenni cluster), s jinou sadou zranitelnosti
- odlejvat na write-only journal data, takze se ti nikdy neprepisou a muzes urezat kompromitovanej konec

A hlavne:
- trenovat obnovu reseni a dat po prukaku

382
Odkladiště / Re:Falešné prozvánění z mého čísla
« kdy: 13. 09. 2022, 14:05:40 »
Ohledně trolingu a nesmyslných příspěvků si každý jistě o tobě udělal obrázek sám, naposledy třeba v sousedním vlákně "Filtrování spamu a scamu na mail serveru", kde zase řádíš jak černá ruka :P

Btw, redakce si je toho jeho trollingu vedoma a neposila emailove upozorneni na jeho prispevky :-)
Ale taky je mozne, ze se to behem putovani skrze SMTP zahodi jako spam, jakmile chytre filtry uvidi jeho jmeno :P

383
Vývoj / Re:Filtrování spamu a scamu na mail serveru
« kdy: 11. 09. 2022, 23:16:59 »
Ackoliv si sam delate pr​del, ze "postfix opravuje postu", nazev opravdu vznikl ze dvou slov: post pro postu, a fix pro opravu.
To, co se opravuje je stav tehdejsich postovnych programu - nizke zabezpeceni a nizky vykon.
Děkuji za poučení. Teprve teď jsem pochopil, že ve Wordu můžu napsat jenom jedno slovo, zatímco s Excelem je každý vynikající.

Jestli sve tvrzeni o Wordu a Excelu podlozite citaci, budiz. Jinak jste exemplarni blbec bez spetky sebereflexe.
To by jako samo o sobe nevadilo, kazdy je nejaky a tohle je odborne forum, ne psychologicka poradna a la zpovednice.

Ale hodne velky problem je, ze si vubec nepripoustite, ze co (vam) tady lidi pisou by mohla byt pravda.

Vyjadreni ohledne puvodu pojmenovani postfixu primo od jeho autora:
https://marc.info/?l=postfix-users&m=164841848519002&w=2

Kontext doby je, ze IBM hledalo nahradu za nevyhovujici sendmail (a ze tech jeho der jsme si taky uzili.. cca pred 20 lety).
https://techmonitor.ai/technology/ibm_takes_on_sendmail_with_secure_mailer

EDIT:
Pro pobaveni dnesni mladeze - vycuc bezpecnostnich problemu sendmailu:
https://cr.yp.to/maildisasters/sendmail.html

384
Vývoj / Re:Filtrování spamu a scamu na mail serveru
« kdy: 11. 09. 2022, 22:09:08 »
Jasně, a Postfix opravuje papírovou poštu, protože má v názvu "post" a "fix".

Tady to jste se dost šeredně spletl. Překlad slova ani význam anglického "post" rozhodně není papírová pošta aka papírový dopis nebo pohled. A "fix" má rozhodně významově silnější překlad v kontextu s tím post než marginální ale klasické čengliš "opravit".
Obávám se, že jste se minul s podstatou postu.

Ackoliv si sam delate pr​del, ze "postfix opravuje postu", nazev opravdu vznikl ze dvou slov: post pro postu, a fix pro opravu.
To, co se opravuje je stav tehdejsich postovnych programu - nizke zabezpeceni a nizky vykon.

385
Vývoj / Re:Filtrování spamu a scamu na mail serveru
« kdy: 10. 09. 2022, 19:55:44 »
ANo, já už naštěstí žádný poštovní server neprovozuju, takže scam neřeším jako správce, ale jen jako běžný uživatel.

Takze ho zejmena ctete, tridite, mazete, otevirate, vytvarite, posilate, preposilate.
Clicking, double-clicking, heslo sem heslo tam.
Nekdy vas nekdo nachyta a nekdy nachytate vy druheho.
To je zivot, cece :P

386
Ako potom mozem testovat funkcnost bez toho aby mejly boli zablokovane ale v horsom pripade len padali do spamu?

Muzes to testovat vuci svym ostatnim serverum, nebo jestli chces, tak ti zridim ucet nebo forward u sebe na nejakou chvili.

387
Ja spravuji DB skrze PMA a tam je moznost davat komentar ke kazdemu sloupci (uklada se do struktury DB), viz:

https://mariadb.com/kb/en/create-table/#comment-column-option

Casto to pouzivam pro indikovani jak provest lookup nejakeho vyctu hodnot (tj. v komentari je pouze:   targettable.column )

388
MTA a MDA je často implementován jako jeden kus softwaru, takže skrze MTA komunikujete i s MDA a skrze SMTP odpověď se dozvíte informaci o MDA. Třeba Postfix umí do lokálních schránek doručovat sám, funguje tedy jako MDA. A když lokální schránka neexistuje, Postfix vám to rovnou ještě v rámci SMTP spojení řekne.

I kdyz je to jeden software, T/D role jsou jasne dane. V praxi se temer nikdy nespouje verejne MTA a koncove MDA, vzdaleny uzivatel tedy nedostava informaci od MDA realtime. Znova se projevuje vase nevedomost a snaha si veci domyslet zpusobem, jak to neni ani podle realne praze, ani podle standardu.

Bud se jedna o verejne MTA a nasleduje pak interni asynchronni mezifronta, ale casteji je tam i spam filtr (clamav a pod), takze o vysledku z finalniho MDA vzdaleny uzivatel nemuze hned vedet. Anebo se jedna o velice tupe a hlavne neverejne MTA sprazene s MDA, kde je typicka hlaska pak ve forme: 250 Delivered to maildir/mbox/inbox (a pod). Ale na takove instalace se vzdaleny uzivatel dnes uz nepripojuje.


250 OK je informace o tom, že e-mail byl někam doručen. Může to být schránka adresáta, může to být nějaký mezilehlý server, který má povinnost doručit zprávu dál, nebo o tom informovat odesílatele. Je to stejné, jako doručenka u pomalé pošty – ta znamená, že zásilka byla doručena do schránky adresáta, nebo byla předána třeba někomu ve stejné domácnosti, který má povinnost zprávu doručit adresátovi. Když pošta adresáta nenajde, pošle zpět celou zásilku s důvodem, proč se ji nepodařilo doručit.

Pletete si porad slova dorucen* a podan, resp. prevzat. Stavovy kod 250 OK znamena, ze podani problehlo v poradku a kompetence ohledne dorucovani nebo oznameni o nedorucei (bounce) prechazi na MTA se kterym jste po SMTP komunikoval.

Opravdu si uvedomte, ze pokud komunikujete po SMTP, tak resite vzdy MTA-MTA. Informaci, zda se jednalo o doruceni, ktere provedlo MTA se synchronne volanym MDA muzete jenom odhadovat podle textoveho komentare u kodu uspesneho podani, ale nikdy to nebude na 100% a SMTP protokol imho nespecifikuje jak rozlisovat zda je uspech jen castecny (MTA v ceste) nebo uplny (MDA skoncil s uspechem).

*dorucen = terminalni stav po ceste MSA/MTA+/MDA, a jediny pristup provadi uz jenom MUA.

389
Já jsem ale psal o doručování e-mailu cílovému serveru, které provádí MTA a doručuje jinému MTA nebo MDA. To se provádí plnohodnotným protokolem SMTP na portu 25. Ve světě pomalé pošty to odpovídá tomu, že se zásilka z podací pošty skrze nějaké mezikroky doručí až do schránky adresáta, nebo – když se to nepodaří – zůstane na dodací poště. To je ve světě SMTP potvrzeno kódem 250 OK, ve světě pomalé pošty doručenkou. Obojí říká, že ten, kdo prováděl transport (MTA, poštovní dopravce) udělal co bylo v jeho silách, aby zprávu/zásilku doručil. Není to ale potvrzení o tom, že adresát zásilku přijal. Potvrzení od adresáta je až dodejka – ta musí být podepsaná adresátem, a samozřejmě to nemůže být součástí protokolu, protože to není věc technická, nýbrž právní – počítá s tím, že technika někde může selhat. (Jedinou výjimkou jsou v tomto datové schránky, kde právě dodejku nepodepisuje adresát, ale přímo systém, takže je to technicky pořád jenom doručenka).

Znova potvrzujete svoji neznalost emailu a jeho komponent.

MTA pouziva SMTP mezi sebou (Transfer). A to je to, co je na obou koncich TCP/IP spojeni, at uz se jedna o prvni, prostredni, nebo posledni server po ceste.

MDA nepouziva SMTP. Jedna se totiz o komponentu retezce zajistujici koncove doruceni (Delivery) do schranky uzivatele, at uz jde o zapis do souboru ci slozky, presun souboru, vlozeni do databaze, nebo jinou ekvivalentni operaci. Viz man procmail. Jelikoz MDA nema SMTP rozhrani, tak tezko muzete argumentovat s 250 OK.

Takze si to cele nastudujte znova, protoze vyjma lokalniho pouziti, nikdy s MDA neprijde (vzdaleny) uzivatel do styku.

250 OK je nicnerikajici o stavu doruceni nebo dodani. Vzdy se vam muze vratit bounce, pokud nasledna cesta nebo treba to posledni MDA selze.

390
A pokud vy trváte jen na úrovni SMTP protokolu, pak odpověď 250 OK je doručenkou na úrovni SMTP protokolu.

Když je pochopení nějakého komentáře nad vaše síly, tak na něj neodpovídejte – to bylo to nejlepší, co jste udělal.

Pokud necemu nerozumite, tak radeji neodpovidejte.

250 OK je ekvivalent "Podaciho listku doporuceneho psani", ktere si odnasite z posty pri podani zasilky.

SMTP slouzi k predavani posty - "Simple Mail Transfer Protocol", ne k dorucovani do schranek.

Stran: 1 ... 24 25 [26] 27 28 ... 153