Portál AbcLinuxu, 5. května 2025 17:03
Může se stát, že je poštovní server nějakou dobu nedostupný – například když je umístěn uvnitř sítě firmy a přestane fungovat internetové připojení. Pro takové případy se často používá záložní server, který nemá úložiště pošty se schránkami, ale může poštu dočasně přebírat k pozdějšímu doručení na hlavní poštovní server.
Je-li hlavní poštovní server umístěn uvnitř firemní sítě, není až tak úplně vyloučeno, že bude občas nedostupný z Internetu. Internetové připojení není nikdy stoprocentně spolehlivé, navíc mohou nastat situace, kdy bude třeba kvůli nějakým stavebním pracím odpojené. Totéž, i když s menší pravděpodobností, se může stát i u serveru umístěném v perfektně zajištěném datovém centru – už třeba proto, že je potřeba provést nějaké práce přímo na tomto serveru.
Za běžných okolností se až tolik neděje, protože odesílající servery ponechají zprávy, které se nepodařilo doručit (kvůli nedostupnosti cílového serveru), ve svých frontách. To ale platí jen v případě, že jsou tyto servery správně nakonfigurované a že během této doby neselžou. Navíc pokud nedostupnost cílového serveru trvá déle, pokusy o opětovné doručení se opakují ve stále delších intervalech, takže i po obnovení dostupnosti serveru může trvat i řadu dalších hodin, než jsou zprávy doručeny.
Z uvedených důvodů (tedy přesunutí nedoručených zpráv „do vlastní moci“ a zajištění rychlého doručení po obnovení dostupnosti) se používají záložní servery, které zprávy přijmou namísto serveru hlavního a ponechají je ve své frontě potřebnou dobu. Po obnovení dostupnosti hlavního serveru je ihned tomuto serveru předají. Záložní server může být jeden, nic však nebrání tomu, aby jich bylo i více.
Problém s dostupností hlavního poštovního serveru lze samozřejmě řešit také tak, že je těchto hlavních serverů více a udržují si synchronizované úložiště. Tím lze zajistit přístup k nově doručeným zprávám i v době, kdy primární server není k dispozici. To je ale záležitost oproti řešení pomocí záložního serveru řádově složitější.
Jeden záložní server může obecně sloužit pro větší počet hlavních serverů. Typicky se to využívá třeba tak, že ISP poskytuje jeden nebo více záložních serverů svým zákazníkům pro případ nefunkčnosti jejich připojení.
Poštovní servery pro doručování do určité domény jsou v DNS identifikovány pomocí MX záznamů. Každý takový záznam obsahuje – kromě adresy serveru – také prioritu. Čím menší číslo, tím je priorita vyšší (na absolutní hodnotě však nezáleží). Doručující server by měl vždy začít od serveru s nejvyšší prioritou a případně (při neúspěchu; tím je myšlena nedostupnost, případně dočasná chyba, nikoli chyba trvalá) postupně zkoušet i servery s prioritou nižší. Pokud má stejnou prioritu více serverů, měly by být zkoušeny všechny se stejnou pravděpodobností (tj. například metodou round-robin nebo náhodně).
Chování správně nakonfigurovaného poštovního serveru tedy vypadá tak, že provede DNS dotaz na MX záznamy a pak postupuje podle priorit jednotlivých záznamů. Primární (hlavní) server bude mít prioritu např. 10, záložní server 100 – proto se nejprve zkusí hlavní server a teprve při neúspěchu server záložní. Pokud neexistují MX záznamy, má odesílající server zkusit ještě A (resp. AAAA u IPv6) záznamy, ale to není běžná situace a nemá to v kontextu řešení záložního serveru žádný zvláštní význam.
Špatně implementované nebo nakonfigurované servery mohou volit pořadí serverů jiné, proto je pro správné fungování pošty žádoucí, aby, když už existuje MX záznam pro jeden či více záložních serverů, tyto servery správně fungovaly (nelze-li to zajistit, pak je lepší příslušné záznamy zrušit).
Existuje však ještě jedna situace, kdy jsou servery voleny ve špatném pořadí. Dělají to mnohé nástroje spammerů, a to dokonce záměrně. U záložních serverů se totiž očekává slabší ochrana než u serverů hlavních, proto spammeři mnohdy cílí právě na MX záznamy s nižší prioritou. Řešení je dvojí – buď záložní servery vůbec nepoužívat (což ale v případě, kdy jsou k používání dobré důvody, zrovna moc řešení není), anebo je zabezpečit tak, aby to spammeři neměli jednoduché.
Záložní server nemá poštovní schránky – jeho jediným úkolem je přijímat zprávy a zadržovat je do doručení na hlavní server (případně je vracet, pokud doručit nejdou). Nemá tedy ani úložiště pošty, nepotřebuje žádnou službu pro přístup ke schránkám ani k autentizaci uživatelů (ledaže by měl sloužit i k odesílání pošty, to však nebývá úkolem záložních serverů). Tím se situace zjednodušuje, dokonce – jak se vzápětí ukáže – může záložní server fungovat i zcela autonomně, bez potřeby přístupu do databáze domén.
Samotná změna konfigurace tak, aby server vystupoval jako záložní, je velmi jednoduchá (viz dále). Bohužel, to není jediná věc, kterou je potřeba vyřešit. Musí se totiž zajistit i již zmíněná ochrana proti spamu, a to nejlépe způsobem co nejpodobnějším tomu, který je použit na hlavním serveru. O tom ale až později – nejprve je potřeba záložní server zprovoznit. Tady je základní podoba konfiguračního souboru main.cf:
myhostname = postak-zalozni.moje.domena
myorigin = $mydomain
mynetworks = 127.0.0.0/8
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
permit_mx_backup,
reject
smtpd_helo_required = yes
disable_vrfy_command = yes
Tato konfigurace je velmi podobná té, která se vyskytovala na počátku seriálu, konkrétně u serveru pro odesílání zpráv. Parametr myhostname musí být shodný s názvem uváděným v MX záznamech směřujících na tento server (viz dále). myorigin je doména pro zprávy odesílané (tak jako dříve), mynetworks určuje „vlastní sítě“ (zde jen lokální stroj).
Restrikce na odesílatele jsou podobné těm používaným dříve, tedy povoluje se příjem z vlastních sítí, odmítá příjem chybně určených adres a neexistujících domén. U restrikcí na příjemce je ale zásadní změna. Povolen je totiž příjem z vlastních sítí a dále pak (po odmítnutí chybných adres příjemců) pro domény, pro které tento server slouží jako záložní (permit_mx_backup).
Jak permit_mx_backup funguje? Povolí příjem pro domény, u kterých existuje neprimární MX záznam obsahující tento server, a dále pak domény explicitně uvedené jako relay_domains (zde žádné nejsou, proto se to neuplatní). Možná to zní trochu složitě, ale ve skutečnosti to složité není. Stručně řečeno, pokud pro danou doménu existuje MX záznam směřující na tento server a současně pro tuto doménu existuje alespoň jeden MX záznam s větší prioritou, je zpráva přijata.
Lze si to ukázat na příkladu. Doména moje.domena bude mít záznam ukazující na server postak.moje.domena s prioritou 10 a záznam ukazující na server postak-zalozni.moje.domena (čili na tento server) s prioritou 20. Zprávy pro doménu moje.domena tedy server přijme. Doména jina.domena však bude mít jen jediný MX záznam, a sice ukazující na postak-zalozni.moje.domena s prioritou 5. Zprávy nebudou tímto serverem přijímány.
Uvedená konfigurace má jednu zásadní výhodu a současně i jedno úskalí. Výhoda tkví v tom, že se vůbec není potřeba starat o to, pro které domény server funguje jako záložní – všechny potřebné informace si server sám získá z DNS. Velmi výhodné je to v situacích, kdy záložní server provozuje někdo jiný než server primární. Není potřeba nijak řešit předávání informací při změně v nastavení MX záznamů.
Úskalí spočívá v tom, že si příslušné MX záznamy může každý nastavovat, jak chce. Proto, když někdo touží po záložním serveru, může si prostě nějaký nastavit – a pokud se tento server nebrání, bude jako záloha sloužit. A uvedená konfigurace je právě taková. Nijak se nebrání tomu, aby si server úplně kdokoliv nastavil jako záložní a využíval jeho systémové prostředky ke svému užitku.
Protože by se málokomu takový stav zamlouval, je potřeba nalézt vhodné řešení, které bude umožňovat ochranu serveru při zachování maximálního komfortu. Jedním z řešení je přidat do konfigurace tento řádek:
permit_mx_backup_networks = 85.207.0.0/16
Uvedený parametr omezuje využití serveru jako záložního na případy, kdy jsou primární servery (MX záznamy s nejvyšší prioritou) v definovaných sítích. Například tak ISP může zajistit, aby jeho záložní poštovní server směli využívat jen jeho zákazníci (mající jím přidělené IP adresy) pro primární servery umístěné za jím poskytovaným připojením.
Druhá možnost je testovat domény explicitně, což může být použito samostatně nebo v kombinaci s předchozí metodou. Pro samostatné použití se místo permit_mx_backup použije permit_auth_destination a domény jsou dostupné pomocí parametru relay_domains (viz dále). Parametr permit_mx_backup_networks se nepoužije. Pro kombinované použití se ponechá parametr permit_mx_backup, permit_mx_backup_networks se nastaví podle potřeby a další domény se uvedou pomocí relay_domains.
Domény, pro něž má server sloužit jako záložní, se definují pomocí relay_domains. Je to úplně stejné, jako když si hlavní server zjišťuje domény, do nichž doručuje. Lze tedy použít obyčejný seznam přímo přiřazený do parametru, ale také kteroukoli z široké škály metod podporovaných konkrétní instalací serveru (čili obecně různé databáze, LDAP, externí službu dostupnou přes TCP…). Takové řešení je vhodné pro případy, kdy se poskytuje záložní server pro primární server umístěný kdekoliv na Internetu.
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.
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.
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í.
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.
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.
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.
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).
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.
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.
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í.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.