technique:adminsys:mail:maintenance:logs

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:adminsys:mail:maintenance:logs [2021/01/20 17:37] – ↷ Liens modifiés en raison d'un déplacement. qduchemitechnique:adminsys:mail:maintenance:logs [2022/01/17 18:02] (Version actuelle) – correction commande tollive
Ligne 1: Ligne 1:
 +{{indexmenu_n>1}}
  
 +# 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
 +
 +## Vérifier les logs à la main
 +
 +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).
 +
 +## Formater les logs de Postfix à la recherche d'un problème
 +
 +La plupart du temps, les logs les plus intéressants sont ceux de Postfix, le [[technique:old:etudes:mail:serveurs_de_mail:mta|MTA]].
 +
 +<bootnote>
 +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 [[technique:adminsys:mail:archi:communication-conteneurs-mta-mda|protocole LMTP]] pour déposer le mail dans la boîte de l'utilisateur final (via Dovecot, le [[technique:adminsys:mail:config:ldap:dovecot|MDA]]). L'analyse des logs de Postfix permet de traquer la plupart des erreurs en soumission comme en réception.</bootnote>
 +
 +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.
 +
 +## Mails déférés
 +
 +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
 +
 +<bootnote>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](https://fr.wikipedia.org/wiki/Greylisting).</bootnote>
 +
 +<bootnote>
 +`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.
 +</bootnote>
 +
 +### LMTP
 +
 +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.
 +
 +### SMTP
 +
 +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
 +```
 +
 +<bootnote warning>Si la queue n'est pas vide, voire particulièrement encombrée, il y a des risques de ralentissement. L'outil [qshape](https://postfix.traduc.org/index.php/QSHAPE_README.html) permet d'analyser la queue des messages déférés de Postfix.</bootnote>
 +
 +## Mails de retour et mails rejetés
 +
 +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 [[technique:adminsys:mail:maintenance:blacklist|page dédiée aux blacklists]].