Fórum Root.cz
Hlavní témata => Server => Téma založeno: scientific 11. 10. 2021, 16:17:42
-
Ahoj všem,
Co mám:
používám ISPConfig administrační panel pro server na kterém máme poštu.
Řešený problém:
Nyní řeším jak vytvořit záložní MX server, který bych dal v DNS velde hlavního MX serveru, akorát s jinou prioritou. Ve výsledku by při výpadku primárního MX serveru měla být pošta směrována na ten záložní MX, kde by se zprávy uložily a počkaly, dokud hlavní MX server nebude zase odpovídat.
Představa o tom, jak by se to asi mělo řešit:
Ideálně bych to řešil bez replikace MySQL databáze s daty o uživatelských schránek. Zřejmě se to dělá jen proto, aby záložní server ihned zahazoval poštu směrující na schránku, která na primárním MX serveru neexistuje. Podle mě to není potřeba.
Úplně nejraději bych to řešil vydeployováním kontejneru s nějakým SW, který přesně k tomu slouží. Že by ten kontejner/jiný VPS sloužil jako backup MX.
Děkuji moc za tipy a rady.
-
Pokud sekundární server a dálší nedokážou ověřit uživatele je lepší takový MX záznam vůbec nemít.
Výsledkem je nekonečné přelévání spamu a neexistujících schránek mezi servery.
Správný stav je, aby záložní servery akceptovali poštu jako primární (ideálně jako HA řešení).
Zachytit ty zprávy a pokoušet se je přeposílat nemá velký smysl, odesílací servery obvykle umí naprosto totéž.
Ahoj všem,
Co mám:
používám ISPConfig administrační panel pro server na kterém máme poštu.
Řešený problém:
Nyní řeším jak vytvořit záložní MX server, který bych dal v DNS velde hlavního MX serveru, akorát s jinou prioritou. Ve výsledku by při výpadku primárního MX serveru měla být pošta směrována na ten záložní MX, kde by se zprávy uložily a počkaly, dokud hlavní MX server nebude zase odpovídat.
Představa o tom, jak by se to asi mělo řešit:
Ideálně bych to řešil bez replikace MySQL databáze s daty o uživatelských schránek. Zřejmě se to dělá jen proto, aby záložní server ihned zahazoval poštu směrující na schránku, která na primárním MX serveru neexistuje. Podle mě to není potřeba.
Úplně nejraději bych to řešil vydeployováním kontejneru s nějakým SW, který přesně k tomu slouží. Že by ten kontejner/jiný VPS sloužil jako backup MX.
Děkuji moc za tipy a rady.
-
Neodmítat poštu pro neexistující uživatele na záložním serveru dnes prakticky nejde. Spousta spammerů toho využívala, že záložní servery tohle nedělaly a rovnou směřovala e-maily na záložní servery. Když záložní server přijme, má zodpovědnost za jeho doručení. Pokud schránka na primárním serveru neexistuje, má poslat odesílateli e-mail o nedoručení – jenže e-mail odesílatele bude obvykle zfalšovaný, takže e-maily o nedoručení budete jen obtěžovat nevinné lidi. Fakticky půjde z vaší strany o spam – a spammeři s tím samozřejmě počítají a to podstatné uvádějí do úvodní části e-mailu, která je v odpovědi o nedoručení citovaná.
Pokud byste chtěl zprávy pro neexistující adresy přijmout a pak zahodit, nedozví se zase odesílatel, který udělal překlep, že zadal špatný e-mail.
Je potřeba počítat s tím, že záložní MX server se u regulérního e-mailu dostane ke slovu akorát v případě, kdy budete mít dlouhodobý výpadek na primárním serveru. Protože krátkodobý výpadek primárního serveru překlene regulérní e-mail tak, že ho u sebe podrží odesílatel ve frontě a zkusí ho odeslat za pár minut znovu.
-
S každým dalším mx serverem roste počet spamů o 100%. Spammery fakt priorita MX nezajímá Nemít na záložním serveru povolené uživatele - o to hůř. Dokud jsem měl záložní MX server u gts (bez ověřování uživatelů samozřejmě),byl právě on zdaleka největším zasilatelem spamu do naší domény, ve výše zmíněné dimenzi. A ještě na mě byli drzí.
-
Ahoj všem,
Co mám:
používám ISPConfig administrační panel pro server na kterém máme poštu.
Řešený problém:
Nyní řeším jak vytvořit záložní MX server, který bych dal v DNS velde hlavního MX serveru, akorát s jinou prioritou. Ve výsledku by při výpadku primárního MX serveru měla být pošta směrována na ten záložní MX, kde by se zprávy uložily a počkaly, dokud hlavní MX server nebude zase odpovídat.
To není nutné, odesílající servery to zkouší poslat znovu , tuším 5 dní
-
To není nutné, odesílající servery to zkouší poslat znovu , tuším 5 dní
Není to žádná globální konstanta. Je na konfiguraci každého klienta (to, čemu vy říkáte „odesílající server“), zda a jak dlouho bude držet e-maily ve frontě a zkoušet je odeslat znovu. Třeba spammeři to často znova vůbec nezkouší ;-)
-
Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.
-
Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.
To je zajímavá úvaha, ale pokud jsou dané servery „koncové“, jak zajistím integritu e-mailových schránek? Vždyť budu mít půlku pošty na jednom a druhou půlku na druhém... Nebo mi něco uniká?
-
Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.
To je zajímavá úvaha, ale pokud jsou dané servery „koncové“, jak zajistím integritu e-mailových schránek? Vždyť budu mít půlku pošty na jednom a druhou půlku na druhém... Nebo mi něco uniká?
Muzete mit prece sdilene uloziste - na tretim pocitaci, nebo nejakou variantu distributed block device a clusterovaciho FS :) Prakticke nasazeni spis vyzaduje 3 nody, kde muze jeden byt restartovan / umrit, protoze se snaz resi kdo ma pravdu (dva prehlasuji jednoho).
Osobne jsem nemel potrebu resit zalozni MX - ze zkusenosti vim, ze klasicka posta se zkousi dorucit cca 2 dny (pak se odesilajici server rozhodne to vzdat a prijde notifikace o nedorucitelnosti), takze pokud jsem schopen resit problemy okamzite (at uz sw update fail.. protoze mam schranky podle DB, nebo stavkujici hw.. ), tak se nic nedeje.
To co se nedorucuje opakovane jsou jednak spamy, a pak ruzne automaticky generovane verifikace typu - tady mate PIN, nebo kliknete na tento odkaz (password reset). Protoze provozuji krutoprisny MX check a vlastni variaci na graylist, tak vidim ze tyhle veci se nikdy nezopakuji - nekdy nezbyva nic jineho nez whitelistovat urcite "cloudove" odesilatele, co neumi retry a pokud umi, tak to zkusi zcela jinej nod.. to pak ani nejobycejnejsi graylist nedava :)
-
To není nutné, odesílající servery to zkouší poslat znovu , tuším 5 dní
Není to žádná globální konstanta. Je na konfiguraci každého klienta (to, čemu vy říkáte „odesílající server“), zda a jak dlouho bude držet e-maily ve frontě a zkoušet je odeslat znovu. Třeba spammeři to často znova vůbec nezkouší ;-)
To nevadí, ale v praxi to víceméně funguje.
Hodní spammeři :-)
-
Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.
Promiňte, jak říkám, spam se nerozloží, ale zdvojnásobí.
-
Promiňte, jak říkám, spam se nerozloží, ale zdvojnásobí.
To těžko. Spammer nemá důvod ten samý e-mail posílat stejnému adresátovi přes jiný server, když místo toho může poslat e-mail někomu jinému.
-
Promiňte, jak říkám, spam se nerozloží, ale zdvojnásobí.
To těžko. Spammer nemá důvod ten samý e-mail posílat stejnému adresátovi přes jiný server, když místo toho může poslat e-mail někomu jinému.
A kdo říká, že to bude ten stejný spammer ?
-
Nedělejte to. Přiděláte si víc starostí než užitku.
SMTP samo o sobě je navrženo tak dobře, že s výpadkem na několik hodin se doslova počítá. U našeho mailserveru (shameless plug https://poste.io) se doručuje až třináctkrát, poslední pokus je po jeden a půl dni. Až teprve potom to vzdá a vygeneruje bounce. Ostatní MTA to mají obdobně.
Pokud byste přecejen nutně potřeboval záložní MX bez databáze tak si dejte záležet na nastavení. Z hlavy mi napadá, že musíte vyřešit jak předat spamfiltru info o zdrojové IP a bounce message pokud možno úplně zakázat. Jak už tu někdo podtknul, 99% provozu záložního mailserveru bude spam, který následně váš hlavní mailserver bude zahazovat.
Pochopitelnější už je HA celého mailserveru včetně IMAPu/POP3, ale to jednak opravdu potřebuje málokdo a jednak to je úplně jinej level komplikací.
-
Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.
To je zajímavá úvaha, ale pokud jsou dané servery „koncové“, jak zajistím integritu e-mailových schránek? Vždyť budu mít půlku pošty na jednom a druhou půlku na druhém... Nebo mi něco uniká?
Muzete mit prece sdilene uloziste - na tretim pocitaci, nebo nejakou variantu distributed block device a clusterovaciho FS :) Prakticke nasazeni spis vyzaduje 3 nody, kde muze jeden byt restartovan / umrit, protoze se snaz resi kdo ma pravdu (dva prehlasuji jednoho).
Pokud mám mailový server někde v hostingu, tak záložní chci mít v jiném hostingu z důvodů od různého „špinění“ adres až po fatální výpadek datacentra. Potom je sdílený FS trochu problém, protože dostupnost a latence, případně šifrování a celkově úzké hrdlo, single point of failure a tak. Takže toto řešení naopak spíše snižuje doručitelnost pošty...
-
Dejte pred MX nejakou postovni proxy.
-
SMTP samo o sobě je navrženo tak dobře, že s výpadkem na několik hodin se doslova počítá. U našeho mailserveru (shameless plug https://poste.io) se doručuje až třináctkrát, poslední pokus je po jeden a půl dni. Až teprve potom to vzdá a vygeneruje bounce. Ostatní MTA to mají obdobně.
Já bych záložní mail server úplně nepodceňoval. Jeden a půl dne není zas tak dlouho, vzpomeňte na požár datacentra OVH. Záložní mail server třeba nemusí být aktivní, nemusí být uveden v DNS – ale měl bych být schopen náhradní server během pár hodin zprovoznit a přesměrovat na něj příchozí provoz. Samozřejmě že aktivní server, na který směřují MX záznamy nižší prioritou, tohle splňuje a může to být lepší řešení, než něco zprovozňovat až v případě problémů.
Ale pořád platí to nejdůležitější pravidlo – všechny záložní poštovní servery musí být při příjmu e-mailů stejně přísné, jako hlavní server. Tj. musí odmítat neexistující adresáty, musí používat stejnou antivirovou a antispamovou ochranu, pokud používáte greylisting, musí být i na záložním serveru. Jakmile bude záložní server v něčem benevolentnější, nemusíte tu přísnější ochranu mít ani na hlavním serveru, protože útočníci vám to budu cpát skrze ten záložní. (A navíc si tím jenom podstatně zkomplikujete život, protože nebude váš hlavní server odmítat e-maily přímo spammerovi, ale bude je odmítat vašemu záložnímu serveru. Takže problémy a rostoucí frontu nebude řešit spammer, ale vy.)
Takže jestli potřebujete záložní server, nebo z toho rovnou uděláte load balancer, nebo jestli vám stačí studená záloha, t oje vaše rozhodnutí, to vám asi nikdo neporadí, bez detailní znalosti vašich podmínek. Ale počítejte s tím nejdůležitějším pravidlem uvedeným v předchozím odstavci. Takže pokud nedokážete databázi uživatelé replikovat i na záložní server, záložní server vůbec nedělejte. (Mimochodem, ta databáze uživatelů nemusí být plnohodnotná databáze a nemusí být každou milisekundu shodná s hlavní databází. Pokud to jinak nejde, seznam uživatelů vysypaný do textového souboru a synchronizovaný jendou za 5 minut přes rsync je použitelné řešení. Mít na záložním serveru doménový koš není řešení.)
-
To je zajímavá úvaha, ale pokud jsou dané servery „koncové“, jak zajistím integritu e-mailových schránek? Vždyť budu mít půlku pošty na jednom a druhou půlku na druhém... Nebo mi něco uniká?
Přijatá zkontrolovaná pošta se doručí/uloží do mailboxů na třetím stroji. A na něm poběží i imapd, webmailová aplikace a podobné věci. Jen s tímto serverem komunikují koncoví uživatelé. V případě většího počtu uživatelů a důležitosti pošty může být i to rozdělení aplikací na dvě množiny pro admina celkem příjemné. Nemáte na serveru širokou paletu aplikací, lépe se ladí výkon jednotlivých strojů, sw upgrade může být méně bolestivý.
-
Ahoj všem,
Ideálně bych to řešil bez replikace MySQL databáze s daty o uživatelských schránek. Zřejmě se to dělá jen proto, aby záložní server ihned zahazoval poštu směrující na schránku, která na primárním MX serveru neexistuje. Podle mě to není potřeba.
Ahoj, replikace cele databaze neni nutna, staci nejak dodat seznam domen a adres, treba i v textaku - jednoducha vec. Dam priklad pro postfix (bez filozofickych kktin typu jestli to ma nebo nema smysl a jen to tema unasi do sracek - root typical).
main.cf
...
relay_domains = $mydestination
lmdb:/etc/postfix/relaysync/relay_domains
relay_recipient_maps =
lmdb:/etc/postfix/relaysync/relay_recipient_maps
relay_transport = relay
relayhost = tvuj.mailserver:25 (nebo jinej MX na perimetru)
...
/etc/postfix/relaysync/relay_recipient_maps
muj@email.cz OK
dalsi@email.cz OK
/etc/postfix/relaysync/relay_domains
email.cz OK
domena.cz OK
Jako milter si dej rspamd, a jeste nasad postscreen (http://www.postfix.org/POSTSCREEN_README.html), nejak takhle treba
postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites =
zen.spamhaus.org*2
bl.spamcop.net*1
b.barracudacentral.org*1
bip.virusfree.cz
bad.virusfree.cz
A budes docela v pohode ;)
-
Já bych záložní mail server úplně nepodceňoval. Jeden a půl dne není zas tak dlouho, vzpomeňte na požár datacentra OVH.
Ale určitě! Je na zvážení každého jestli není lepší, že po dni a půl odesílatel dostane upozornění, že adresát email nepřijmul nebo že zpráva leží na cestě. Anebo jinak, jestli stojí za to investovat čas a peníze kvůli něčemu co se úplně běžně neděje. Jsou tací, kteří to určitě potřebují, ale z malých a středních firem jsem nepotkal žádnou.
Ono to lze pojmout i takto, pokud firma nedokáže za den nahodit mailserver ze záloh, asi by si neměla zprovozňovat záložní SMTP jako řešení potenciálního problému.
-
jestli není lepší, že po dni a půl odesílatel dostane upozornění, že adresát email nepřijmul nebo že zpráva leží na cestě.
Právě že je docela pravděpodobné, že žádné takové upozornění nedostane. Dneska je možné posílat nedoručenky jedině v případě, že jste si hodně jistý tím, kdo je skutečný odesílatel e-mailu.
Ono to lze pojmout i takto, pokud firma nedokáže za den nahodit mailserver ze záloh, asi by si neměla zprovozňovat záložní SMTP jako řešení potenciálního problému.
Jenže ono to právě není takhle jednoduché. Klidně můžete server za den obnovit ze záloh, ale pokud máte v DNS MX záznam s platností 7 dní a vede na starou IP adresu, bude vám to k ničemu. Proto jsem psal o tom, že nejdůležitější je mít předem rozmyšlené a předem připravené, jak bude takové záložní řešení vypadat. Teprve z toho vyplyne, jestli záložní řešení je „umím přehodit příjem pošty na jiný server dřív, než se e-maily začnou ztrácet z front“, nebo jestli záložní řešení je „stejně potřebuju někde trvale běžící SMTP server, tak proč ho rovnou nezveřejnit v DNS?“
Mimochodem, e-mail dneska slouží jako hlavní identifikační prostředek. Takže osobně nepovažuju za největší problém to, že nějaká obchodní poptávka dorazí až za den a možná na ni jiná firma odpoví dřív. Větší problém je to, že zaměstnanci mé firmy nebudou moci resetovat zapomenuté heslo do nějakého systému, nebudou se moci někam zaregistrovat apod. Nebo jim nebudou chodit nějaké notifikace, že mají schválit odchozí platbu, že je nějaký systém přetížen apod. To může způsobit daleko vážnější problém.