Jak co nejjednodušeji udělat záložní MX server?

[scientific]

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.

[Reklama]

[Jan Forman]

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.

[Filip Jirsák]

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.

[FKoudelka]

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

[FKoudelka]

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í

[Reklama]

[Filip Jirsák]

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ší ;-)

[_mbily]

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.

[mhepp]

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

[RDa]

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 :)

[FKoudelka]

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  :-)

[FKoudelka]

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

[Filip Jirsák]

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.

[FKoudelka]

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 ?

[analogic]

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

[mhepp]

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