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

Stran: [1] 2 3
1
Server / Re:Google Sites a nastavení CNAME v DNS
« kdy: 28. 12. 2024, 15:48:20 »
Hm, tím se to dál komplikuje. Ten webový administrační nástroj Vám dovolil vložit formálně nesprávný (čtěte nesmyslný) záznam. A neumí s ním dál pracovat. Takže nejdřív budete muset jít přes toho poskytovatele DNS služby a požádat, aby ten záznam smazal on. Následuje čekání, jestli se sám vyřeší problém DNSSEC nebo zda opět budete muset jít na poskytovatele. A teprve do třetice zavedení nového CNAME záznamu.

2
Server / Re:Google sites problém DNS
« kdy: 28. 12. 2024, 15:30:05 »
V tuto chvíli máte jiný, vážnější problém, s rozbitým DNSSEC. Vizte https://dnssec-debugger.verisignlabs.com/praha-rytectvi.cz
To je potřeba spravit jako první. Může a nemusí to souviset s nesprávnými CNAME záznamy. Doporučuji:

  • Smazat všechny ty uvedené CNAME záznamy.
  • Po chvíli, za hodinku, za dvě, zítra, zkusit, zda ten test je "zelený". Pokud DNSSEC problém bude trvat i zítra, obraťte se na vašeho poskytovatele služeb. A pošlete mu pro jistotu odkaz na ten test.
  • Po vyřešení problému s DNSSEC nastavte DNS CNAME záznam www.praha-rytectvi.cz. odkazující na ghs.googlehosted.com., obojí s tečkami na konci. (To už jste skoro měl, jen je potřeba v tom webovém nástroji na obou stranách psát ty koncové tečky.)


Update: Teď dodatečně koukám, že u A záznamů tečky nejsou. Takže pro změnu v kroku tři dejte obě strany bez koncových teček.... Pardon.

3
Server / Re:Postfix + LDAP - co s výpadkem LDAP
« kdy: 25. 11. 2023, 23:46:05 »
LDAP standart je docela moderni a uz dopredu pocita s replikaci.

Promiňte, ale slovo moderní bych pro protokol s téměř třicetiletou historií asi nepoužil. Spíš vyzrálý.

LDAP vznikal na univerzitě v Michiganu od roku 1993 jako odlehčená varianta pro dotazování se do adresářové služby X.500. Odtud slůvko Lightweight v názvu protokolu. Plnohodnotná implementace z Michiganu je datována 1996. Ve stejném roce vznikl též iPlanet Directory Server. OpenLDAP spatřil světlo světa v roce 1998.

RFC 2251 popisující soudobou verzi LDAPv3 je z roku 1997.

A dopředu počítá s replikací?

Vím pouze o RFC 4533 (1996), které nikdy nepřekročilo svůj experimentální status a ani na něj nebylo nijak dále navázáno. Pokud je mi známo, každý výrobce si řeší replikaci po svém. Ani se nikdo nechlubí schopností replikace s produktem jiného výrobce. Pokud tedy neuvažujeme export/import dat ve standardizovaném formátu LDIF.

A abych napsal něco k tématu: pokud se i při fungující replikaci obáváte možných delších výpadků, pak se připojuji k názoru pana Kriegela na zavedení lokální repliky. Nebo hloupý (ale účinný) postup pravidelné extrakce informací z LDAPu a jejich transformaci do klasických konfiguračních souborů postfixu.

4
Server / Re:MS 365: podvržené emaily
« kdy: 14. 09. 2023, 22:35:28 »
Bez DMARCu budete muset hodně dobře vyškolit účetní ve čtení záhlaví mailů. A pokud se tedy navíc bavíme specielně o vnitrofiremní komunikaci v rámci jedné domény v prostředí MS365, tak to má ještě jeden háček. Takový mail vůbec nemusí opustit prostředí Exchange Online, a v takovém případě není DKIM podpisem opatřen.

5
Server / Re:MS 365: podvržené emaily
« kdy: 14. 09. 2023, 21:33:37 »
... Když pak přijde e-mail s odesílatelem z vaší domény, ale bez podpisu, je jasné, že je ten e-mail podvržený...
Pardon, ale toto neplatí. S použitím čistě jen DKIMu nemá přijímající strana jak zjistit, že mail měl být podepsán. Příjemce kontrolou případného existujícího podpisu pouze ověřuje, zda tělo mailu a vybrané hlavičky nebyly při transportu nějak změněny.

Teprve až zastřešující politikou DMARC může odesílající strana svět informovat, že by ten DKIM podpis měl být použit.

6
Server / Re:Sendmail hlásí Internal server error
« kdy: 06. 06. 2023, 16:38:14 »
Pokud se držíte sendmailu, tak na debianu 11 se sendmailem 8.15.2 jsem si otestoval autentizaci smtp relace proti smtp serveru. Na stranu serveru jsou maily předávány na submission port 587, spojení v šifrovaném režimu po STARTTLS. Otestováno i z thunderbirdu.

Instalován je balíček sendmail. Dále i balíček mailutils za účelem snadného odesílání mailů z příkazového řádku příkazem mail.

Můj testovací smtp klient i server jsou online, s veřejnými ip adresami a registracemi v dns. Nicméně v konfiguraci klienta uvádím i základní variantu maškarády. Konfigurace je koncipována pro klientský stroj, z nějž se maily pouze odesílají.

Základ konfiguračního souboru /etc/mail/sendmail.mc vznikl při instalaci. Upravený soubor uvádím pro úsporu místa bez většiny komentářů.


Kód: [Vybrat]
divert(0)dnl
#
#   Copyright (c) 1998-2005 Richard Nelson.  All Rights Reserved.

define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.15.2-22 2021-03-16 16:04:16 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
undefine(`confHOST_STATUS_DIRECTORY')dnl
dnl define(`confLOG_LEVEL', `14')dnl
define(`SMART_HOST',`[mail.hostmaster.sk]')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Port=smtp, Addr=127.0.0.1')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MSP-v4, Port=submission, M=Ea, Addr=127.0.0.1')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`access_db', , `skip')dnl
FEATURE(`greet_pause',  `1000')dnl
FEATURE(`delay_checks', `friend', `n')dnl
define(`confBAD_RCPT_THROTTLE',`3')dnl
FEATURE(`conncontrol', `nodelay', `terminate')dnl
FEATURE(`ratecontrol', `nodelay', `terminate')dnl
FEATURE(`always_add_domain')dnl
MASQUERADE_AS(`hostmaster.sk')dnl
FEATURE(`masquerade_envelope')dnl
include(`/etc/mail/m4/dialup.m4')dnl
include(`/etc/mail/m4/provider.m4')dnl
MAILER_DEFINITIONS
MAILER(`local')dnl
MAILER(`smtp')dnl

V souboru jsem ponechal všeobecné direktivy a rovněž detaily nějak specifické pro debian, jejichž smysl se mi nechtělo zkoumat.
V běžném režimu provozu v logu sendmailu neuvidíte podrobnosti o autentizaci. Stačí ale odkomentovat definici s LOG_LEVEL (a znovu spustit make a restartovat sendmail) a bude to o něco lepší.

V definici SMART_HOST je v hranatých závorkách jméno serveru, na nějž se předávají odchozí maily (a kde je nutné se autentikovat). Další řádky mění komunikaci z portu 25 na submission port 587 na straně smart hosta. Náš klientský sendmail naslouchá jen na loopbackové adrese 127.0.0.1 a tedy není schopen přijímat maily "zvenku". Díky tomu neřešíme pravidla pro relay mailů a celá konfigurace je tím jednodušší. cw_file a access_db jsou obvyklá nastavení. Nyní je k ničemu nepotřebujete, ničemu nepřekážejí, výhledově se mohou hodit. Umělou prodlevu greet_pause jsem ponechal jako částečnou ochranu v situaci, když by se Vašeho stroje zmocnil nějaký spammer neznalý sendmailu. Ta sekundová prodleva by trošku mohla omezit celkový objem mailů. Stejná motivace se týká i BAD_RCPT_THROTTLE, connection control a rate control.

Do MASQUERADE_AS uveďte doménovou část z Vaší mailové adresy. Máte-li adresu novak@zoznam.sk, napište tam zoznam.sk. Touto maškarádou by se měl odstranit problém s oním hostname debian.debian. Místo toho by v odchozích mailech měla být nyní adresa odesilatele přepisována. Ještě zbývá případné mapování uživatelského jména na část mailové adresy vlevo od znaku @, to jsem neřešil. Testujte to z běžného uživatelského účtu. Bývalo totiž zvykem, že na uživatele root se maškaráda nevztahuje.

Protože se všechny odchozí maily předávají na SMART_HOST, lze soubor /etc/mail/authinfo pojmout minimalisticky a uvést zde jen uživatelské jméno a heslo pro autentizaci na straně ISP. A dále předpokládám, že v thunderbirdu používáte v definici smtp serveru autentizační metodu označovanou jako Normal Password, plain či nějak podobně. Tedy že zabezpečeným kanálem (STARTTLS) se heslo předává v čitelné podobě, a jeho šifrování zajišťuje ten vnější zabezpečený kanál. Tomu odpovídá i stručnější varianta nastavení AUTH_MECHANISMS výše.

AuthInfo: "I:xxxxxxx" "P:yyyyyy"

Další krok v případě debianu je být v adresáři /etc/mail a zavolat program make pro překlad konfiguračního souboru do podoby sendmail.cf. Současně by se měly vytvořit nebo aktualizovat i potřebné mapy, včetně  /etc/mail/authinfo.db.
(Varování o chybějící SASL podpoře lze v naší konfiguraci ignorovat). Pak už jen restartovat sendmail, např. systemctl restart sendmail

Nu a pak už si můžete sám sobě do schránky u providera zkusit poslat mail, příkazem např. mail novak@zoznam.sk.

Snad jsem v tom textu při kopírování/opisování neudělal moc chyb...


7
Server / Re:Sendmail hlásí Internal server error
« kdy: 05. 06. 2023, 16:13:23 »
Večer si zkusím toto téma osvěžit v paměti a na jednom sendmailovém stroji nastavit režim smtp klienta s autentikací. Pak se ozvu.
V mezičase můžete zkusit zvýšit detailnost logovaných zpráv na cca 14.

define(`confLOG_Level', `14')

Máte v konfiguraci někde uvedeno, že se jako klient chcete autentikovat? Odkaz na soubor smtpauth pravděpodobně nestačí. Jde mi o jednopísmenkové příznaky, které se píší buď do access souboru nebo jako argument nějaké direktivy do hlavní konfigurace. Totiž, to verify=FAIL v logu u STARTTLS se myslím týká verifikace serverového certifikátu a není v tomto případě fatální. V logu by mohla/měla být i zmínka o autentizaci a jejím výsledku.

8
Server / Re:Sendmail hlásí Internal server error
« kdy: 05. 06. 2023, 13:40:43 »
V rychlosti několik poznámek. Omlouvám se, pokud jsem přehlédl odpověď na některou z nich.
  • Co je zač doménové jméno debian.debian? Ve veřejném dns neexistuje. Už kvůli tomu nadřazený smarthost/relayhost mail odmítne. Ale do této fáze jste se asi ani nedostal.
  • Sendmail (ani postfix) neumí odeslat mail protokolem imap nebo pop.
  • Program ssmtp kolegům v mém okolí v principu nedoporučuji až zakazuji. V případě jakéhokoliv dočasného výpadku, nedostupnosti či přetíženosti protistrany neumí ssmtp odesílaný mail odložit do fronty a po čase zkusit znovu odeslat. S msmtp zkušenost nemám, dle dokumentace zřejmě tímto neduhem netrpí.
  • Ad soubor/mapa smtpauth - v nastavení je zadaná cesta ale nefunguje: je v logu zpráva o neúspěšném pokusu ten soubor otevřít? Je v něm jiná chyba týkající se toho souboru?
  • A konečně - umožňuje Vám protistrana použít autentikovaný smtp protokol a je ochotna přeposílat Vaše maily dál do světa?

9
Software / Re:Elektronický podpis v Thunderbirdu
« kdy: 18. 04. 2023, 20:50:09 »
Ano, to souhlasí.
Zopakuji radu, která už zde zazněla: porovnejte si vlastní tělo odeslaného mailu (ze složky s odeslanou poštou) s tím, které dorazí do Exchange.

10
Software / Re:Elektronický podpis v Thunderbirdu
« kdy: 18. 04. 2023, 20:37:31 »
Nevyjadřuji se k S/MIME mailům, ale k problému při doručování do MS Exchange, ať už ve variantě on-premise nebo online.
Pokud bys treba na tom exchange chtel revalidovat dkim, tak taky smula, nacpe si do mailu hromadu svych nesmyslu, takze to uz neprojde.
Ta hromada přidaných nesmyslných hlaviček ale naštěstí nemá vliv na existující DKIM podpis. Alespoň tedy jsem se s takovou situací nepotkal. Problém je s tělem MIME mailů, do nějž Exchange při vkládání mailu do schránky skutečně zasahuje. Stručně jsem to nedávno popsal na konkurenčním serveru, pan domácí doufám promine. Jde o předposlední příspěvek (v tuto chvíli) v debatě https://www.abclinuxu.cz/blog/Max_Devaine/2023/3/office-365-zkusenosti/diskuse

Maily v ASCII z thunderbirdu v mém případě odcházejí jako MIME s jedinou (hlavní) částí, a problém se jich tak netýká.

11
Hardware / Re:Tiskové jazyku u tiskárny
« kdy: 04. 04. 2023, 22:05:15 »
Dovolím si navázat na historické okénko pana Ryšánka. Taky už něco pamatuju:

Postscriptová tiskárna bývala poměrně vzácnou záležitostí. Mluvím o době, kdy  byla na trhu HP LJII, později LJIII.
Byl jsem hrdým majitelem referenčního manuálu PCL od HP. Postscriptový výstup jsem tenkrát vnímal jako záležitost spíš DTP studií a osvitových jednotek, než běžných firemních tiskáren. S velkou slávou jsme si do HPLJII pořídili rozšiřující kartu pro zpracování Postscriptu. Ano, tisk byl proti PCL výrazně pomalejší. Procesor tiskárny nestíhal. Stejně tak se velmi často narazilo na nedostatek RAM v tiskárně.

Na tehdejším pracovišti jsme měli i plotter "souřadnicový zapisovač" Digigraf. Pár slov o něm je zde na rootu https://www.root.cz/clanky/tiskarny-a-plottery-vyrabene-v-ceskoslovensku/. To bylo svým mechanickým provedením opravdu povedené zařízení. Zádrhel trochu byl spíš v samotných kreslicích perech. Ty bylo třeba pečlivě opatrovat a uctivě s nimi zacházet. Šlo pochopitelně o problém zasychání inkoustu nebo výrobu kaněk, a to v kombinaci s nastavením rychlosti pohybu kreslicí hlavy. A to zvlášť při potřebě mít v zásobníku připravených více per různého průměru pro velkoformátové výkresy, kdy vykreslení trvalo desítky minut. Šťastlivcům se mohlo zadařit sehnat pera Rotring místo tuzemských Centropen(?). Už se nepamatuju, jestli byly rozměrově shodné nebo se používal nějaký adaptér.

Při zapnutí elektrostatického přisávání pro upevnění papíru k podložce bylo krásně vidět, že se papír rázem celý vyhladil. To bylo doprovázeno i zvukovým efektem krátkého zašumění či chcete-li mlasknutí.

Digigraf měl či možná stále ještě má tuhý kořínek. Nadšenci s ním i frézují https://forum.strojirenstvi.cz/viewtopic.php?t=11403

12
Sítě / Re:Lze zjistit DKIM selektor jen podle domény?
« kdy: 09. 12. 2022, 17:50:38 »
Napadají mne dva způsoby, kterými je možné zjistit obsah DNS zóny. A v zóně pak najdete i  DKIM selektory. Oba způsoby jsou založeny na komunikaci se slabě, či chcete-li nevhodně, konfigurovanými autoritativními name servery:
  • správce dns serveru omylem či úmyslně povolí libovolnému klientovi tzv. zónový přenos,
  • DNSSEC lze provozovat ve variantách NSEC nebo NSEC3. Starší NSEC v sobě skrývá problém v odpovědích informujících o neexistenci nějakého záznamu. Vizte google, klíčová slova dnssec zone walking.

13
Mohu-li Vám radit, tak z řetězce uvedeného v HELO/EHLO lze jen těžko něco podstatného vyvozovat. Bylo tomu tak vždy, a je tomu tak i dnes. Rovněž tak ze vztahu HELO/EHLO k ip adrese či dns jménu smtp klienta. Vizte tento výběr z pár minut reálného poštovního provozu dnešního dne:

client=mail-vi1eur04on0630.outbound.protection.outlook.com[2a01:111:f400:fe0e::630], helo=<EUR04-VI1-obe.outbound.protection.outlook.com>
client=relay.netic.dk[2a03:dc80:0:f136::218], helo=<mxout02.netic.dk>
client=mailgate.tugraz.at[129.27.2.197], helo=<mxesa1.tugraz.at>
client=budka.sunnysoft.cz[86.49.189.186], helo=<host-22.sunnysoft.cz>

Můžete ty jednotlivé případy analyzovat a hádat, zda jsou to servery s více interfejsy, jestli třeba není ve hře load-balancer, zda ip adresa má omylem více PTR záznamů apod. Bude se tahhle snažit hádat i Váš antispam?

Použil jste pojem něco jako ověřený překlad. I na to pozor. Očekával bych, že v dnešním světě k tomu přidáte nějaké další pojmy. Když se bavíme o smtp, tak třeba smtp spojení zabezpečené pomocí TLS, s platným certifikátem (obou stran?), vydaným respektovanou certifikační autoritou, zabezpečení DNS komunikace na bázi DNSSEC, nad tím kontrola certifikátu podle DANE.

14
Hardware / Re:Výběr klávesnice pro pracovní účely
« kdy: 20. 11. 2022, 18:41:08 »
Perixx PERIBOARD-106M

Nádhera. Děkuji. Tu firmu jsem neznal, dávám do bookmarků.

Mám v práci podobný model od Chicony, přesný typ si nepamatuji, modernější gumák. Hrozím se dne kdy mne pro sešlost věkem opustí.

Mám i nějakou pradávnou od IBM, ale ten legendární model to myslím není. Když jsem ji před časem vytáhl, tak mne překvapilo, s jak velkou silou jsem musel tisknout klávesy. Máte prosím tušení, jaký typ spínačů v tom Vašem retro modelu je? Děkuji.

(Kde jsou ty časy, kdy jsem byl zvyklý na psacím stroji na samolepku vypsat všechny akcentované znaky, abych je pak lepil na boky kláves...)

15
Server / Re:Autoritativní DNS server Bind pro PTR
« kdy: 23. 06. 2022, 19:06:15 »
RFC 2317

Stran: [1] 2 3