[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Serveur Mail de secours!



Le mardi 4 octobre 2011 à 13:20:53, Fabrice MATHIEU a écrit :
>[…]
> >    Ou alors on change (manuellement s’entend) le MX de son
> > domaine vers l’IP du copain quand on se rend compte que le
> > sien est tombé en panne…
> 
> Cela suppose une surveillance 24/24 du relais / serveur de
> messagerie depuis un réseau externe.

  Rappelons que, de ce que la discussion a donné pour l’instant, 
seule la panne matérielle de plus de quelques heures (voire 
jours) reste un potentiel problème.

  On reste sur un délai de réaction de l’ordre de la journée. Si 
on n’est pas là pendant la panne, c’est un utilisateur qui se 
rendra compte du problème parce qu’il ne pourra pas accéder au 
serveur. Dans le cadre d’un serveur à la maison, le nombre 
d’utilisateurs est plutôt limité et ils connaissent en général 
un moyen simple et rapide de prévenir l’administrateur.

  Pas besoin d’un truc trop compliqué. À la limite, puisque 
machine du copain il y a, que celle-ci et la sienne se vérifient 
de temps à autre et qu’un dispositif d’alerte ou de réaction 
plus ou moins automatique soit mis en place. Il y a une symétrie 
entre les deux serveurs, autant s’en servir. Et pas besoin de 
vérifier toutes les 5 min ; une ou deux fois par jour devrait 
suffire.

> Il me semble que généralement le MX pointe sur un nom de
> machine, le client résout ensuite l' entrée A ou AAA.

  Si, il me semble aussi. J’aurais dû dire « machine », pas 
« IP », _mea culpa._

> Mais, corrigez - moi si je me trompe, la mise à jour d' une
> entrée dns implique un temps de réplication et de mise à
> jour des caches clients. Je pense que c' est viable si la
> panne est sur une moyenne / longue durée, mais pas assez
> réactive sur une courte durée.

  On reste sur quelques jours (un ou deux pour les DNS). Ce qui 
reste acceptable si on ne peut pas remplacer le matériel fautif 
plus rapidement.

> Sachant qu' un bon client smtp essaye de renvoyer à certains
> intervalles et pendant un certain temps les messages avant
> d' abandonner et avertir l' émetteur;

  Euh, s/bon client smtp/serveur smtp (MTA/MSA)/, parce que les 
clients (MUA) discutent directement avec le serveur qui risque 
la panne (et seront donc directement au courant qu’ils ne 
peuvent se connecter) ou utiliseront un MTA/MSA intermédiaire 
(qui sera celui qui réessaiera).

>   excepté pour certains types de messages (réservation en
> ligne entre autre).

  Tu as un exemple ?

-- 
 Sylvain Sauvage


Reply to: