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:DMARC/SFP a hlavička Return-Path
« kdy: 04. 11. 2025, 10:40:25 »
S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.
Jaké nedostatky má DKIM? ...
Jeden z častých DKIM problémů v praxi představují maily s řádky delšími než limit 998 znaků. Často produkované nějakými html generátory. Obvyklá dvojice Postfix+OpenDKIM nedokáže s tímto prohřeškem pracovat (třeba řádek násilím zlomit). Jiným problémem může být zásah do MIME mailů v podobě změny kódování obsahu někde po cestě. A není to tak dlouho, co jsem se potýkal se zásahy MS Exchange do záhlaví jednotlivých částí MIME mailů při jejich lokálním doručování a přeposílání prostřednictvím uživatelských pravidel.

Samostatnou kapitolou pak jsou mailing listy. Například chcete na listserveru do Subjectu přidávat jméno listu, na konec mailu přidat patičku listserveru a chcete z mailu odfiltrovat nežádoucí MIME části. Tím vším porušíte původní DKIM podpis. A nový DKIM podpis přidat nemůžete kvůli nesouladu jména domény původního odesilatele a podepisujícího serveru.


Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM.
Ona to ani vyžadovat nemůže.
Ano, moje trapná chyba a omluva čtenářům. Mozek už usínal, a z posledních sil si vzpomněl na dmarc tag fo=, který ale slouží k něčemu jinému.


2
Software / Re:Nekorektní chování BTRFS
« kdy: 04. 11. 2025, 00:00:31 »
To volné nedotknutelné místo prostě berte jako cenu či daň za provozování takového typu filesystému. Ať už je to btrfs, zfs, ceph a určitě ještě řada dalších...

3
Windows a jiné systémy / Re:Microsoft odporúčanie pre SPF
« kdy: 03. 11. 2025, 23:54:00 »
Až Vás (a všechny další provozovatele on-premise Exchange) Microsoft přiměje plně přejít do Exchange Online, tak se Vám ten include: bude hodit...

4
Server / Re:DMARC/SFP a hlavička Return-Path
« kdy: 03. 11. 2025, 23:49:56 »
Zazněly zde některé nepřesnosti, zkusím tu problematiku shrnout:

Řádek Return-Path: vzniká až v okamžiku, kdy mail na své cestě k adresátovi dorazí na poslední MTA v cestě a je předán pro lokální doručení.  Do Return-Path: je v tomto okamžiku vložena adresa odesilatele obvykle označovaná jako mail sender, obálková nebo protokolová adresa, adresa ze smtp příkazu MAIL FROM atp. Ve zde nepřímo zmíněném RFC 5321 vizte sekci 4.4.

Na mail sender adresu se posílají zprávy o nedoručitelnosti a tato adresa se používá při kontrole dodržení SPF.
Po doručení mailu do mailboxu by ta adresa mail sender vlastně zanikla. Aby ji příjemce mailu měl možnost někde spatřit a aby ji správce mail serveru eventuelně nemusel hledat v poštovním logu, je použita tato berlička v podobě zapsání adresy do hlavičky Return-Path.

SPF kontrola nepracuje s hlavičkou From:, ale s adresou mail sender.

SRS je pomocný trik sloužící k tomu, aby bylo možno mail přeposílat (prostřednictvím aliasů, souboru .forward apod.). Při klasickém přeposlání by zůstala adresa mail sender zachována, čímž by ale při kontrole u příjemce bylo (velmi pravděpodobně) zjištěno porušení SPF. Proto je použit trik s přepisováním této adresy pomocí SRS.

Můžete narazit i na názor, že při přeposílání má přeposílající převzít za tento mail odpovědnost tak, že adresu mail sender změní na svoji vlastní. (A adresu From: ponechá beze změny.) To je také možné řešení. S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.

Ve vztahu k DMARC existují různá doporučení pro přeposílání nebo pro provozování mailových konferencí. Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM. Chcete-li plnit DMARC zcela důsledně, tak dojdete k závěru, že adresy From:, mail sender a  doménové jméno z DKIM podpisu musejí být prakticky stejné, resp. ve vzájemném souladu/alignmentu.

5
Server / Re:Postfix s OAuth při odesílání e-mailu
« kdy: 24. 03. 2025, 23:05:15 »
Tak postfix umi kde co, ale kdyz je potreba jen mala proxy, tak existuje esmtp, ale nevim zda umi oauth.
Pokud Vám nebo Vašim uživatelům na spolehlivém doručení odesílaných mailů jen trochu záleží, tak se všem udělátkům typu esmtp či ssmtp prosím vyhýbejte. Důvod je ten, že nadřazený smtp server (mailhost, relay host, hub atp.) může z mnoha důvodů odmítnout mail převzít. Např. je na něm poštovní služba dočasně administrátorem zastavena, server je přetížen, má zaplněný disk apod. A v takové situaci esmtp či ssmtp neumějí pokus o odeslání mailu zopakovat, dojde ke ztrátě mailu.

Proto je dobré mít i na čistě odesílacích strojích plnotučný program, který při nezdařeném odeslání uloží mail do své fronty a po čase jej zkusí odeslat znovu. Může se jednat ať už o postfix, nebo třeba exim. Kdo se obává nějaké možné chyby v konfiguraci, tak třeba postfixu může říci inet_interfaces = loopback-only. Tím postfix nebude umět přijímat maily "zvenku", bude umět jen odesílat.

6
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.

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

8
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.

9
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.

10
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.

11
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...


12
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.

13
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?

14
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.

15
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á.

Stran: [1] 2 3