Centralisation et fiabilisation

De plus en plus d'organisations mettent en place une machine de courrier de site, seule habilitée à émettre et recevoir du courrier de l'extérieur. Cette machine redistribue ensuite les messages en interne. Cette politique est celle, par exemple du campus Jussieu (voir 3.5.2, page ).

Le passage par une machine unique suppose :

• de placer des MX dans le DNS, pour indiquer au reste de l'Internet que le courrier doit être reçu par cette machine (voir 1.6, page ) ;

• de mettre en place des filtres sur le routeur d'entrée du site (ou équivalent) pour empêcher les connexions SMTP depuis l'extérieur vers l'intérieur ou réciproquement ;

• d'indiquer aux stations en interne d'utiliser cette machine comme relais (avec la variable RelaisExterieur).

Ainsi, la sécurité du site est renforcée. Toutefois, l'inconvénient est la dépendance vis-à-vis d'une machine qui peut tomber en panne, devenir indisponible suite à une coupure de courant, ou toute autre cause.

Pour éliminer cette dépendance, il est possible avec la version 8 de sendmailde doubler cette machine. Ainsi :

• les MX doivent indiquer les deux machines, éventuellement avec une priorité équivalente ;

• de modifier les filtres pour autoriser la deuxième machine ;

• d'indiquer aux stations en interne les deux machines comme relais :

  RelaisExterieur='smtp.[relais1.site.fr]:[relais2.site.fr]'

Il est même possible que la machine de secours soit extérieure au site^3.2. Ceci peut se faire avec plus ou moins de finesse :

• dans le premier cas, le mailhost extérieur ne connaît rien de la politique de routage interne du site secouru. Il dispose alors d'une table de routage simple :

  site-distant.fr:

  smtp.[mailhost.site-distant.fr]

  Comme nous l'avons vu en 1.6 (page ), cela présente surtout l'intérêt d'alléger la reprise, mais pas de fonctionner lorsque le mailhost du site distant est indisponible.

• dans le deuxième cas, le mailhost extérieur connaît la politique de routage interne du site secouru. Par exemple, l'UVSQ connaît la politique de routage de Jussieu, simplement en énumérant les sous-domaines de Jussieu dans la table de routage^3.3 :

  labo1.jussieu.fr:	smtp.[mailhost.labo1.jussieu.fr]
  labo2.jussieu.fr:	smtp.[mailhost.labo2.jussieu.fr]
  ...

  Pour que cette méthode fonctionne correctement, il faut également qu'il y ait concordance sur la liste noire en cas de lutte anti-spam (voir 3.5.4, page ).

Lorsque le site distant est indisponible, les courriers s'entassent dans la file d'attente du site de secours. Si le site distant reçoit un gros volume de courrier, cela peut devenir génant pour le site de secours : sendmailpasse alors de plus en plus de temps à explorer sa file d'attente en pure perte - il suffit d'utiliser mailq pour s'en convaincre. Si le problème se prolonge, il peut s'avérer utile de migrer la file d'attente dans un autre répertoire :

# kill -15 `head -1 /etc/sendmail.pid`      # en version >= 8.8 uniquement
# cd /var/spool
# mv mqueue mqueue.old
# mkdir mqueue
# sendmail -bd -q30m

Lorsque le site redevient disponible, il faut vider la file d'attente :

# sendmail -oQ/var/spool/mqueue.old -q

Attention toutefois : des messages non destinés au site secouru peuvent figurer dans cette file d'attente sauvegardée. Une fois la vieille file d'attente explorée, il restera sans doute des messages. Dans ce cas, il faut les déplacer dans la file d'attente « normale » (un simple mv suffit) après s'être assuré de ne pas écraser de message dans cette file « normale ».