La fonction php mail() a servi à spammer depuis l'hébergement

mail() n'est pas le SMTP du plugin

PHP `mail()` parle à sendmail / postfix du serveur, souvent sans mot de passe, au nom du user Unix du compte. WP Mail SMTP, lui, ouvre une session authentifiée ailleurs. On peut révoquer le SMTP et laisser `radio.php` spammer. On peut couper `mail()` et laisser un SMTP volé envoyer depuis Gmail. Les journaux distinguent : local vs authenticated remote. WP Mail SMTP, compte SMTP CMS. Un bounce qui mentionne `Authenticated sender` oriente vers le SMTP ; un `cwd=/home/.../public_html` oriente vers `mail()`. Les deux phrases dans le même ticket hébergeur évitent qu'on vous rouvre le mauvais tuyau.

Ce que le journal d'envoi nomme

Chemin du cwd / du script (`/home/xxx/public_html/wp-tmp.php`), volume, destinataires, From. C'est la pièce. Sans elle, on « scanne » au hasard. Journal à demander. Exportez avant que la rotation des logs n'efface le pic.

Où se cache le script

Racine (`radio.php`, `wp-core.php`), `uploads` double extension, mu-plugin, thème enfant, un `cache` exécutable, un cron qui appelle un PHP. Grep `mail(` et `mb_send_mail` dans `wp-content` et à la racine — après copie. N'exécutez pas le fichier « pour voir ». Dates de modification vs pic d'envoi. wp-cron, backdoor.

• Chemin issu du journal → fichier archivé puis isolé.
• Grep `mail(` hors cœur officiel.
• Crontab du compte.

Couper mail() sans tuer le CMS pour toujours

Urgence : blocage hébergeur. Les formulaires contact cesseront (mieux que le spam). Recollez-les ensuite sur un SMTP authentifié (plugin officiel, secret neuf). Ne demandez pas « rouvrez mail() » le jour même. Rate limit, suspension.

disable_functions, cron, et le voisin

`mail` dans `disable_functions` (php.ini / panel) aide CE pool PHP. Un cron `php -d disable_functions=` ou un binaire CLI peut contourner. Un voisin de compte qui envoie depuis la même IP : voisin, IP blacklist.

Formulaires légitimes qui passent encore par mail()

Contact Form 7, des thèmes, PrestaShop `mail()` native : inventoriez. Après incident, tout le monde passe SMTP authentifié + journal. Un formulaire oublié qui retombe sur `mail()` dès que vous rouvrez la fonction, c'est la récidive — ou le prochain abus si le formulaire est injecté. Relisez les destinataires et les headers.

Après : interdire et surveiller

Gardez `mail()` fermé si tout passe SMTP. Surveillez le journal 14 jours. Interdisez PHP dans `uploads`. Spamhaus avec le constat script + date d'arrêt.

Quand c'est l'IP, pas seulement le script

Le script retiré, l'IP déjà SBL : delist / ticket hébergeur. Créer un compte si les logs sont absents et le volume énorme — le constat sert aux listes.

• Tuyau identifié : mail() vs SMTP.
• Script nommé par les logs, isolé.
• mail() coupé le temps du ménage.
• Formulaires recollés en SMTP.

PrestaShop, Magento, Joomla : le même mail()

Le cœur WordPress n'a pas le monopole. PrestaShop envoie encore souvent via `Mail::Send` qui tombe sur `mail()` si aucun SMTP n'est configuré. Magento a son transport ; un module mal écrit rappelle `mail()`. Joomla aussi. L'enquête est la même : journal d'envoi du compte, chemin du script, coupure de la fonction, puis SMTP authentifié. Ne cherchez pas uniquement dans `wp-content`.

Sur un compte mutualisé qui héberge un WordPress et une boutique, le spam peut partir de l'un pendant que vous scannez l'autre. Inventaire des vhosts avant de déclarer `mail()` « propre ». Voir voisin de serveur et compte SMTP du CMS. Le From affiché (la boutique) n'est pas forcément le PHP coupable.

Les hébergeurs ferment parfois `mail()` pour tout le compte après un abus. C'est une bonne nouvelle le temps du ménage. Recollez chaque CMS sur un relais nommé, testez un message, puis seulement demandez une réouverture — ou laissez fermé si plus personne n'en a besoin. Un compte à trois sites avec `mail()` rouvert « pour le petit formulaire du site vitrine » est la récidive la plus bête.