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

[czechsys]

Dejte pred MX nejakou postovni proxy.

[Reklama]

[Filip Jirsák]

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

[_mbily]

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

[jvb]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

muj@email.cz OK
dalsi@email.cz OK

/etc/postfix/relaysync/relay_domains

Kód: [Vybrat]

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

Kód: [Vybrat]

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

[analogic]

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.

[Reklama]

[Filip Jirsák]

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.