Pour se faire un serveur de mail secondaire simpliste (en cas de panne du primaire, il ne fait que mettre en file d'attente les mails et la consultation se fera uniquement directement dans cette file d'attente avec postcat, guère pratique ...) avec Postfix, on met les domaines voulus dans « relay_domains » et on augmente la valeur de « maximal_queue_lifetime » (5 jours par défaut), histoire de garder les mails plus longtemps en cas d'une panne prolongée du primaire.

Ce type de secondaire permet de se prémunir d'une panne du primaire tout en étant sûr que les mails seront bien mis en file d'attente. En effet, certains administrateurs de serveurs mails peu consciencieux (le mail n'a pas été conçu pour être instantané) réduisent le « maximal_queue_lifetime » à 24h ou 48h, ce qui s'avère insuffisant pour réparer une bonne panne. Au moins, avec un tel secondaire, c'est vous qui fixez la durée de rétention.

On se demande ensuite comment le secondaire peut vérifier qu'une boîte aux lettres ou un alias existe bel et bien sur le primaire ? En effet, les spammeurs s'attaquent bien souvent au MX de plus basse priorité espérant qu'il sera moins bien protégé. En fonctionnement normal, le secondaire va donc se retrouver à mettre en queue des mails que le primaire va lui refuser sans cesse ... jusqu'à l'atteinte du « maximal_queue_lifetime ». Le secondaire tentera alors d'avertir l'expéditeur de la non-livraison ... quand il le peut ... donc le bounce peut se retrouver en file d'attente pendant « bounce_queue_lifetime ». Tout ce travail pour rien, c'est dommage.

Pour éviter cela, Postfix peut interroger le primaire et vérifier que la boîte ou l'alias existe juste après l'étape « RCPT TO » et donc avant le transfert du message par l'expéditeur et sa prise en charge. Cela se fait avec l'option « reject_unverified_recipient » de la directive de configuration « smtpd_recipient_restrictions ».

Cette vérification se fait simplement en simulant l'envoi d'un mail : EHLO - MAIL FROM - RCPT - QUIT. Si le primaire ne répond pas assez vite, le secondaire demandera à l'expéditeur de revenir plus tard (code 450, comme pour le greylisting) donc aucun risque de perte. Évidemment, le secondaire met en cache la réponse du primaire, qu'elle soit négative ou positive pendant le délai défini par « address_verify_cache_cleanup_interval » (0 pour persistant, 12h par défaut).

Lors d'une panne importante et durable sur le primaire, il faudra désactiver cette option (« reject_unverified_recipient »). Dans le cas contraire, le secondaire n'arrivera jamais à interroger le primaire et les mails seront donc sans cesse refusés temporairement à l'entrée ... et donc vous dépendez à nouveau de la bonne configuration du serveur de mail expéditeur en ce qui concerne le délai maximal de mise en file d'attente en cas de non livraison.

Astuce en plus : un tel secondaire n'a que deux buts :
  1) transmettre les mails pour certains domaines à un (ou plusieurs) serveur primaire.
  2) accepter et délivrer les mails pour lui-même, en tant que machine (mamachine.mondomaine.example).
On connaît donc toutes les destinations de sortie autorisées : soit les relay_domains, soit le serveur lui-même est la destination finale. Donc on élimine les indésirables avec l'option « reject_unauth_destination » de la directive « smtpd_recipient_restrictions ».

L'astuce consiste à positionner l'option  « reject_unauth_destination » avant l'option « reject_unverified_recipient ». Dans le cas contraire, le secondaire va contacter inutilement la destination indiquée dans le RCPT TO avant de rejeter le mail pour cause de relai interdit !

Comme l'indique cette page du manuel de Postfix, il est aussi possible de vérifier l'existence de l'adresse mail d'expédition mais le manuel ne le recommande pas, surtout sur des gros volumes de mails : des checks trop fréquents provoqués par des mails forgés pourraient vous valoir un ban de votre serveur de la part de ces serveurs indiqués comme expéditeurs.