Demander le journal d'envoi à l'hébergeur : la pièce qui tranche
Le journal d’envoi de l’hébergeur tranche : qui a envoyé, quel script, quel volume, quelles heures. Il distingue un formulaire détourné d’un PHP à la racine. On le joint au constat et aux listes noires — avant qu’il tourne (rétention courte).
Qui a envoyé, quel script, quel volume, quelles heures. Distingue un formulaire détourné d'un PHP à la racine. Joignez-le au constat et aux listes noires.
Pourquoi c’est la pièce qui tranche
Sans journal, tout le monde a une théorie : « c’est CF7 », « c’est le voisin », « c’est du spoof ». Le log d’exim, postfix, le « mail queue » du panel, les logs SMTP du mutualisé : ils montrent l’auth user, le cwd / le script PHP, le nombre de destinataires, les codes de refus. C’est ce qui sépare trois dossiers qui se ressemblent au téléphone.
Nous le demandons avant de rouvrir le quota, avant de jurer à Orange que « c’est fini », avant de réinstaller (la réinstall détruit souvent les logs locaux). Les premiers gestes : copier aussi ça, pas seulement wp-content.
Un propriétaire qui a déjà « tout nettoyé » sans log : on peut encore travailler, plus lentement, plus cher, avec plus de doutes RGPD.
Le demander tout de suite (rétention)
Chez beaucoup de mutualisés français, les logs mail tournent en 7, 14, parfois 3 jours. Le week-end + le lundi « on verra » : trop tard. Ticket J0 : « merci de nous fournir les logs d’envoi du compte X du [date] au [date], identifiant de script / auth si disponible ». Numéro de ticket dans le constat.
Si le FTP est coupé, ils peuvent quand même extraire. Ne dites pas seulement « rouvrez ». Dites « logs + archive ». Voir suspension.
Cloud / Docker / un VPS à vous : les logs sont à vous (`journalctl`, fichiers mail). Copiez hors machine. Un down -v les oublie.
- Dates de début de symptômes (premiers bounces, premier client).
- Marge : 48 h avant.
- Adresse perso dans le ticket si la messagerie du domaine est morte.
Quoi demander, précisément
Pas « les logs ». Les envois : timestamp, from envelope, auth user, IP source si relais, id de message, destinataire (ou au moins le compteur), statut (sent/reject), et si l’hébergeur l’a : le chemin du script (cwd, extra PHP). Les reçus (inbound) sont un autre export, utile pour les réponses / bounces.
Formats : texte, parfois un CSV. Demandez 2–3 jours d’abord si le volume est énorme, puis élargissez. Un fichier de 4 Go le soir J0 n’aide personne ; un extrait du pic, si.
Les panels (cPanel « Track Delivery », Plesk, o2switch historique) : capturez aussi l’UI, ça date.
Lire : script, user, destinataires, heures
Un pic entre 2 h et 5 h, cwd `/home/xxx/www/wp-content/uploads/…/x.php` : PHP déposé. Un pic aux heures de bureau, script `contact-form` : form ou To: détourné. Un auth user `mail-smtp` à 4000 dest : mot de passe SMTP. Trois lectures, trois gestes.
Les refus 550 / 5.7.1 : déjà listé pendant l’envoi. Utile pour les dates de listing. Les acceptés : le mal est parti.
Ne publiez pas le log. Données de destinataires. Chiffrez l’archive du constat.
Formulaire vs PHP vs compte SMTP
Form : souvent peu de dest par message, beaucoup de messages, contenu « devis ». PHP root : beaucoup de dest, sujets aléatoires. SMTP auth : user non-humain, parfois depuis une IP hors du serveur (vol de secret, pas seulement un fichier). Les trois se cumulent dans un dossier long.
Cette distinction évite de « réparer CF7 » pendant qu’un radio.php tourne, et l’inverse. Form RDV, WordPress, rate limit.
Un log vide + plaintes clients : spoof ou autre machine (spam tiers, RUA). Le vide est un résultat, pas un échec de la demande — à condition que la rétention n’ait pas tout effacé.
Joindre aux listes et à l’assureur
Spamhaus, Orange, l’assureur, parfois la CNIL : extraits (pas 200 000 lignes). Pic, cut-off, script retiré. Page domaine blacklisté. Les RUA complètent pour le spoof.
Cohérence des dates avec le constat fichiers (mtime du PHP). Si le PHP est daté après le pic mail, il y a un autre fichier ou un autre compte.
Ne mentez pas « volume zéro depuis » si le log montre encore 200/j. Trouvez-les.
Ce que le journal ne contient pas
Les envois via un ESP (API) hors de leur MTA. Les spoof qui n’ont pas touché le serveur. Le contenu complet de tous les corps (parfois un bout, souvent non). La preuve RGPD « personne n’a lu la base » — autre constat.
Les logs web (access.log) sont le cousin : un POST vers le script à l’heure du pic mail. Demandez-les aussi. Reverse proxy : IP du proxy, pas du bot, si mal réglé.
Un hébergeur qui « n’a pas de logs mail » : changez de question (Track Delivery, ticket N2) ou changez d’hébergeur plus tard. À chaud, RUA + bounces + en-têtes clients.
Après : garder une rotation, pas un mythe
Demandez la durée de rétention, notez-la. Un export mensuel n’est pas nécessaire ; un réflexe J0, si. SMTP authentifié : logs ESP (90 j souvent), plus confortables.
Trente jours : plus de pic. Un nouveau pic : ticket logs le jour même, pas « on a déjà donné ».
Créer un espace : on s’appuie sur ce journal dès que vous l’avez. Inscription sans accès. Guide emails pour la suite des files.