31
Odkladiště / Re:Klamavá stránka
« kdy: 22. 05. 2023, 11:13:38 »
Už to převzal i ESET. Přístup na web blokuje.
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.
32
Server / Re:Profi SMTP MAiL FROM:
« kdy: 19. 05. 2023, 11:40:02 »Když jsme u té profesionality...
Já myslím, že je to OK a dneska zcela běžné - spousta lidí využívá tyhle massmailingové společnosti pro rozesílku a není neobvyklé, že obálkový odesílatel (MAIL FROM:) udává adresu té společnosti, třeba kvůli SPF kontrole. Hlavičkový odesílatel (FROM:) je pak obvykle už adresa zákazníka.
Nechci kecat, ale matně si pamatuju jednu veřejnou českou službu na úschovu souborů, která toto měla nastaveno špatně (jako MFROM uváděla e-mail zákazníka), takže při striktním nastavení SPF kontroly u zákazníkovy domény byl tento e-mail na našem serveru rovnou zahozen. Dneska už to mají kluci a holky opraveno. :-)
33
Server / Re:Profi SMTP server
« kdy: 18. 05. 2023, 12:24:33 »Diky. Doufal jsem v neco automatizovaneho, mam desitky serveru a bounce ruzneho typu mam denne v desitkach ci vyssich radech. Zkoumanim vypisu pflogsummu bych travil hodiny denne :-)
Kdyby měl M$ veřejný dotazovatelný blacklist, ten by se dal integrovat třeba do Wedos Online monitoringu a v případě pozitivního výskytu by přišlo upozornění e-mailem. Ale takto bohužel. JJ, při takovém množství serverů to chápu, že to není moc efektivní. :-)
34
Server / Re:Profi SMTP server
« kdy: 18. 05. 2023, 12:05:32 »technicka: jakym zpusobem jste detekoval blokaci? monitoring - jak ?Denní výpisy z logu Postfixu - pflogsumm. Když tam vidím nějakou "zajímavost", koumám to pak podrobněji v samotném logu. V tomto případě pflogsumm prozradil:
Kód: [Vybrat]
message bounce detail (by relay)
--------------------------------
eur.olc.protection.outlook.com[104.47.12.33]:25 (total: 1)
1 27:51.756Z 08DB54CD99EBE39D] (in reply to MAIL FROM command)
A pak v logu:
Kód: [Vybrat]
May 15 14:27:51 mail postfix/smtp[198917]: 351B32A004F: to=<*****@outlook.cz>, relay=eur.olc.protection.outlook.com[104.47.12.33]:25, delay=0.57, delays=0.09/0.02/0.43/0.04, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.12.33] said: 550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [DB3EUR04FT064.eop-eur04.prod.protection.outlook.com 2023-05-15T12:27:51.756Z 08DB54CD99EBE39D] (in reply to MAIL FROM command))A pak jsou tu uživatelé, co reportují, že jim někam nejde poslat e-mail. :-) Schválně jsem si testoval několik poštovních serverů, které máme, a všechny blokovány, takže M$ zablokoval zřejmě celý /24 subnet. Ani jednou ale nesdělili, kdo je původcem problému, jejich blacklist není bohužel veřejný.
35
Server / Re:Smysluplnost "aliasů" v hlavičkách To,Cc
« kdy: 18. 05. 2023, 11:50:05 »Jo, skvělé jsou např. Samsung Cloud <no-reply1234@gmail.com>, nebo MojeBanka <dobrabanka247@email.cz> (a nedělám si srandu, že někteří klienti opravdu zobrazujou jen ten alias...)
Nedávno jsem řešil masivní phishing (zaměřený na firemní Webmail), kdy odesílatel byl NAŠE FIRMA <anna.jacquit@blabla.fr> a byl jsem docela nepříjemně překvapený, když pak volalo pár zaměstnanců, že jim přišel od nás e-mail, ale že nemohou otevřít ten odkaz v něm - zablokoval jsem ho na firewallu. Lidi si fakt mysleli, že to byl e-mail z IT oddělení. :-/ Volající vůbec nezarazila e-mailová adresa někde ve Francii ani podivná nedokonalá čeština. Ani webový odkaz složený z nesmyslných písmenek vedoucí někam do .com zóny neodradil. A jak tuhle URL adresu zablokovat i jinde, to byl druhý oříšek. Hlásil jsem ji opakovaně několika společnostem (Google, Netcraft, ESET, AVG, ...) a ani jedna neoznačila URL odkaz za phishing. Nejvíce mne štval Netcraft, který URL link označoval za bezpečný, i když jsem jim poslal phishingový e-mail jako .eml soubor, doslova na stříbrném podnosu. Samotný hosting stránky v USA pak zareagoval odstavením webu.
36
Server / Re:Profi SMTP server
« kdy: 17. 05. 2023, 11:49:42 »
A také můžete mít svůj server sebelépe nastavený a stačí, aby měl váš ISP v části subnetu (ve kterém má vaše společnost servery) nějakého spammera nebo zavirovaný stroj dalšího zákazníka a takový Microsoft rovnou zablokuje celý subnet včetně těch dobrých, a je úplně jedno, jestli jste na nějakých whitelistech a máte dokonalou reputaci...
To se před pár dny stalo nám. Vyřešil jsem to ihned, jak jsem blokaci detekoval, a to přesměrováním smtp komunikace jinam... Ale pak kolotoč žádostí o odblokaci s Microsoftem, fakt za trest. Zabere to nejeden den a zaručeně vás laxní přístup M$ rozpálí doběla.
To se před pár dny stalo nám. Vyřešil jsem to ihned, jak jsem blokaci detekoval, a to přesměrováním smtp komunikace jinam... Ale pak kolotoč žádostí o odblokaci s Microsoftem, fakt za trest. Zabere to nejeden den a zaručeně vás laxní přístup M$ rozpálí doběla.
37
Server / Re:Profi SMTP server
« kdy: 17. 05. 2023, 07:53:33 »divne, nikdy som to nekontroloval, ale zdalo sa mi, ze problem s blacklistami na tychto sluzbach nie je.
Ale nikdy som to nepotreboval skontrolovat.
Mne osobně potěšilo, že jedna česká společnost, co se zabývá rozesílkou, se dostala před pár dny až týdny na blacklisty a mají problém se z tama vyhrabat. Pravda, mají desítky serverů a ne všechny jsou na blacklistech. Jednatel té společnosti je arogantní nepříjemný Rusák, asi karma.
38
Sítě / Re:Horší WiFi na MikroTik hAP ax3
« kdy: 24. 04. 2023, 17:52:23 »To není tak úplně pravda - absence HW offloadingu se projeví vysokým vytížením CPU a zařízení má potom tendenci droppovat packety a provoz v síti je potom smrt. Problém se projeví globálně, nejen na tom vytíženém provozu - tak kdybys na to narazil, aspoň víš, po čem jít :-)
I se zapnutým https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack ? (tím samozřejmě člověk přijde o nějaké ty věci, ale když je vyloženě nepotřebuje... Kde nepotřebuju pracovat s markováním paketů/spojení a omezováním v queues, tam dávám fasttrack a spokojenost)
39
Sítě / Re:Veřejný hotspot bez šifrování pro hosty na domácím AP (Ubiquiti)
« kdy: 03. 04. 2023, 20:31:11 »
Provozujeme guest portal na Unifi. Samostatná VLAN s izolací guestů, routing s NATem dělá Mikrotik a šlape to pěkně. Osobně bych řešil i to, zda směrem do Internetu je pro guesty vyhrazená vlastní veřejná IP adresa. Doma bych na vlastní veřejné IP adrese nechtěl traffic guestů, co projdou kolem. :-) Lákadlo pro podvodníky z Bazoše, spammery, vyděrače politiků nebo stahovače dětského porna...
40
Bazar / Re:Prodám MikroTik RB4011iGS+RM
« kdy: 31. 03. 2023, 10:46:17 »
Není ta cena příliš velká? 
Tady www.wifihw.cz/default.asp?cls=stoitem&stiid=4158 si připlatím 368,- Kč a mám nový kus se zárukou 2 roky...
Tady www.wifihw.cz/default.asp?cls=stoitem&stiid=4158 si připlatím 368,- Kč a mám nový kus se zárukou 2 roky...
41
Vývoj / Re:AI a poker
« kdy: 28. 03. 2023, 15:13:30 »
Uvědomujete si, že celé tohle vlákno je jeden velký spam? ;-) Některé příspěvky jsou šikovně maskovaný link building a reklama zadarmo... 
42
Server / Re:Je lepší LAMP nebo XAMP? Co vybrat na Mint pro vývoj?
« kdy: 26. 03. 2023, 18:34:38 »
Je toho víc. ;-)
lnmp(Linux + Nginx+ MySQL/MongoDB+ PHP)
lamp(Linux + Apache+ MySQL/MongoDB+ PHP)
lnmpa(Linux + Nginx+ MySQL/MongoDB+ PHP+ Apache):Nginx handling the static, Apache processing dynamic PHP
lnmt(Linux + Nginx+ MySQL/MongoDB+ Tomcat)
lnpp(Linux + Nginx+ PostgreSQL+ PHP)
lapp(Linux + Apache+ PostgreSQL+ PHP)
Osobně provozuju weby nejčastěji na LNMPA.
lnmp(Linux + Nginx+ MySQL/MongoDB+ PHP)
lamp(Linux + Apache+ MySQL/MongoDB+ PHP)
lnmpa(Linux + Nginx+ MySQL/MongoDB+ PHP+ Apache):Nginx handling the static, Apache processing dynamic PHP
lnmt(Linux + Nginx+ MySQL/MongoDB+ Tomcat)
lnpp(Linux + Nginx+ PostgreSQL+ PHP)
lapp(Linux + Apache+ PostgreSQL+ PHP)
Osobně provozuju weby nejčastěji na LNMPA.
43
Server / Re:Pomale predani emailu na gmail.com
« kdy: 20. 03. 2023, 13:00:03 »
delay = 0.76:
ale
delay = 15:
Třeba je to vytížením jejich serverů, čert ví. Náš server je nevytížený... Na servery Seznamu to dělá delay okolo 1.3 až 1.6. Na Gmail nejčastěji pod 1 sekundu, ale občas je tam anomálie, viz výše. Přiznám se, že mne to moc netrápí.
Kód: [Vybrat]
Mar 20 10:30:57 mail postfix/smtp[1114821]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)
Mar 20 10:30:57 mail postfix/smtp[1114821]: 134AC2A004E: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=0.76, delays=0.09/0.02/0.3/0.35, dsn=2.0.0, status=sent (250 2.0.0 OK 1679304657 q6-20020a1709064cc600b00934a633a6c1si1855786ejt.228 - gsmtp)ale
delay = 15:
Kód: [Vybrat]
Mar 20 12:39:59 mail postfix/smtp[1125593]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 20 12:40:14 mail postfix/smtp[1125593]: E35222A00A2: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.27]:25, delay=15, delays=0.38/0/0.34/14, dsn=2.0.0, status=sent (250 2.0.0 OK 1679312414 d5-20020a50fb05000000b004ad0993e54esi9779437edq.487 - gsmtp)
Třeba je to vytížením jejich serverů, čert ví. Náš server je nevytížený... Na servery Seznamu to dělá delay okolo 1.3 až 1.6. Na Gmail nejčastěji pod 1 sekundu, ale občas je tam anomálie, viz výše. Přiznám se, že mne to moc netrápí.
44
Server / Re:Nefunkční mailserver s Postfixem
« kdy: 16. 03. 2023, 10:52:40 »Ač už Gentoo několik let nepoužívám, protože má náročnou údržbu, tak mně jeho instalace dala mnohem víc, než jakákoliv jiná hotová distribuce.
Já takhle začínal se Slackwarem. Pak jsem si v něm běžně kompiloval kernel, Apache, PHP... bezva časy.
45
Server / Re:Nefunkční mailserver s Postfixem
« kdy: 16. 03. 2023, 09:56:20 »
Já mám doma tuto knihu o Postfixu, mohu doporučit, i když je staršího data. ;-) https://www.trhknih.cz/kniha/6jeyphfp
