Vérifier les logs du serveur mail

Le mail est une technologie ancienne comportant de nombreux défauts. La gestion de ces défauts est très peu automatisée et nécessite une grande vigilance de la part de l’administrateur. Voici quelques conseils et quelques pistes en cas de problème.

Regarder régulièrement les logs est votre première priorité.

Cela permet :

  • De vérifier si le système fonctionne correctement. Les utilisateurs ne vont pas vous avertir si le système ne marche pas comme il faut, surtout les personnes envoyant des mails à destination de nos adresses.
  • De vérifier si on est sur une blacklist ou greylist. Cette pratique est très courante, automatique, et basée sur des critères douteux (surtout chez Microsoft, Google, Apple, Amazon, Yahoo…). Si nous sommes blacklisted, il va falloir comprendre pourquoi puis négocier pour revenir en ligne. En général, c’est parce que les destinataires de courrier nous placent dans les indésirables, ou parce que nous envoyons trop de mails.
  • De vérifier si on est la cible de spam ou si nos serveurs sont utilisés à des fins malveillantes.
  • De vérifier si nos utilisateurs se servent correctement du système. Il faut notamment rappeler à l’ordre ceux qui utilisent leur adresse pour l’envoi massif de courriel (> 100 mails par jour ou > 100 adresses par mail environ).
  • De vérifier si on n’a pas de problème de stockage, réseau

Sur la machine qui fait tourner le serveur mail, les logs sont disponibles sur /var/log/mail.log et /var/log/opendmarc.log pour le MTA. Ces fichiers sont montés dans plusieurs conteneurs, c’est pourquoi on utilise pas les logs Docker.

Les logs du MTA sont gardés pour un mois (voir /etc/logrotate.conf sur la machine).

Pour le MDA, il suffit de regarder les logs Docker :

docker logs pica-mail-mda

La rotation des logs du MTA est assurée par le démon Docker (voir /etc/docker/daemon.json sur la machine).

La plupart du temps, les logs les plus intéressants sont ceux de Postfix, le MTA.

Note:

En effet, Postfix permet à la fois d’envoyer des mails (soumission SMTP) et de recevoir des mails à destination d’une adresse Picasoft. Dans ce dernier cas, il utilise le protocole LMTP pour déposer le mail dans la boîte de l’utilisateur final (via Dovecot, le MDA). L’analyse des logs de Postfix permet de traquer la plupart des erreurs en soumission comme en réception.

L’outil Perl pflogsumm permet de récupérer les logs de Postfix et de générer une synthèse (mails envoyés, nature des rejets, etc). Il peut directement lire depuis les logs Docker :

cat /var/log/mail.log | pflogsumm

Cette commande produit un rapport pour tous les logs. Si le serveur tourne depuis de nombreux jours, le rapport peut être très dense. Pour diagnostiquer un problème, il est utile de rajouter quelques arguments :

cat /var/log/mail.log | pflogsumm --problems_first --rej_add_from --verbose_msg_detail | less

Avec cette commande, les statistiques et problèmes reportés pour la dernière semaine sont affichés en haut du tableau de logs. Par exemple :

Grand Totals
------------
messages

   1727   received
   1727   delivered
      0   forwarded
      5   deferred  (115  deferrals)
      3   bounced
      3   rejected (0%)
      0   reject warnings
      0   held
      0   discarded (0%)

On voit que la semaine passée, plus de 1700 mails ont été envoyés.

  • 3 ont été bounced
  • 3 ont été rejetés
  • 120 ont été déférés, 5 le sont encore.

Les mails déférés sont des mails “en attente” d’envoi après un échec. Postfix tente régulièrement de renvoyer ces mails, jusqu’à vidage de la queue au bout d’un moment. Les raisons sont en général :

  • Un utilisateur distant invalide (il n’existe pas ou plus)
  • Un greylisting
  • Une erreur du prochain relai ou de la boîte de réception

Note:

Le greylisting (mot anglophone signifiant « inscription sur liste grise ») est une technique de lutte anti-spam très simple qui consiste à rejeter temporairement un message électronique, par émission d’un code de refus temporaire au serveur informatique émetteur (MTA). Dans la majorité des cas, les serveurs émetteurs réexpédient le courriel après quelques minutes. La plupart des serveurs émettant des spams ne prennent pas cette peine. Source : Wikipédia.

Note:

pflogsumm trie les messages déférés par protocole. Il affichera lmtp pour les erreurs lors du dépôt d’un mail à destination d’une adresse Picasoft dans sa boîte mail, et smtp pour les mails rejetés par un relai extérieur.

Exemple :

message deferral detail
-----------------------
  lmtp (total: 107)
       107   host pica-mail-mda[172.27.0.3] said: 451 4.3.0 <wekan@picasoft.net> Internal error occurred.

Dans cet exemple, 107 messages ne sont pas arrivés dans la boîte mail de wekan@picasoft.net à cause d’une erreur inconnue. La consultation des logs de Dovecot nous apprendra qu’il s’agissait d’un souci au niveau du LDAP.

Exemple :

  smtp (total: 8)
         4   host mxi-vip.utc.fr[195.83.155.11] said: 450 4.2.0 <picasoft@assos.utc.fr>: Recipient address rejected: Greylisted
         1   host mx00.gmx.net[212.227.15.10] refused to talk to me: 421-gmx.net
         1   host mx00.gmx.net[212.227.15.10] refused to talk to me: 421-gmx.net
         1   host mxa.relay.renater.fr[194.214.201.8] refused to talk to me: 421 4.3.2 All server ports are busy
         1   host mx00.gmx.net[212.227.15.10] said: 451 Requested action aborted: local error in processing

On voit plusieurs causes différentes :

  • Du greylisting du serveur des associations de l’UTC. A priori pas de soucis, les mails ont été renvoyés après quelques minutes.
  • Des erreurs (timeout, serveur surchargé) qui se traduisent par des erreurs 4XX. Tant que ces erreurs sont marginales, ce n’est pas nécessaire de se prendre la tête.

Pour vérifier que la queue est vide :

$ docker exec -it pica-mail-mta bash
# mailq
Mail queue is empty

Attention:

Si la queue n’est pas vide, voire particulièrement encombrée, il y a des risques de ralentissement. L’outil qshape permet d’analyser la queue des messages déférés de Postfix.

Les mails rejetés et les mails de retour (bounced) sont en général dûs à :

  • Une adresse mail distante qui n’existe pas ou une boîte mail saturée
  • Un rejet à cause de mesures anti-spam.

Dans ce dernier cas, on se référera à la page dédiée aux blacklists.

  • technique/adminsys/mail/maintenance/logs.txt
  • de tollive