Administrace komentářů

Souhlasím, nicméně se přikláním k názoru "Matej_Vanatko". Důležité je, z jaké strany se na toto díváme. Buď nato koukáme jako na klasický záložní server, který emaily přijme a snaží se je doručit primárnímu serveru, až bude dostupný. Nebo na něco jako cluster, či plně syncované servery.

Pokud klient poižívá nějaké freemaily (seznam, gmail apod.), tak ty nic nedrží a okamžitě dají echo odesílateli, který hned ví, že se mail nedoručil. Pokud je to důležité, tak volá, pokud ne, zkusí to poslat později (druhý den, nebo za pár hodin).
Pokud klient používá firemní řešení, tak ty dají také hned echo uživateli o nedoručení, maximálně v nějakém případě se drží maily ve frontě a server dá echo uživateli, že se ho pokusí doručit později.

Pokud chci být firma, která žije emailama, tak je hloupost mít klasické záložní mxko, protože si tím ničím nepomohu. Naopak mi to ještě může uškodit, protože klient se nedozví, že mi email nedošel a visí na záložním mxku, které se pokouší o doručení. Nějaké bouncování je zbytečné, protože mxka jsou většinou na hodně černých blacklistech. A jsou tam proto, protože jim ani nic jiného nezbývá.
Ovšem to se bavíme o tom, že předpokládáme klasické záložní mxko.

Pokud jsem firma a chci mít 99,99 dostupnost, tak dva oddělené servery, dvě oddělené konektivity a servery mezi sebou syncovat. To už bych ale nenazýval jako řešení pomocí záložního mxka, ale spíš jistý druh clusteru, RAS apod.
Zdar Max