Příspěvky

376

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 21:50:43 »

Ale spat k topicu.

Je este jedna moznost preco nie su metadata. Mail bol vytlaceny. Za tych sest rokov bol mailbox x krat precisteny. A tak maju len kus papiera ktory samozrejme metadata nenesie...

377

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 21:42:43 »

Njn, najjednoduchsia moznost je ta najpravdepodobnejsia.

No právě.

Napriklad snaha o zakrytie nejakeho pruseru. Je to jednoduchsie vysvetlenie ako komplikovany bombovy atentat.

Ne, to není.

Naco by sa snazili posielat nejaky mail ked sa tam ako sa pise dostali aj bez neho.

Oni nejdřív poslali ten e-mail, teprve pak se tam dostali. Možná s etam dostali i díky tomu e-mailu. A nebo prostě plánovali víc různých variant, jak se tam dostat. Myslíte, že když plánují takovouhle akci, chtějí pak skončit na nějakém vrátném jenom proto, že neposlali předem e-mail?

Ako nech by robili cokolvek, tak nejake metadata by tam byt museli

Nikdo také netvrdí, že tam žádná metadata nebyla. Každému, kdo se v doručování e-mailů alespoň trochu vyzná, je jasné, že když odstraníte všechna metadata e-mailu a e-mail doručíte na cílový server, ten hned nějaká metadata přidá. Takže „byla odstraněna metadata“ neznamená, že v přijatém e-mailu žádná metadata nejsou.

Ten myslienkovy tok ma ale minimalne dve podmienky:

• Vinnikom su ti dvaja typci z GRU. Preco su vinnici dokazeme nejako neskor. Napriek tomu nebudeme pochybovat ze vybuch nesposobila manipulacia s vybusninami.
• Mail najake metadata ma, ale chybaju mu ip adresy servrov cez ktore prechadzal aj s casovymi peciatkami kedy cez ne prechadzal. Napriek tomu nebudeme pochybovat ze mail dorazil skor ako doslo k vybuchu.

378

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 17:12:48 »

IMAP může posílat zprávy ? Myslel jsem, že jen přijímat …

Nie spravy posielat nemoze, na to je SMTP, ale IMAP vie synchronizovat mailboxy, nie len vzdialeny do lokalneho ale aj naopak

379

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 17:08:51 »

Přístupové údaje k cílovému IMAP serveru (pokud vůbec provozují IMAP) asi ti agenti neměli.

Njn, najjednoduchsia moznost je ta najpravdepodobnejsia. Napriklad snaha o zakrytie nejakeho pruseru. Je to jednoduchsie vysvetlenie ako komplikovany bombovy atentat. Naco by sa snazili posielat nejaky mail ked sa tam ako sa pise dostali aj bez neho. Ako nech by robili cokolvek, tak nejake metadata by tam byt museli, je dine ak by ten mail neprivestoval ale bol vytvoreny.

380

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 15:09:06 »

Jestli jsem dobře pochopil, tak se nevydávali přímo za inspektory IMEX Group, ale za jejich zákazníky za Tádžikistánu a Moldávie.
V tom clanku, ktory odkazujete sa pise ze imex group tvrdi ze na prehliadku neprisli. Cize ako som si myslel tak tam sami nakracat nemohli. Tak ako si nemyslim ze by imex group zobrala na exkurziu do municaku niekoho kto sa vydava za ich zakaznika. Mne osobne by ani nenapadlo vziat niekoho, kto mi tvrdi ze je moj zakaznik a nepoznam ho, na exkurz do firmy kde pracujem.

Btw, je niekde nejaka zmienka o tommaili starsia ako 2-3 mesiace? Nikde som nic take nenasiel. Preco sa objavil 6 rokov stary mail az teraz.

381

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 14:40:50 »

Skor mi to pripomina scenar ktory som uz mnohokrat videl, ked zamestnanec chcel argumentovat mailom ktory odosielatel nikdy nenapisal. Mail bol zrejme napisany na mieste a presunuty do prijatej posty.

Mali by tam byt minimalne metadata cieloveho mta. Ak tam nie su, tak mail bol vytvoreny rucne a na server nahrany cez imap. Ip servrov cez ktore by mal mail putovat tam nie su, je dost komplikovane upravit logy mail serverov po ceste...

Vida, zkusim telnet na smtp.

Ja by som to videl ma jednoduchsi scenar, mail sam sebe, export spravy do suboru, edit, import spravy zo suboru... a ak je klient pripojeny cez imap tak tu upravenu spravu nasynchronizuje na server, div sa svete bez metadat s kade ten mail prisiel...

382

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 14:36:32 »

Tie access logy, pripadne iny sposob identifikacie klienta by mali byt dostupne. Podla smernic EU musi byt elektronicka komunikacia zalohovana, teraz z hlavy neviem kolko rokov.

Otázka je, zda by GRU používala zrovna freemail spadající pod jurisdikci EU.

Freemail sa moze vylucit uplne, podla toho co sa pise tak sa vydavali za inspektorov imex group, teda sa da predpokladat ze odosielatel by mal byt z domeny tej firmy.

383

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 13:40:23 »

Myslite ze ak poslete mail z freemailu, tak nie je mozne zistit z acces logov ip adresu browseru v ktorom bol ten freemail otvoreny?

Access logy po takové době nemusí být dostupné. Ale freemaily obvykle IP adresu klienta dávají rovnou do hlaviček e-mailu.

Nemyslím si ale, že to byl e-mail poslaný z nějakého freemailu. Ona by asi žádost o návěštěvu muničního skladu poslaná z freemailu vypadala dost podezřele.

Tie access logy, pripadne iny sposob identifikacie klienta by mali byt dostupne. Podla smernic EU musi byt elektronicka komunikacia zalohovana, teraz z hlavy neviem kolko rokov.

Ten najpouzivanejsi freemail tu ip do hlavicky nedava, je tam len ip webserveru.

S ostatnym suhlasim.

384

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 11:53:37 »

IMHO hledáte složitosti, kde nejsou. Nejpravděpodobnější varianta je, že to byl úplně normální mail, kde si jen odesílatel dal pozor, aby tam nebylo nic prozrazujícího (tzn. poslaný třeba někde z freemailu) a novinář (nebo policajt?), kterej tomu nerozumí, to "přebásnil".

Myslite ze ak poslete mail z freemailu, tak nie je mozne zistit z acces logov ip adresu browseru v ktorom bol ten freemail otvoreny?

385

Server / Re:Vymazání metadat z mailu

« kdy: 29. 04. 2021, 10:18:12 »

Skor mi to pripomina scenar ktory som uz mnohokrat videl, ked zamestnanec chcel argumentovat mailom ktory odosielatel nikdy nenapisal. Mail bol zrejme napisany na mieste a presunuty do prijatej posty.

Mali by tam byt minimalne metadata cieloveho mta. Ak tam nie su, tak mail bol vytvoreny rucne a na server nahrany cez imap. Ip servrov cez ktore by mal mail putovat tam nie su, je dost komplikovane upravit logy mail serverov po ceste...

386

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 26. 04. 2021, 09:26:31 »

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.

Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.

A nechceš si napsat prototyp, ať se máme nad čím bavit? Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)

Na napisanie bussiness logiky do db je uz dostatok moznosti - https://wiki.postgresql.org/wiki/PL_Matrix

Nie je problem znapisat sp ktora ti json rozparsuje alebo funkciu ktora ti json vrati (https://www.postgresql.org/docs/current/functions-json.html) Podla mojich skusenosti, v plpgsql je to rychlejsie nez tu logiku riesit v php alebo v pythone a db volat len ako storage... To iste mozes aj v sql sevri, tam je transact sql, ale tam ma irituje ze niektore ddl dotazy su pod transakciou a ine nie...

387

Vývoj / Re:Aplikační vs business vrstva

« kdy: 20. 02. 2020, 20:57:33 »

Bussines vrstva by mala definovat strukturu a sposob spracovania dat. Idealne v jazyku ktory je na hromadne spracovanie dat urceny, napr, plSQL.

Aplikacna vrstva by mala zabezpecit interface medzi bussines vrstvou a klientom.Napr, aplikacna vrstva pre php, koli websluzbam a alikacna vrstva v cecku pre desktop klienta, dalej napr pre python pre serverove scripty... Vyhoda je ta ze netreba siahat do uz otestovanej a spravne fungujucej bussines logiky.
Vpripade ze uzivatel nezvlada plsql tak je mozne pisat bussines logiku aj v jazyku v ktorom pise aplikacnu vrstvu, dost sa ale v tomto pripade stiera motivacia aby dosledne oddelil bussines logiku a aplikacnu logiku.

Cize ak by si to chel rozdelit na jednotlive vrstvy:
Datova - fyzicke ulozene data, ci uz subor alebo tabulky v rdbms
Bussines logika - sposob spracovania a ulozenia dat - zvedsa struktura databazy a procedury ktore data spracovavaju (vysvetlujte danovakovi ze float v php vam neulozi milardovu ciastu na korunu presne
Aplikacna logika - interface pre bussines logiku, riadenie opraveni, validacia vstupnych poziadavok - zvedsa nazyvane modely
Prezentacna vrstva(web) - zabezpeci odovzdanie dat z formularov do aplikacnej vrstvy, formatovanie vystupu cez sablony tak aby bol vhodny pre zobrazenie browserom, formatovanie vynimiek do citatelnej podoby. - view + controller(presenter)
Prezentacna vrstva(api) - ziskanie vstupnych dat, poziadaviek zo soap alebo json (a kadecoho ineho), odovzdania do plikacnej vrstvy a formatovanie dat alebo vynimiek ktore vrati aplikacna vrstva do spravneho formatu (spravidla rovnakeho typu ako bola poziadavka). - view + controller(presenter)

Tolko teoreticky pohlad, prakticky zalezi od toho na akej urovni su ludia ktory vo firme ke sa dostates uz pachali tu aplikaciu pred tebou. V lepsom pripade vcelku realisticky pokrcia pleciami ze zavadzat idealy by bolo uz priis nakladne a v horsom pripade budu mylne presvedceni o svojej jedinecnosti a s idealmi nezapadnes... Firiem kde by boli jednotlive vrstvy oddelene dosledne najdes bohuzial minimum...

388

Server / Re:Seznam odmítá můj záznam SPF

« kdy: 09. 08. 2019, 21:11:20 »

Ked tak vyriesene,

cielova mail schranka presunuta inde kde nemaju problem z tym ze mail ma v hlavickach jak ipv6 tak aj ipv4 adresy sucastne.

Mozno ked tak uzavriet.

389

Server / Re:Seznam odmítá můj záznam SPF

« kdy: 09. 08. 2019, 21:07:54 »

Hola,

nesnažíš se forwardovat email, který byl doručený z jiné domény? Pokud ano, může dojít k problému viz odkaz
https://support.forpsi.com/kb/a3070/presmrovani-zprav-a-spf.aspx

další odkaz, jak problému předejít.

https://github.com/roehling/postsrsd

J.

Praveze nie, pisal som o tom uz vyssie. A to ako si spravne nastavit server viem, problem je zrejme na strane primaca, viz vyssie.

390

Server / Re:Seznam odmítá můj záznam SPF

« kdy: 09. 08. 2019, 21:06:00 »

mno jestliže má server ipv4 a ipv6 tak postfix pokud není nastavený, že má používat jen ipv4, tak pokud může používá ipv6 a tím může vzniknout ten problém, kdy email dojde do cílový smtp server, jako odesilací adresu tam má ipv6, která ale není nikde uvedená v dns takže v spf se neobjeví a tim pádem to neprojde přes spf check

ono dneska bojovat proti spamům je dost náročný a mít správně nastavený náležitosti na svém serveru je základ.

server ma dns zaznamy jak pre ipv4 tak pre ipv6, a spf je nastaveny spravne. Ako, nechal by som tam pustenu len ipv6 ale v dnesnej dobe este vodafon nevie ipv6.