Poslední příspěvky

1

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« Poslední příspěvek od McFly kdy Dnes v 09:22:44 »

Něco podobného jsem v práci řešil - šlo buď o Gmail nebo Microsoft, to si už nepamatuju. Analýzou údajů v hlavičce (a pro jistotu i kontrolou poštovního logu) jsem rychle zjistil, že problém byl v infrastruktuře odesílatele, kde zjevně jedna část jeho poštovního systému přijala e-mail, ale předala jej dalšímu internímu serveru s velkým zpožděním. Vše se dá vyčíst z hlavičky. Greylisting taky aplikujeme, ale ti největší poskytovatele e-mailových služeb jsou whitelistováni. Taky není rozumné aplikovat tvrdé kontroly blacklistů na Google nebo Microsoft - nalijme si čistého vína - bordel chodí zejména od nich a ostatní spammery (třeba zombie stroje) snadno odhalí antispam.

Microsoft je s Googlem v první pětce odesílatelů na světě - https://talosintelligence.com/reputation_center/email_rep#top-senders-owner

2

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 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.

3

Sítě / Re:Optický kabel - obecný souhlas

« Poslední příspěvek od jjrsk kdy Dnes v 09:03:42 »

Nevim, jak EG.D, ale treba CEZ ma pomerne presne definovano, jak ma vypadat propojeni ...

Az na tu drobnost, ze jak ma vypadat pripojka definuje legislativa, nikoli CEZ nebo kdokoli dalsi.

Pricemz jak tu zaznelo obecne plati, ze vsechny pripojky musi byt realizovany na hranici pozemku (tzv antonicek ...) a to predevsim prave proto, aby provozovatel rozvodu nemusel vstupovat na pozemky ani pri udrzbe ani pri provadeni nejakych odectu atd. (zaroven je potreba rict, ze hromady historickych pripojek to nesplnuji a nikdo je predelavat kvuli tomu nemusi).

A stejne tak plati zcela obecne, ze to co je dal, je veci majitele pozemku/domu a muze si tam dat/delat co chce. Jen se mu pak muze stat, ze mu treba pojistovna nic nevyplati, kdyz zjisti, ze ten dum vyhorel/vyletel do vzduchu ... kvuli jeho tvorivosti.

Presne jak tu zaznelo, neexistuje zadny duvod k tomu, aby to u datovych rozvodu bylo jinak.

4

Bazar / Re:Koupím DDR4 32GB ECC unbuffered DIMM moduly

« Poslední příspěvek od theyama kdy Dnes v 08:55:37 »

Já mám
Samsung 32GB 2Rx4 PC4-2400T-RA1-12-MCO
a
SKhynix 64GB 4DRx4 PC4-2133P-LE0-11

moduly. Jsou vyndány z HPE serverů, funkční.

5

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 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

« Poslední příspěvek od BobTheBuilder kdy Dnes v 08:01:14 »

...
Takže teoreticky je problém na mém příchozím serveru a ne na jeho odchozím. Díky za popostrčení, jak bude chvíle tak se podívám kam budu moct. Může to být třeba i hardwerem někde po cestě, co já vím. Ale setkal jsem se s tím až poslední dobou.

Nebo nedoručitelné/odmítnuté zprávy, ale to je trochu jiný problém.

To se pozná podle těch časových značek, kde to viselo.

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).
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.
No a zbytek jsou nevyžádaná obchodní sdělení, ale tam už jde o obsah, ne původce, ten je formálně v pořádku.

7

Software / Re:Brave: otevření stránky po kliknutí prostředním na „+“

« Poslední příspěvek od Bukowski kdy Dnes v 07:35:25 »

A jake je tam bezpecnostni riziko? Je to prostě UX funkce – vloží URL ze schránky a naviguje jako když to udělám ručně.
Jak postupujete kdyz vas neco zaujme na strance a neni to url, ja to proste oznacim a kliknu prostrednim na + a novem tabu se mi to vyhleda (ano muzu pres prave tlacitko ale je to o klik navic)

8

Software / Re:Brave: otevření stránky po kliknutí prostředním na „+“

« Poslední příspěvek od Bugsa kdy Dnes v 06:56:59 »

Tak o této funkci jsem opravdu nevěděl a neznám tak ani nikoho kdo by ji používal (nebo se nezmínil)... Ale mě to nefunguje ani v Brave ani ve Firefoxu (tam mám Betterfox, možná to vypnul?).

Taky mi to přijde jako bezpečnostní riziko, javascript do clipboardu přeci umí vložit obsah ne?

9

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« Poslední příspěvek od Supra. vod kdy Dnes v 01:16:46 »

Díky za konstruktivní diskuzi, určitě je to jasnější.

10

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« Poslední příspěvek od Supra. vod kdy Dnes v 01:10:43 »

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.

Takže teoreticky je problém na mém příchozím serveru a ne na jeho odchozím. Díky za popostrčení, jak bude chvíle tak se podívám kam budu moct. Může to být třeba i hardwerem někde po cestě, co já vím. Ale setkal jsem se s tím až poslední dobou.

Nebo nedoručitelné/odmítnuté zprávy, ale to je trochu jiný problém.