Stavíme poštovní server – 16 (záložní server): Příkaz ETRN

23. 3. 2010 | Lukáš Jelínek | Sítě | 19513×

Příkaz ETRN

Za normálních okolností to (v případě programu Postfix) funguje tak, že záložní server zkouší s prodlužující se periodou doručit přijaté zprávy primárnímu serveru. Zejména při delším zadržování to však znamená, že od okamžiku, kdy je primární server dostupný, do doručení zpráv může uběhnout dlouhá doba. Aby šlo zprávy doručit dříve, existuje v rozšíření protokolu SMTP (konkrétně v RFC 1985) příkaz ETRN.

Obdrží-li záložní server příkaz ETRN (pro určitou doménu, uvádí se v argumentu příkazu), zahájí doručení zpráv, a to obdobně, jako kdyby šlo o spontánní doručení (tedy vytvoří novou SMTP relaci, ve které zprávy předá, pokud nějaké zadržoval). Hodí se to pro - dnes již naštěstí velmi řídké – případy, kdy je primární server připojen přes dial-up nebo nějaké velmi nespolehlivé připojení.

Pokud není žádoucí, aby se záložní server pokoušel zprávy automaticky doručovat, lze to zajistit příslušným nastavením v souboru master.cf. Běžně není důvod to dělat, ale kdyby to někoho zajímalo, návod najde v dokumentaci k Postfixu.

Ohledně příkazu ETRN je důležité, aby byl záložní server správně nastaven, jinak příkaz nefunguje (server ho odmítne). Je to řízeno dvěma parametry – jednak fast_flush_domains (specifikace domén, pro které je příkaz povolen) a dále pak smtpd_etrn_restrictions (restrikce na příkaz ETRN).

Parametr fast_flush_domains má výchozí hodnotu odpovídající parametru relay_domains. To je výhoda v případě, že se pro testování domén využívá tento parametr (viz výše), ale nevýhoda v případě, že se domény testují jen podle MX záznamů. Pak je lepší povolit ETRN pro všechny domény, například takto:

fast_flush_domains = static:any

Výsledkem dotazu na libovolnou doménu bude natvrdo hodnota „any“ (resp. lze použít cokoli neprázdného; hodnota „any“ má význam pro srozumitelnost konfigurace), proto bude příkaz povolen. Pro úplné vypnutí ETRN pro všechny domény by stačilo použít toto:

fast_flush_domains =

Dále lze nastavit oprávnění vůbec používat ETRN. Ve výchozím stavu je povolen neomezeně, což není úplně to pravé ořechové, protože by mohl být zneužit k DoS útoku (hlavně při větším počtu zadržovaných zpráv může být režie ETRN významná). Proto ho lze omezit například takto:

smtpd_etrn_restrictions =
  permit_mynetworks,
  reject

Tím se umožní přístup jen z vlastních sítí. Lze používat klasické metody omezování přístupu známé z jiných restrikcí. Příkladem může být třeba toto:

smtpd_etrn_restrictions =
  sleep 5,
  check_etrn_access hash:/etc/postfix/etrn,
  permit_mynetworks,
  reject

Takovéto nastavení bude po příkazu ETRN vždy čekat 5 sekund (dobré jako ochrana proti DoS), pak prověří doménu v hešové mapě v uvedeném souboru (lze zakázat některé domény i pro přístup z vlastních sítí a naopak některé povolit odkudkoliv). Možností je mnoho, například lze vyžadovat klientský certifikát, testovat existenci reverzního DNS záznamu či třeba dotazovat vzdálené blacklisty.

Vyvolání příkazu ETRN

Zajímavá a důležitá otázka je, jak odeslat příkaz ETRN záložnímu serveru. Odpověď je jednoduchá – musí se o to postarat správce. Primární server (ve smyslu jeho SMTP služby) nesleduje, kdy je dostupný zvenčí, kdy na něj lze doručovat poštu.

V první řadě je třeba identifikovat stavy, kdy server začne být (po nedostupnosti) opět dostupný. Takovými stavy je samotné spuštění Postfixu a také aktivace příslušných síťových rozhraní. Nejjednodušeji to lze tedy realizovat tak, že se do skriptů spouštěných v uvedených případech přidá zavolání příslušné akce, které bude předcházet dostatečná čekací doba, aby byl server plně připraven (např. 10 sekund).

K odeslání příkazu lze použít například program fetchmail, který je standardně dostupný v podobě balíčků pro všechny běžné distribuce. Příkaz pro odeslání příkazu by vypadal například takto:

fetchmail -p ETRN --fetchdomains moje.domena postak-zalozni.moje.domena

Tento příkaz způsobí, že se záložnímu serveru odešle příkaz ETRN pro doručení pro doménu moje.domena. Pokud by bylo potřeba vyžádat doručení pro více domén, uvedly by se jako seznam.

Lze samozřejmě poměrně snadno zajistit, aby se příkaz ETRN posílal i na základě skutečné dostupnosti zvenčí. K tomu poslouží monitorovací program (např. monit), který bude periodicky testovat dostupnost záložního serveru a pokud dojde k obnovení dostupnosti po období nedostupnosti, zavolá program k odeslání příkazu ETRN.

Silnější zabezpečení

Pokud si nakonfigurujete záložní server takto jednoduše, bude sice hladce fungovat, současně se ale brzy stane cestou, kterou se bude na hlavní server tlačit zbytečný spam. Proto je žádoucí server silněji zabezpečit (základní restrikce jsou již uvedeny v prvním příkladu, ale to je opravdu jen úplné minimum).

Podrobné informace o ochraně proti spamu najdete v 9. až 11. dílu seriálu. Většina popsaného platí prakticky ekvivalentně i pro záložní server, samozřejmě s nutností přizpůsobení některých věcí. Co se týká samotného Postfixu, do main.cf se vyplatí přidat následující řádky:

smtpd_client_connection_rate_limit = 10
smtpd_client_message_rate_limit = 20
smtpd_client_recipient_rate_limit = 200
smtpd_recipient_limit = 100
smtpd_recipient_overshoot_limit = 10

Limity jsou oproti hlavnímu serveru nastaveny tvrději, což má v tomto případě svůj smysl. Je to proto, že záložní server se k příchozím legitimním zprávám v praxi dostane dost zřídka (jen při nedostupnosti primárního serveru), naopak bude velmi často konfrontován se spamem. Konkrétní hodnoty nejsou samozřejmě žádné dogma, nechť si je každý upraví podle potřeb a zkušeností.

amavisd-new, Spamassassin a ClamAV

Na použití programů pro ochranu proti spamu a virům se oproti primárnímu serveru nic nemění. Sice by se dalo spekulovat o možnosti nekontrolovat na hlavním serveru zprávy, které už byly zkontrolovány na serveru záložním, ale zejména u virů to není dobrý nápad (mezi doručením na záložní server a předáním na server primární může být do databáze doplněn virus, který by jinak nebyl zachycen).

Prahy pro hodnocení zpráv lze na záložním serveru nastavit o něco přísněji, protože legitimní zprávy se na něm budou vyskytovat jen výjimečně a není tedy příliš pravděpodobné, že by byla nějaká neoprávněně zahozena.

Co si však zaslouží úvahu, je učení bayesovského filtru. Na záložním serveru to může být docela problém, protože materiálu pro učení (zejména legitimních zpráv) moc není a hlavně nelze vycházet z toho, jak zprávy hodnotí uživatelé.

Možností, jak to řešit, je více. Asi nejjednodušší je periodicky (např. jedenkrát denně) přenášet obsah databáze primárního serveru na server záložní. Čistá metoda je export databáze do souboru, přenos tohoto souboru na záložní server a import do databáze z přeneseného souboru. Není potřeba nijak řešit vlastnosti databází ani vlastnosti architektur obou serverů.

Jak bude konkrétně celá operace realizována, to už záleží na správci serverů (celé řešení samozřejmě předpokládá, že záložní server slouží právě jednomu primárnímu serveru). Lze ji celou provést z primárního serveru, ze záložního serveru, případně kombinovaně. Následující popis bude vycházet z první varianty, tedy z řešení na primárním serveru. Tam se vytvoří následující skript (umístěný například v /etc/cron.daily na primárním serveru):

#!/bin/bash

BACKUPPATH=/var/lib/spamassassin/sa.backup
sa-learn --backup > $BACKUPPATH
sftp -b /etc/sftp/sa-sync postak
ssh postak sa-learn --restore $BACKUPPATH && rm $BACKUPPATH

Uvedený skript předpokládá, že se lze ze záložního serveru na ten hlavní přihlašovat certifikátem pod vhodným uživatelem (postup při nastavení najdete například v manuálu k ssh – přesahuje rámec tohoto článku). Pro samotný přenos přes SFTP se použije skript /etc/sftp/sa-sync s příkazy pro SFTP. Ten může vypadat například takto:

put /var/lib/spamassassin/sa.backup /var/lib/spamassassin/sa.backup
quit

Funkce obou skriptů je z jejich obsahu zřejmá. Bylo by samozřejmě žádoucí je přepsat do čistší podoby, aby byly schopny správně vyhodnotit všechny chyby, které při přenosu mohou nastat, a vypsat o tom zprávu do logu.

       

Komentáře

Diskuse byla administrátory uzamčena

[kolcon]

a nestacilo by na tom zaloznim serveru proste nastavit relay_host ?

[Luk]

Jde o to, co znamená to "prostě nastavit". Bez kombinace s restrikcemi to nejde, jinak z toho bude open relay se všemi důsledky. Kromě toho je zbytečné to nastavovat, když záložní server ví, kam má zprávy předávat (dozví se to z MX záznamů). Pokud navíc záložní server slouží více primárním serverům, ani to nastavit nejde, protože jsou ty servery různé.

[Petr Horacek]

Je mozne nejakym podobnym zpusobem postavit ne jen zalozni, ale duplicitni mail server takovy, ze v pripade vypadku primarniho prevezme v plne siri jeho ulohu (vcetne uzivatelskych uctu, stavajicich dat a podobne), a to idealne transparentne, bez nutnosti prekonfigurovat MUA? Tahove high-availibility reseni.

Dekuji za odpoved.

[Luk]

Bez nutnosti překonfigurovávat MUA to bude docela problém. Buď by musely být DNS záznamy s TTL=0 (nebo hodně nízkou hodnotou) a spoléhat se na to, že si to cachující servery nebudou vykládat po svém. Pak by se musely odněkud ty DNS záznamy měnit podle dostupnosti serverů. Druhá možnost je z to z IP adresy uvedené v DNS to tunelovat jinam, ale to už se zavádí single point of failure (když selže, selže všechno).

Samozřejmě duplicitní server postavit lze, s uživatelskými účty není problém (ať už jsou v databázi, přes LDAP, případně souborově). Zbývá vyřešit jediný problém, a to je úložiště. Pokud bude vzdálené (v technologickém smyslu) a transparentně synchronizované mezi různými geografickými místy, opět to není až tak velký problém.

[tomfi]

Sakra, to jsem nějak zaspal dobu... myslel jsem, že standardně lze pro účely "sdílení" IP použít vrrp, carp, různé formy natu alá load-balancing atd...

ale co, možná i to DNS někdo považuje za failover technologii, i když je to trochu podle hesla "když to nezvládnu nastavit na serveru tak ten problém přenesu jinam (na klienta) :D"

[petr_p]

Problém je ve sdílení IP. K čemu mi je cluster, když se k němu klient nedostane.

[Luk]

standardně lze pro účely "sdílení" IP použít vrrp, carp, různé formy natu alá load-balancing atd.

To lze, ale jen v případě, že jsou cílové servery v jedné síti. Pokud jsou v různých sítích (nejlépe geograficky vzdálených), pak je to mnohem problematičtější. Nevím jak obecně ve světě, ale mám pocit, že tady v Česku jsou problémy zasahující celý telehouse nebo jeho velkou část (ať už souvisí s napájením, s routery nebo něčím jiným) dost časté na to, aby high availability řešení s tímto mělo počítat.

[Duskol]

Pripada mi to zbytecne, muze mi nekdo rici v cem je vyhoda mit MX backup ? kdyz v pripade nedostupnosti mailserveru zustava nedorucena posta ve spoolu na smtp serverech po dobu peti dnu ( default ) se je postak snazi co 30 minut odeslat.

[Luk]

Pripada mi to zbytecne, muze mi nekdo rici v cem je vyhoda mit MX backup ?

Je samozřejmě pravda, že "nejlepší léta" záložních serverů jsou už pryč, protože spolehlivost internetových připojení je dnes už taková, že většinou záloha není potřeba. Nicméně někdo se může rozhodnout, že záložní server používat bude.

kdyz v pripade nedostupnosti mailserveru zustava nedorucena posta ve spoolu na smtp serverech po dobu peti dnu ( default ) se je postak snazi co 30 minut odeslat.

Na tohle nelze až tolik spoléhat. Jednak těch 5 dnů je opravdu jen default a nikdo nebrání správci nějakého serveru tu dobu zkrátit třeba na 1 den.

Dále neplatí to tvrzení o 30 minutách. Jednak velmi záleží na konkrétním serveru, jeho chování a konfiguraci (např. Postfix standardně doručovací pokusy opakuje v prodlužujících se intervalech). Současně je potřeba brát v úvahu zatížení konkrétních serverů, takže i kdyby byl interval 30 minut, v reálu to může být podstatně víc.

Proto se někdo může rozhodnout, že bude raději používat záložní server, který má ve své moci. Další možností je, že záložní server poskytuje ISP v rámci připojení (v ceně služby) a s předem definovanými parametry chování.

[fanda]

Trochu mi není jasné fungování v případě graylistingu. Pokud mi (ač normálně dostupný) primární server odpoví z důvodu graylistingu, že je dočasně out, nebude se to odesílající server snažit doručit na ten záložní? Když na něm bude graylisting také asi se vrátí s dalším pokusem zas na primární, takže to asi zafunguje, ale nebude to dělat nějakou neplechu?

[Luk]

Pokud mi (ač normálně dostupný) primární server odpoví z důvodu graylistingu, že je dočasně out, nebude se to odesílající server snažit doručit na ten záložní?

Může se pokoušet (nevím, jak který poštovní software vyhodnocuje různé dočasné chyby a jak na ně konkrétně reaguje).

Když na něm bude graylisting také asi se vrátí s dalším pokusem zas na primární, takže to asi zafunguje, ale nebude to dělat nějakou neplechu?

Může se tím prodloužit doba doručení. Ovšem vzhledem k tomu, že u greylistingu je obecně problém s tím, že doba doručení pro první komunikaci může být dlouhá (a podle toho, jak moc to vadí, je potřeba rozhodovat, zda greylisting nasadit), za až tak moc velký problém to nepovažuji.