Comment traquer les envois de mail PHP sur votre serveur ?

Comment savoir quel script envoi des mails à partir de mon serveur dédié ?

Depuis PHP 5.3, de nouvelles fonctionnalités ont été rendues disponibles et configurables directement à partir du fichier php.ini. Parmi ces dernières, une en particulier est fortement intéressante et permet de logger tous les appels à la fonction mail() de PHP et donc de savoir quel script fout potentiellement la merde sur votre serveur (très utile en cas de faille de sécurité pour ne pas voir son serveur fermer pour cause de spammactivite massive aigüe).

Dernière mise à jour le 16/02/2015.

Est-ce que j’ai besoin d’avoir des connaissances techniques ? Des accès spécifiques ? etc.

Bon, on va partir du principe que si vous gérez un dédié, à minima vous y avez accès en SSH si c’est du Linux (sinon il faut commencer à se poser des questions) et que vous avez déjà lancé des commandes dans un terminal (du style apt-get install par exemple, rien de foufou). Si vous gérez un serveur IIS sous Windows, je pars du principe que vous êtes suicidaire et que de toute façon vous vous êtes déjà tiré une balle dans le pied, alors un peu plus un peu moins…

Donc, sur la config, on a un OS Linux (sous Debian, Ubuntu, Centos, etc.) avec un serveur (on va dire Apache au hasard) permettant de gérer du PHP, nécessairement installé donc, en version 5 de préférence et à jour, donc minimum 5.3 puisque c’est ce qui nous intéresse (à l’heure de la rédaction du billet, on en est à la 5.4.4.14). On a bien entendu un accès SSH au serveur, et pour la mise en place on sait taper au clavier sans faire de faute, ou mieux encore, faire du copier/coller.

C’est parti, comment fait-on ?

Premièrement, on se connecte en SSH, FTP ou tout au moyen permettant d’écrire sur 2 fichiers de votre serveur (voir 3).

Il va falloir faire 2 choses importantes :

  1. Modifier le fichier php.ini afin qu’il sache ou stocker les informations
  2. Créer le fichier dans lequel seront stockées les informations, et accessoirement le rendre accessible en écriture, sinon ça ne fonctionnera pas

Modification du fichier php.ini

Une étape ma foi bien simple, mais qui peut vite rendre chèvre ! Tout d’abord, il faut savoir qu’il est possible qu’il existe plusieurs fichiers php.ini sur votre serveur, selon comment l’installation a été faite. Normalement le fichier à modifier se trouve dans /etc/php5/apache2/php.ini pour une installation classique, cela inclus tout de même quelques défaillances en terme de sécurité, surtout si vous hébergez les sites de vos clients sur le serveur…

Le fichier peut également se trouver dans /etc/php5/cgi/php.ini. Là on est déjà un peu mieux niveau sécurité. Bon dans le doute, vous modifiez les 2 et c’est réglé hein.

Vous avez, depuis la version 5.3, une ligne avec le paramètre mail.log qui n’attend que d’être renseigné, on va donc lui indiquer le chemin de notre fichier de log qu’on va appeler mail-php.log par exemple (vous mettez ce que vous voulez, faudra juste penser à appeler votre fichier de la même manière), ce qui donne :

mail.log = /var/log/mail-php.log

Assurez-vous qu’il n’y ait pas de « ; » (point-virgule signifiant que la ligne est commentée et donc non interprétée) devant la ligne et que la ligne au dessus « mail.add_x_header = On » soit également dé-commentée, on ne va pas cracher sur quelques infos en plus.

C’est fait ? Bon, on sauvegarde et on ferme, on pense à redémarrer Apache et next step !

Création du fichier de log des mails

Comme dit précédemment, le créer ne suffira pas, il faut aussi que le serveur puisse écrire dedans à chaque utilisation de la fonction mail() de PHP.

Tout d’abord, on créé le fichier. Si notre utilisateur (le USER avec lequel on est connecté) a les droits suffisants (j’espère que vous n’êtes pas loggé en Root !!), on procède ainsi :

touch /var/log/mail-php.log

Si vous obtenez un message d’erreur relatif à l’absence de droit de création dans le dossier /var/log, pas de souci, on fait juste ça à la place :

sudo touch /var/log/mail-php.log

Ah, pour rappel, si vous aviez choisi un nom de fichier différent en renseignant le php.ini, il faudra mettre le même nom de fichier du coup. Le système vous demande votre mot de passe ou vous affiche une erreur. Dans le premier cas, vous renseignez votre MDP, dans le second c’est que votre USER n’appartient pas au groupe SUDOERS, donc il faudra l’ajouter via l’utilisateur ROOT, et pour se connecter en root, rien de plus simple :

su –

Il vous faudra par contre le mot de passe du super-utilisateur root qui vous sera demandé à la validation de la précédente commande. Ensuite soit vous ajoutez votre USER dans /etc/sudoers soit vous tapez la commande suivante :

usermod -aG sudo <username>

Fin de l’aparté. Quand c’est fait, on donne les droits en écriture sur le fichier, bon moi je le fais en mode un peu barbare pour gagner du temps mais vous pouvez affiner au besoin (en même temps, il n’y a pas beaucoup de risque) :

chmod 777 /var/log/mail-php.log OU sudo chmod 777 /var/log/mail-php.log (selon vos droits)

Là vous avez donné les droits en lecture, écriture et exécution à tout le monde sur le fichier, mais encore une fois, il ne s’agit que d’un fichier de log. Je pars du principe que si un gars arrive à se connecter au serveur et à accéder à /var/log, votre serveur est de toute manière perdu 😉

Et donc, qu’est-ce qui se passe maintenant ?

La combo magique est faite, à présent, chaque fois qu’il y aura un appel à la fonction mail() de PHP, une ligne sera ajouté au fichier indiquant quel est le script qui a effectué cet appel, cela pourra vous éviter de vous torturer le cerveau pendant des heures pour savoir pourquoi votre serveur spam à gogo.

Pour lire le fichier, il existe de nombreuses commandes SSH, comme « cat », « less », « more », etc. Personnellement, je préfères utiliser un « tail -f » qui permet de ne remonter que les dernières lignes et se met à jour automatiquement, après c’est juste une question de choix.

En espérant que cet article vous aura été utile, n’hésitez pas à le partager et/ou à venir dire ce que vous en pensez ci-dessous.

A propos de Tony (33 Posts)

Développeur Web et consultant SEO, je vous invite à venir échanger et partager sur ce vaste sujet.
Je vous propose également mes services en référencement naturel, afin d’améliorer la visibilité de votre site Internet.


Leave a Reply