Názory k článku Stavíme vlastní e-mailový server: webmail RainLoop
-
Filip JirsákStříbrný podporovatelJe to obecný návod – když budete chtít webmail nainstalovat na jiný stroj, můžete postupovat podle stejného návodu.
A obecně moc nechápu tenhle přístup, kdy se u každé věci znovu posuzuje, zda je fakt nutné šifrovat. Není lepší opačný přístup? Prostě šifrovat vše, pokud není nějaký vážný důvod nešifrovat. Připadá mi takový přístup mnohem jednodušší a bezpečnější.
-
anon (neregistrovaný)
> A obecně moc nechápu tenhle přístup, kdy se u každé věci znovu posuzuje, zda je fakt nutné šifrovat.
Já si naopak myslím, že je dobré umět posoudit, kdy je co "fakt nutné". Dokonce bych řekl, že umět to posoudit je nesmírně důležité. Bezmyšlenkovitě něco nastavit si podle mě dobrý sysadmin nemůže dovolit. Samozřejmě máte pravdu, obecná poučka je "šifrování je dobré" - ale tenhle článek čte hodně lidí a pokud má sloužit jako osvěta ("měli byste šifrovat spojení"), neměl by navádět k fanatismu ("šifrovat se musí vždycky a všude za každou cenu a není dobré nad tím vůbec přemýšlet").
V tomto konkrétním případě si myslím, že je lepší nešifrovat. Protože aby někdo zachytil takovou komunikaci - to už by musel mít roota na tomhle konkrétním stroji - no a to je game over šifruj, nešifruj.
Takže to nepřináší žádné benefity. Naopak, znamená to, že i backend webmailu je závislý na (hádám) OpenSSL knihovnách, na jejich bindings pro PHP, na platném certifikátu .. co třeba OCSP stapling? Co když nebude CRL dostupný?
V tomhle konkrétním případě je to prostě zbytečné a nese to sebou několik vrstev navíc, kde se může něco pokazit.
-
Filip JirsákStříbrný podporovatel
Znovu zopakuji, že jde o obecný návod – podle kterého může postupovat i někdo, kdo bude mít ten webmail na jiném zařízení, a pak s emu ten návod na rozchození šifrování bude hodit. Pokud má někdo webmail i IMAP server na jednom zařízení, neměl by pro něj být problém tu konfiguraci šifrování přeskočit.
-
On vás k tomu vlastně nikdo nenutí, ale taky vás nikdo nenutí k tomu, aby byl RainLoop na stejném serveru. Šifrování nikomu neublíží, časy, kdy to bylo výpočetně náročné jsou dávno pryč a pokud se nebavíme o serveru s mnoha současnými přístupy, řešit takovou drobnost je zbytečné. Certifikát je obnovován automaticky a pokud vyprší, RainLoop asi nebude to, co vás bude v první chvíli trápit nejvíc.
-
anon (neregistrovaný)
> řešit takovou drobnost je zbytečné
V tom se mýlíte. Není to drobnost a řešit by ji sysadmin rozhodně měl. Nebo by se nad tím měl alespoň zamyslet - zvážit svoji volbu. Neznám moc lidí, pro které e-mail není kritickou službou.
viz má reakce o kousek výše (https://www.root.cz/clanky/stavime-vlastni-e-mailovy-server-webmail-rainloop/nazory/928643/)
-
daemon (neregistrovaný)
Rozumím Tvému stanovisku. Někteří ale mají - bohužel - tu smůlu, že pracují v podniku, kde zákazník/klient je až na prvním místě a platí, že "náš zákazník, náš pán". A pokud zákazník z jakéhokoliv důvodu, byť by to měla být třeba jeho vlastní hloupost, odesílá přílohy jako MS TNEF, je na nás, jako dodavateli, abychom mu vyhověli. Protože zákazník je ten kdo nás živí a my chceme jeho prachy. A když budeme dělat obstrukce, rád si tu službu/zboží koupí od někoho jiného, kdo má vstřícnější IT, které si TNEF umí ošetřit. Může se nám takový stav věci klidně i nelíbit, ale taková je realita.
-
Ono je to potřeba správně podat. Pokud se jedná o našeho zákazníka a navíc jsme v roli nějakého IT dodavatele, potom je lepší zákazníka upozornit na to, že my si s tím poradíme, ale někdo jiný by nemusel (pro změnu jejich zákazníci) a že uvést to do "lepšího stavu" je otázka několika kliků v nastavení, rozhodně se tím nic nerozbije a naopak to může externí komunikaci usnadnit. Já vím, je to případ od případu, ale zrovna toto se dá celkem dobře obhájit, vyargumentovat a pokud na druhé straně nesedí nějakej mamlas, rád si to překliká.
-
daemon (neregistrovaný)
No tak zrovna z pozice IT dodavatele bych se zákazníky snažil edukovat. To by ještě bylo fajn. Píšu spíš o dodavateli nějaké obecné komodity, služby nebo zboží, především retailovému zákazníkovi (ale ono to platí i o leckteré menší firmě). A tam právě může nastat nějaké to pnutí. Protože takový retailový zákazník býva zpravidla velmi náročný (přece platí těch pár stovek) a taky velmi tvrdohlavý (nám to se všema funguje, jste jediní komu ne -> problém je u vás). Nebo na druhé straně je naopak velká korporace, ideálně nějaká finanční instituce jako banka nebo pojišťovna. Tam mají většinou Outlook/Exchange a z pozice korporace se nebudou s nikým bavit. Chcete s náma dělat bussiness, tak se koukejte podle toho zařídit.
Zkrátka, chci říct, že mnohdy je lepší řídit se pravidlem, že "moudřejší ustoupí" a raděj hledat způsob jak si TNEF ošetřit, než důvod, proč TNEF nejde ošetřit. Ale jo, jde mi tenhle stav světa pěkně na nervy. -
Papundekl (neregistrovaný)
Já si říkám, proč je ten e-mail tak strašně složitý. V minulosti jsem zkoušel to na serveru rozchodit, ale vzdal jsem to. Přitom zprovoznit XMPP/Jabber server (konkrétně Prosody) je věc na patnáct minut i se čtením manuálu. Tím myslím zprovoznění základu, ale i ten základ hned funguje. A přitom XMPP a e-mail jsou co do účelu podobné - přenášení zpráv mezi počítači.
-
Unknown (neregistrovaný)
SMTP je temer 40 let stary protokol, poplatny dobe ve ktere vznikal (malo standardizovane prostredi siti, pomale, drahe a malo spolehlive linky, atd). Tim ze je tu tak dlouho, tak se stal de-facto standardem pro komunikaci mimo realny cas, nemit (krome jinych komunikacnich kanalu) mail si dnes na internetu muze dovolit skutecne jen malokdo a kdyz k tomu pripocteme decentralizovanou architekturu tak je to stale zdaleka nejefektivnejsi kanal pro sireni SPAMu a malware. Tyhle vsechny veci jepri nasazeni treba resit a pokud by se XMPP (nebo nejaky jiny) protokol dostal do podobne situace, dopadne to s nim IMHO velmi podobne.
-
Unknown (neregistrovaný)
Ptat se me proc na svete neco nevzniklo je skutecne inteligetni otazka ;-)
SMTP je z doby kdy internet byl jeste povytce domenou akademiku, podle meho soudu uz dnes zadny "velky" (cti masove uzivany) protokol nevznikne jinak, nez ze ho sepise a protlaci velka firma (jako treba SPDY/HTTP2), pripadne jejich konglomerat. Protokol IPv6 vznikal v boardu a vidite sam v jak bolestne a pomalu se rozsiruje (i kdyz tady to dost brzdi i navaznost na HW). A kdyz uz si nekdo da praci s nasazenim a odladenim postovniho reseni, tak to pak vetsinou pomerne dobre funguje a k zasadni zmene neni duvod.
-
BobTheBuilderStříbrný podporovatelTak samozřejmě, že vznikl. Dokonce se to v Německu docela používá/používalo - X.400 - https://cs.wikipedia.org/wiki/X.400
Zlatý SMTP. X.400 totiž psala komise, a ještě ke všemu ITU, takže se message handling pokusili provést podobně, jako mezinárodní telefonní síť, včetně možnosti tarifikace (přece nebude někdo posílat zprávy zadarmo, to by tak hrálo). Aby to mohlo fungovat, vyžadovalo to adresářové služby X.500 (z toho nakonec vznikl použitelný klon nad TCP/IP, známý jako LDAP). -
BobTheBuilderStříbrný podporovatel
To je možné, jednak v tom Německu museli samozřejmě udělat gateway do SMTP a jednak nakonec rezignovali na klíčový počáteční moment - totiž, že X.500 je spravovaný centrální státní autoritou (v představách ITU tehdy všude monopolní PTT) a s tím související message handling (X.400) pak taky, takže bychom dnes měli mezinárodní e-mailovou ústřednu patřičně účtující mezinárodní e-maily a na takovou cochcárnu, jako že máte u nás doménu .com, tak to ani náhodou.
Věc úplně nezjednodušilo ani to, že referenční implementace byla postavená na ISO OSI a použít TCP/IP pro transport nebylo úplně triviální. Jen pro upřesnění, já jsem se s tím setkal někdy 1992, to ještě u nás e-mail chodil přes UUCP a někde se docela vážně uvažovalo o nasazení IPX/SPX. TCP/IP bylo v řadě systémů za příplatek. Za nějaký rok dva už bylo všechno úplně jasné i u nás. -
muf (neregistrovaný)
Ono to tak složité není. Pokud třeba nainstalujete CentOS, i pokud zvolíte kombinaci sendmail/procmail/dovecot (ano, ta není moc frikulínská), většinu z toho máte připravenou.
Vygenerovat 2 certifikáty, přidat spamassassin(také balík v distru) a případně ClamAV přes milter také nezabere moc času. Cesta, kterou ukazuje autor není jediná možná. Je spíš taková tak trochu jirsákovská. -
LDP (neregistrovaný)
Ještě jednou dotaz k minulému dílu, který v diskuzi zůstal bez odpovědi...
Pokud nastavím DMARC dle návodu a pokouším se odeslat poštu z klienta (např. Thunderbird) prostřednictvím submission, pak server zprávu odmítne:
5.7.1 rejected by DMARC policy for ...Pro tento případ pomůže přidat IP adresu providera do souboru /etc/opendmarc/ignore.hosts. Co ale v případě, kdy se pokaždé připojuji z jiného místa nebo s jinou adresou?
-
j (neregistrovaný)
To ti neco dost nefunguje ... mel bys mit povoleny autentizovany uzivatele.
neco na to tema
submission inet n - n - - smtpd
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...Co ktera volba dela si uz pocitam najdes.
-
No buď je chyba v nastavení submission, nebo je špatně nastavený klient nepoužívá port 25?. V master.cf by pro submission mělo být
-o smtpd_milters=inet:localhost:8891
což je jen DKIM, který by měl správu podepsat, přes DMARC přesně z těchto důvodů vlastní zprávy neposíláme, protože by kontrola neprošla.
-
greensmileStříbrný podporovatel
Problém se změnou hesla jsem vyřešil pomocí pluginu postfixadmin-change-password. Vyplní se údaje potřebné pro napojení do databáze postfixadminu z minulé části seriálu a fachá to včetně restrikcí na tvar hesla.
-
smal (neregistrovaný)
Ahoj, nemas tam nekonzistenci v tech cislech portu pro SELinux?
v logu a grepu mas 143|587|4190, ale pises ze hledas 993 (a ne 143)
Diky za super dalsi dil! A jsem rad ze to mas i se sifrovanim - jak uz tu zaznelo, kazdy se muze rozhodnout sam, jestli to preskoci nebo ne, a takhle je ten popis kompletni... -
robotron (neregistrovaný)
Serial se mi libi a castecne se z nej i zrovna inspiruju pri konfiguraci serveru.
Pokud jsem to prehledl: existuje nejaka argumentace proc RainLoop a ne RoundCube? RL z pohledu uzivatele neznam, RC jsem kratkou dobu pouzival a pripadalo mi to po predchozi zkusenosti s dobrou, lec ponekud jiz chudsi pribuznou veverkou jako hodne vymazleny. Taky koukam, ze RC ma i v postarsich Debianech balicek, jak moc pouzitelnej, zatim nevim.
-
Killer feature je to, že je to jiný systém, který není na rozdíl od RC tak známý, někomu prostě může vyhovovat víc, tak jsem ho chtěl trošku zviditelnit. Na domácí mailování pro rodinu mi přijde fajn, ne-IT lidi z mého okolí, kterým jsem to ukázal, to prostě žerou. Já osobně taky raději používám RC, není to tak strašně zmalovaný a hejbací.
-
Petr (neregistrovaný)
Hezky popsane, jak si postavit auto sam. Ja si myslim, ze takto se resily mail severy cca 15 let zpet, kde si clovek vsechno musel "poladit" sam. Dneska vezmu treba Zimbru a mam vse hotove. Myslim free verzi, ktera je dostacujici na vsechno.
Drive mozna bylo vice casu si "hrat" se vsim je pravda. -
Já nevím, jak to chodí jinde, ale u nás má každá část infrastruktury přidělené správce, kteří by měli alespoň tušit, co jejich systémy dělají a proč. A je jedno, jestli si to postavíš sám, nebo použiješ Zimbru, iRedMail, nebo něco takovýho. Základ je pořád víceméně stejnej a není od věci o něm něco vědět.
-
greensmileStříbrný podporovatel
"Mám spoustu poznámek a námětů z diskuzí, určitě si popíšeme něco ohledně dalšího zabezpečení,..."
A furt nic. Dočkáme se? :-)
ČLÁNKY DO MAILU