Stavíme poštovní server – 16 (záložní server): Greylisting

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

Greylisting

Také na záložní server lze nasadit greylisting, a opět je to velmi žádoucí. Možná neškodí nasadit ho i v případě, že na hlavním serveru nasazen není. Je však potřeba dát si pozor na to, aby všechny výjimky nastavené na primárním serveru byly nastaveny i zde. O to se může opět postarat nějaký synchronizační mechanismus, ať už takový, jako je uveden výše (s tím, že se po přenosu vynutí načtení souborů), nebo například realizovaný pomocí rsync (zde je výhoda v tom, že na druhé straně není potřeba provést žádnou akci, stačí synchronizovat soubory).

Při využití programu Postgrey bohužel nelze jednoduše synchronizovat databázi, takže je třeba se buď smířit s tím, že se budou záznamy na záložním serveru vytvářet samostatně, anebo použít nějaký jiný software, který synchronizaci databáze umožňuje. Například SQLgrey, Gld nebo Policyd.

Ověřování existence schránek a aliasů

Zatím záložní server testoval (z hlediska možnosti doručení) jen to, zda doručuje do určitých domén. Neověřoval ale, zda existují schránky či aliasy, pro které jsou zprávy určeny. To samozřejmě znamená, že se na něm mohou hromadit zprávy, které nebudou nikdy doručeny (po pokusu doručit je budou vráceny zpět). Většinou půjde o spam, který se nepodařilo eliminovat nějakou antispamovou metodou a zbytečně zabírá místo ve frontě.

Klíčový problém je dostupnost databází schránek a aliasů. Pokud jsou v souborech, je třeba zajistit synchronizaci. SQL databáze může běžet v replikovaném režimu (při kterém na záložním serveru funguje jako slave, tedy jako podřízená instance). Komplikace mohou být u využití LDAP, pokud tento funguje například jen uvnitř firmy (pak se musí buď zajistit replikace – v závislosti na možnostech konkrétní implementace LDAP – nebo prostě vůbec ověřování schránek nevyužívat).

Je-li vyřešen předchozí problém, zbývá ještě správně nakonfigurovat Postfix. Oproti serveru, který přímo doručuje do uživatelských schránek, se musí změnit jedna zásadní věc: transporty. Zatím o nich v rámci celého seriálu prakticky nebyla řeč, nicméně jde o poměrně významnou součást celé architektury Postfixu.

Postfix totiž funguje tak, že není pevně dáno, jak se s každou zprávou naloží. Existují sice výchozí modely chování, ale to vůbec neznamená, že je nelze změnit. Lze nadefinovat, jak program naloží s každou jednotlivou zprávou – a to jak přímo na bázi příjemců a domén, tak i funkcí serveru. Existuje základní výchozí transport, lokální transport (doručení lokálnímu příjemci), virtuální transport (doručení virtuálnímu příjemci) a transport pro relay (vzdálené doručení).

Pro běžné role serverů není potřeba do transportů zasahovat. Ovšem pokud má být něco jinak, než je obvyklé, je třeba transporty přenastavit. To je i případ záložního serveru, který ověřuje příjemce v databázi. To lze dělat na bázi doručování místním nebo virtuálním příjemcům – ale protože se zde nemá doručovat do schránek (nýbrž předávat primárnímu serveru), musí se upravit lokální, resp. virtuální transport.

Ověřování virtuálních příjemců

Lze si to ukázat na situaci, ve které jde o virtuální příjemce (pro lokální by to bylo velmi podobné). Místo přímého doručování (například do úložiště typu Maildir) se použije doručování vzdálené, tedy relay. Záložní server tedy ověří příjemce, ale ponechá si zprávu ve frontě pro doručení na primární server.

virtual_transport = relay:
virtual_mailbox_domains = moje.domena
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual

Uvedený příklad je určen pro uživatele a aliasy v souborech (konkrétně hešových mapách), seznam domén je uveden přímo v parametru virtual_mailbox_domains (další možnosti jsou popsány v 6. dílu seriálu). Když bude nyní vytvořena příchozí SMTP relace s pokusem doručit neexistujícímu příjemci či aliasu, server neexistující adresu odmítne. Pro platné adresy zprávu přijme a doručí ji na primární server.

Všimněte si, že už se neuvádějí další parametry používané při doručování virtuálním příjemcům (umístění schránek, identifikátor uživatele a skupiny atd.). Nemají tady totiž žádný význam.

Někdo se ještě zcela oprávněně může zeptat, co vlastně dotaz na e-mailovou schránku vrací, když nevrací cestu ke schránce. Odpověď je opět jednoduchá – může vracet cokoli neprázdného (tedy klidně i cestu ke schránce), protože jde pouze o test, zda uživatel existuje. Proto lze beze změny používat datové zdroje z primárního serveru.

Uvedený postup není jediný možný. Lze postupovat i jinak, bez přenastavování transportů. Například lze příjemce testovat v rámci restrikcí, tedy pravidlem v smtpd_recipient_restrictions (check_recipient_access). Má to své výhody i nevýhody. Výhoda je možnost upravit si restrikce lépe podle potřeb, nevýhoda hlavně nutnost řešit ověřování samostatně (bez přímého využití metody z primárního serveru).

Optimalizujeme výkon

Pokud serverem proteče jen několik málo zpráv denně (myšleno do řádu tisíců nebo desítek tisíc), není většinou vůbec potřeba se zabývat výkonnostními optimalizacemi. Server bude přinejhorším trochu pomalejší, ale jinak bude bez problémů fungovat. Pokud je ale průtok větší nebo musí server zvládat mnoho současně připojených uživatelů (protokolem IMAP), už to začíná být poněkud zajímavější. V takovém případě je dobré vědět, jak lze dosáhnout svižného a stabilního chování i pod velkou zátěží, což bude téma příštího dílu.

       

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.