Názory k článku Stavíme vlastní e-mailový server: základní nastavení systému

Ano, bylo by to možná lepší, ale ten server opravdu existuje, dá se o něm něco i zjistit (třeba dig), a doména testemail.cz mi přišla dostatečně jasně "testovací". Když jsem se snažil to přepsat na něco neutrálního, vnášelo to jen chyby. Server je navíc asi 20x přeinstalovaný kvůli ověření, že opravdu vše funguje a v návodu nic nechybí a i pro mě bylo jednodušší, když návod obsahoval skutečné údaje (kromě hesel).

Rozumim, existenci serveru jsem vsak nekontroloval. Volba .test/.example mi prijde proste vhodnejsi (RFC 2606) zvlast pokud clovek nechce zverejnovat info o infrastrukture, kterou spravuje, nebo naopak podprahove cilit skrytou reklamou :))
Ale nic proti gustu...

Ano, z domény testemail.cz hodlám udělat největší veřejný mail server a toto je reklama na něj :D Jak říkám, přemýšlel jsem nad tím, ale tohle vyšlo pro mě jednodušší. Bohužel se mi nějak nedostává času, takže jsem na tom pracoval po nocích a i tak mi z toho hrabalo. Výsledkem je třeba zapomenutý FW na IPv6, který se snad do článku doplní. Jinak tu doménu plánuju využít k dalším zajímavým aktivitám okolo konfigurace mailů, už jsem začal pracovat na nějakých testovacích skriptech ohledně domén, message reflektorech atd. A slavnostně slibuji, že tam nikdy nebude reklama ;)

3. Klíče pro ssh se mohou dělat na klientovi a stěhovat tak pouze veřejný klíč, nikoliv soukromý.
4. funkcionalita ntp je již v systemd, takže stačí timedatectl set-ntp true. (Pokud nebude dál potřebovat speciální funkce ntpd.)

Ok, dík za info. To se nám ta jednota a všude stejné nastavení trochu rozpadá.

Dík za článek, paráda.
A ještě doplním k bodu 3, klíče by se měly dělat na klientovi, poněvadž na VPS nebývá dostatek entropie.

Je to samozřejmě pravda, ale taky by se k tomu dalo dodat, že server nemá být hostovaný na cizím VPS, protože spoustu věcí lze vyčíst z memory dumpu, na konzoli lze zachytávat klávesnici atd atd. Proto tuto část bezpečnosti v návodu příliš neřeším a proto tam neřeším ani šifrování dat. Prostě to nemá smysl. Na serveru generuji v návodu klíč proto, protože to prostě funguje a nemusím řešit, jak vygenerovat klíč v Linuxu, Windowsu, Macu a já nevím, kde ještě. Jsou to drobné ústupky, ale na druhou stranu je to pořád lepší, než root s heslem 1234 a povoleným přihlášením odkudkoliv.

K argumentům pro iptables-service bych přidal to, že všude na internetu je plno návodů na iptables. Jakmile to máte něčím obalené (ať už jsou to „jen“ distribuční skripty, nebo je nad tím celá aplikace), komplikuje použití všech těch materiálů – přečtete si, jak něco nakonfigurovat v iptables, pak musíte zjistit, jak firewalld mapuje věci na iptables a pak to nakonfigurovat tak, aby vám z firewalld nakonec vypadla ta pravidla pro iptables, která jste znal na začátku. Přičemž třeba u těch distribučních skriptů to bývá tak, že ten postup transformace z konfiguráku do pravidel iptables není nikde zdokumentován, takže nezbývá než najít si to v příslušném skriptu. Skript, na kterém musím dělat nejdřív reverzní inženýrství, mi nijak nepomáhá, právě naopak. Samozřejmě také může nastat případ, kdy daná nadstavba příslušnou věc nepodporuje vůbec, a pak musím ještě řešit, jak skloubit tu nadstavbu s nativními iptables.

Podobné je to často s konfigurací sítě. To byl můj největší problém, když jsem kdysi začínal s Linuxem – přečetl jsem si návod, nakonfiguroval síť a firewall pomocí ip a ipchains, a pak jsem zjistil, že distribuce má na konfiguraci sítě jakési podivné soubory, které na ip vůbec nepasují (bodejť by také pasovaly, když skripty ještě používaly ifconfig).

Takže pokud někdo využije ty služby, které poskytuje nějaká nadstavba, ať ji používá. Ale pokud je to obecný návod, je podle mne mnohem lepší použít základní nástroj, protože si to pak každý může transformovat pro tu svou nadstavbu, kterou používá.

Ano, to je důvod, proč samotný OpenWRT nepoužívám a vážně uvažuju, že na Turris Omnia dám jiný systém. Na router dávám Linux proto, protože umím v Linuxu síť nakonfigurovat podle svých představ – ne proto, aby mi v tom nějaká mezivrstva překážela.

Je to zvláštní, ale je to velký problém, pokud to má fungovat. Ty drobný odchylky v konfiguracích jsou otravný. Většinou jsem používal Debian, ale když jsem (už koncem minulého roku) začal dávat dohromady tento návod, tak mi Debian přišel nějakej dost zuboženej. Politiky SELinuxu neexistovaly, daly se sice nainstalovat starší, ale ty se přestaly udržovat pro svoji rozbitost a každému u Debianu to bylo jedno... neměl jsem z toho dobrý pocit. Návod se samozřejmě dá aplikovat s přiměřeným úsilím na jinou distribuci.

Už jsem doma běžící mailserver měl (kvůli ověření domény), ale nějak jsem to vůbec nepoužíval a nakonec to asi upadlo do stavu nefunkčního. Jsem rád, že tu vzniká seriál na tohle téma. Alespoň mě to donutí to zase rozchodit a navíc uvidím i další možnosti/informace.

Super, těším se na pokračování.

Ano, internet je plný návodů, podle kterých to "nějak" funguje, ale většinou je třeba slepit několik konfigurací dohromady. Jen na velmi málo místech je alespoň základní popis toho, proč a co se nastavuje a tak se jen kopíruje. Občas je člověku smutno, když se dostane k nějakému serveru a koukne do poslepovaného main.cf a master.cf. V lepším případě jsou z toho drobnosti typu dvakrát podepsaný email DKIMem (např. iinfo.cz :D ), v horším to pak končí jako open relay.

Přesně tak, sa-update. Ale ani to není vždy výhra, Je potřeba se smířit s tím, že žádný server není zcela bezúdržbový a občas je potřeba něco přizpůsobit aktuální situaci ručně. Jinak samozřejmě to v návodu bude, ale zázraky nečekejte. Zrovna toto jsou věci, u kterých je nejlepší variantou mít pod tím silnou udržovanou distribuci a příliš si to neohýbat, protože to stojí neúměrné množství času a výsledek je často katastrofální, ve srovnání s defaultním stavem.

Ona volba SW byla dost problém, rozhodoval jsem se mezi klasikou a modernou, nakonec to až na RainLoop vyhrála klasika. On by někdo chtěl nginx, někdo unbound, někdo exim, někdo spamd, clamav většinou v produkci taky nepoužívám a raději nasazuju komerční řešení, ale tak to prostě je. On protokol SMTP je taky z minulého století/tisíciletí ;) A právě to překotné nasazování novinek není vždy to nejlepší. Stejně už teď počítám s tím, že to doplním alespoň o ten RoundCube, možná SOGo, pokud bude zájem, je možné dodatečně doplnit i další změny. Ale nejdříve by to měl být funkční a konzistentní systém a potom je možné si s tím hrát a experimentovat.

A to je pravda, za to se omlouvám a sypu si popel na hlavu. Pana krčmáře jsem poprosil, jestli by to tam doplnil.

Držím palce, uvidíme jestli tohle překoná Lukáše Jelínka :-).
Jinak postgrey (greylist) bude nebude nasazen ?
Stále ho používáme i přes nějaké problémy, jako ten "nedávno" s outlook.com, dodnes se nemohu rozhodnout jestli je to ok nástroj, ale klady asi převažuji nad zápory. FH

Dle RFC 5321 by MĚL BÝT čas mezi pokusy alespoň 30 minut, ale téměř nikdo to nedodržuje.
Konkrétně postfix se v tomto řídí několika volbami:
queue_run_delay - default je 300s, znamená to, jak často se snaží znovu projet deferred queue - frontu odmítnutých zpráv
minimal_backof­f_time - default opět 300s - po jaké době nejdříve zkusit další doručení. Tato doba se z každým pokusem pro konkrétní mail zdvojnásobuje až do horní hranice, což je další volba
maximal_backof­f_time - default 4000s - maximální čas čekání mezi dvěma pokusy
maximal_queue_li­fetam - default 5d, maximální čas, po který se snaží doručit mail, poté je zahozen jako nedoručitelný
delay_warning_time - default 0 (vypnuto) - po jak dlouhé době se odesílateli oznámí, že mail čeká ve frontě a zatím nebyl doručen.

Ve výchozím nastavení to tedy znamená, že druhý pokus je někde mezi 300 a 599 vteřinami a pokud problém trvá, odesílatel se to dozví po 5ti dnech!

Třeba Postgrey má výchozí čas pro druhé doručení tuším 300 vteřin, což je kouzelné, protože jestli se nepletu, třeba MS Exchange má default retry po jedné minutě.

Větší servery mívají retry i několik hodin, protože jejich deferred queue bývá dlouhá jak pohádka...

a teď si vyberte... řídit se RFC, neřídet se RFC, čekat hodiny na maily... nedává to smysl. Navíc, jak jsem psal, servery spammerů bývají často nastaveny líp, jak ty nespamovací, aby měly vůbec šanci něco doručit. Graylisting toho opravdu víc rozbije, než zachrání.

Graylisting z několika důvodů nebude, je to v dalších kapitolách popsané. Dřív to bývala celkem spolehlivá ochrana proti spamu, ale dnes už moc nefunguje. Spamovací servery jsou často nastavené lépe, než ty regulérní a greylisting podle mě dnes přináší víc problémů, než užitku.

Sice už nějaký ten mail server mám za sebou, ale tutorial jen vítám. Díky! :)

nebojte, bude, bez toho blbnou velké dotazy ohledně dkim

Přijde mi logičtější povolovat věci až dle potřeby, jsou potom jasnější souvislosti. Věci na loopbacku budou povoleny taky jen potřebné, server nemá sám se sebou co kecat :) Co se týče ICMP, ano, stačilo by povolit request a reply. Jenomže když se do toho vnoříme pořádně, tak jen nastavení firewallu by bylo na samostatný seriál a nikdy nebudou spokojení všichni, protože každej má svoje postupy, svoje oblíbený pravidla a každej je má samozřejmě nejlepší :D Proto nechci zabíhat do nějakých extrémních podrobností. Ano, je co zlepšovat, v produkci by to bylo ještě úplně jinak, ale mělo by to být celkem dostatečný.

ICMP Echo rozhodně nestačí. Potřebuješ ještě přinejmenším ICMP destination unreachable, kvůli fragmentaci/MTU linky. Jinak se může stát, že si nepopovídáš s některými servery a klienty, kteří jsou za několika vnořenými tunely. (Třeba teredo nebo jiná forma IPv6 over IPv4). A zrovna na tohle se těžko ladí, protože to vypadá jako chyba druhé strany. Ostatním to přeci funguje.

Pardon, v tomhle případě IPv4 over IPv6, nebo tak něco. Mám dojem, že IPv6 fragmentaci řeší jinak, než přes ICMP.

Tohle je trochu problém VPS. Člověk většinou dostane nějak základně předinstalovaný systém a v jakém je stavu záleží na tom, jak je ta prvotní instalace udělaná. Pokud bude poskytovatel VPS dostatečně kreativní, může tam být cokoliv :(

Strašně se mi líbí, když někdo řeší, jestli požít firewalld nebo iptables, ale nikoho z diskutujících už netrápí, že v tom firewallu je třeba kompletně zařízlý loopback...

Což vůbec ničemu nevadí, protože zatím není potřeba. Vše co bude potřeba bude povoleno, až na to přijde čas. Ten návod už existuje kompletní a ten server funguje, což by asi se zaříznutým loopbackem úplně nešlo. Jsem zvyklej zaříznout úplně všechno, včetně loopbacku a podle situace povolit jen to, co je opravdu potřeba. Někdo to dělá jinak a loopback povoluje komplet, někdo se vůbec nestará o OUTPUT, někdo chce používat firewalld, protože je v CentOSu výchozí, někdo volá po větší univerzálnosti a nevázání se na jednu distribuci... omlouvám se, ale opravdu není v mých silách udělat radost úplně všem...

Jako rychlé řešení stačí načasovat pomocí at reset firewallu do původní podoby třeba za 5 minut. Když se úprava firewallu povede a jste pořád připojen, úlohu resetu zrušíte. Když se to nepovede, máte za 5 minut další pokus.

Ano ano. Kdysi jsem byl pripojeny na debian pomoci ssh a prekonfiguroval jsem /etc/network/in­terfaces. Nasledne jsem chtel aby se eth0 spustilo s novou konfiguraci, takze bezny postup:
ifdown eth0 <Enter>
ifup eth0 <Enter>

No asi nemusim rikat, ze druhou radku uz nebylo kam napsat.

Tohle byla moje oblíbená rada pro začínající kolegy, hlavně na windows, na vzdálené ploše. Tak zakaž a povol síťovku. Chytl se snad každý, ale zase na druhou stranu si to většina z nich pamatovala do smrti.

Dobrý článek. Jen tak dále v dalších dílech. Díky!

Ano, rspamd je určitě velmi zajímavé řešení, ale mám trochu pocit, že se snaží dělat moc práce najednou. Když se člověk podívá na bug list, tak ho nadšení velmi rychle přejde. Na hraní je to pěkný, pohodlný, moderní, ale ještě bych tomu dal nějaký čas, než to trochu sedne.

Doporucim jeste zmenu SSH portu. Na jednom testovacim serveru mam cca 20 - 30 tis. pokusu o spojeni za den. Na jinem portu nezli 22 neeviduji zadny pokus o pripojeni. Zmena portu pro SSH je take potreba pohlidat v selinuxu. Jinak super clanek, bezim na dalsi dil.