WordPress et SMTP 552 5.3.4. Mesurer un message trop volumineux

Reconnaître le refus à la fin de la transmission

Un site WordPress envoie correctement certains courriels. Pour d’autres, son journal affiche DATA END command failed, suivi de 552 5.3.4 et d’un message qui indique une taille excessive. Le forum WordPress décrit ce cas sur des notifications envoyées par un relais SMTP. La trace situe le refus après la transmission du message au relais interrogé. Dans ce cas précis, le serveur n’a pas accepté le message à cette étape. Les échanges du forum évoquent plusieurs causes possibles et ne donnent pas de mesure du plafond qui s’appliquait à ce site.

Relevez le code complet et le texte de réponse. Le code SMTP 552 seul peut accompagner d’autres refus. Le code enrichi 5.3.4 décrit un message trop gros pour le système. Un 5.2.2 oriente vers une boîte pleine et un 5.7.x vers une politique de sécurité ou de remise. Le moment compte aussi. Une réponse d’erreur pendant l’envoi à WordPress, avant tout dialogue SMTP, mène à un autre contrôle. Si le relais a accepté le message avec 250 à la fin de DATA puis qu’un avis de non-remise est arrivé, le premier relais a pris le message en charge. Il faut alors identifier le serveur suivant qui a émis le refus.

Un test SMTP contenant seulement quelques mots vérifie que le compte et le relais savent expédier un petit message. Le même chemin peut refuser une notification qui contient un PDF, plusieurs images ou du contenu ajouté automatiquement. Comparez le même type d’événement, avec le même expéditeur, le même destinataire de recette et le même transport. Un courriel de test depuis les réglages d’une extension et un reçu généré par une autre extension peuvent emprunter des chemins différents. Dans le journal, associez le test à une heure et à un identifiant, plutôt qu’au seul nom de l’expéditeur.

1. Notez le type de notification, le fuseau du journal, la phase SMTP et le code complet. Ne recopiez ni identifiants de connexion ni contenu du message dans un ticket partagé.
2. Vérifiez si le défaut vise toutes les notifications, un modèle précis ou seulement certaines pièces jointes. Notez la taille des fichiers côté application et la présence éventuelle de logos intégrés.
3. Conservez un événement qui réussit et un événement qui échoue, tous deux fictifs si vous devez les recréer. Relevez quel serveur a répondu et si un identifiant de file a été renvoyé.

Comparer des messages avec les mêmes réglages

Avec l’accès au tableau de bord, commencez par identifier le composant qui produit réellement la notification. Dans son écran de réglage du courrier, repérez le modèle, le destinataire et la section qui joint ou génère des fichiers. Si la pièce est fabriquée après l’action utilisateur, par exemple un rapport assemblé ou un PDF de confirmation, mesurez la sortie générée. La taille du fichier déposé dans le formulaire ne représente pas forcément celle de la pièce transmise. Un deuxième composant peut aussi incorporer une image ou ajouter une autre pièce à la même notification.

Préparez une copie isolée où les courriels sont capturés par un relais de test ou une boîte contrôlée. Neutralisez les automatismes de la copie qui pourraient envoyer des notifications aux contacts importés. Reproduisez trois variantes avec la même action et un seul destinataire de test. Commencez par du texte seul, ajoutez un petit fichier fictif, puis un fichier fictif plus volumineux ou une seconde pièce. Donnez à chaque variante un marqueur propre dans l’objet ou dans une référence de suivi. Pour un diagnostic de taille, changez un élément à la fois. Si vous modifiez le destinataire, le modèle et la pièce en même temps, une différence ne permet plus de savoir quelle variable a compté.

Un relais de capture peut accepter toutes les tailles. Dans ce cas, le test confirme que WordPress compose les trois variantes et permet de les comparer. Il ne reproduit un plafond que si une limite est configurée sur le relais de recette ou si l’environnement de test possède une politique équivalente au chemin concerné. Gardez une marge sous le plafond documenté, car un relais en aval peut ajouter ses propres en-têtes et un fournisseur peut appliquer une règle plus stricte pour certains chemins.

1. Déclenchez la version sans pièce et relevez son état dans le journal du transport. Vérifiez qu’elle apparaît dans la boîte de recette ou dans la capture.
2. Rejouez avec la petite pièce, puis avec la version plus grosse. Relevez pour chacune la taille du fichier, la taille du message complet si elle est disponible, le code SMTP et la présence dans la boîte.
3. Si le petit message échoue aussi avec un autre code, résolvez cet obstacle avant de mesurer une limite. Si seul le message volumineux rencontre 5.3.4, cherchez le plafond du serveur qui l’a rejeté.

Lire le plafond au bon endroit

Avec l’accès au fournisseur de courrier, cherchez l’événement dans le journal de remise du relais. Filtrez par heure, expéditeur technique et destinataire de recette, puis ouvrez la réponse détaillée. Un fournisseur peut donner la taille en octets et l’état de chaque saut. D’autres ne donnent que la réponse SMTP. Si la trace provient d’un module qui remplace l’envoi SMTP par une API, recherchez le statut de la requête et celui de la remise dans ce fournisseur. Le message du forum concerne SMTP, tandis que les API peuvent avoir d’autres codes et d’autres plafonds.

Un serveur SMTP peut annoncer une extension SIZE lors de la réponse à EHLO. Lorsqu’une valeur positive est indiquée, c’est le plafond annoncé par ce serveur en octets pour son extension de taille. L’absence de valeur exploitable ne permet pas de conclure que tous les messages seront acceptés. Un relais en aval peut refuser une taille que le premier accepte. La bonne donnée est la règle du serveur qui a effectivement rejeté le message, complétée par la limite annoncée pour le compte ou la route utilisée.

Les plafonds de PHP ou de la médiathèque s’appliquent à l’entrée du fichier dans WordPress. Ici, le dialogue SMTP a déjà reçu le contenu. Augmenter la limite de téléversement peut laisser entrer davantage de fichiers et aggraver le refus du courriel. De même, libérer de l’espace dans la boîte du destinataire est une action adaptée à un diagnostic de quota de boîte, avec le code et la trace correspondants. Pour une taille de message, vérifiez la politique en octets de l’expéditeur et celle du destinataire si la remise échoue après l’acceptation initiale.

1. Comparez la trace du petit message à celle du gros. Notez qui répond 250 et qui répond 552 5.3.4. Si les deux codes viennent de serveurs différents, consignez les deux étapes.
2. Demandez la limite du message complet pour le transport utilisé. Si le fournisseur parle de « Mo », vérifiez l’équivalent exact en octets et si le plafond vise la pièce seule ou le MIME assemblé.
3. Si seul le support a accès au journal du relais, transmettez le marqueur fictif, l’heure, la taille mesurée et le code. Demandez la phase du refus et le plafond de la route, sans joindre la notification réelle.

Mesurer le message complet depuis un terminal

Les pièces encodées en base64 grossissent avant transmission. Chaque groupe de trois octets donne quatre caractères, avec un remplissage éventuel à la fin. Une pièce de 6 000 000 d’octets occupe donc déjà 8 000 000 de caractères encodés. Les sauts de ligne, les en-têtes de la pièce, les séparateurs MIME et le corps du message s’ajoutent à cette taille. Une image intégrée dans le message s’ajoute aussi. Une limite de fichier calculée à partir du seul poids du PDF laisse peu de marge si la notification contient plusieurs éléments.

Si vous avez accès au terminal et aux fichiers de la recette, enregistrez ce script dans un dossier privé sous le nom mesurer-message.php. Il charge uniquement les classes PHPMailer du WordPress indiqué et prépare un message fictif en mémoire. Lancez php mesurer-message.php "/chemin/wordpress" puis php mesurer-message.php "/chemin/wordpress" "/chemin/prive/temoin.bin" avec un fichier fictif lisible. Le premier appel donne la taille du message sans pièce. Le second affiche les octets de la pièce et du MIME complet. Le script a sa propre limite de 20 000 000 d’octets pour les témoins. Cette valeur ne représente aucun plafond d’hébergeur.

Le script appelle la préparation du MIME, sans ouvrir de session SMTP. Il donne un ordre de grandeur pour un message simple fabriqué par la bibliothèque présente sur disque. Le résultat ne comprend pas le modèle de votre extension, les signatures et en-têtes ajoutés par le transport, ni les réécritures en aval. Pour établir la taille exacte d’une notification, comparez-la au message capturé pendant un déclenchement fictif ou à la taille enregistrée par le relais. Avec plusieurs pièces, additionnez leurs tailles et leur surcoût, puis mesurez la notification complète. Un second PDF de quelques mégaoctets peut faire franchir le seuil alors que les deux pièces le respectent individuellement.

<?php
declare(strict_types=1);

use PHPMailer\PHPMailer\PHPMailer;

if (PHP_SAPI !== 'cli' || $argc < 2 || $argc > 3) {
    exit("Usage : php mesurer-message.php /chemin/wordpress [fichier-fictif]\n");
}

$root = realpath($argv[1]);
$lib = $root === false ? '' : $root . '/wp-includes/PHPMailer';
if ($lib === '' || !is_file($lib . '/PHPMailer.php') || !is_file($lib . '/Exception.php')) {
    fwrite(STDERR, "Bibliothèque PHPMailer introuvable.\n");
    exit(1);
}
require_once $lib . '/Exception.php';
require_once $lib . '/PHPMailer.php';

$piece = isset($argv[2]) ? realpath($argv[2]) : null;
$taille = 0;
if ($piece !== null) {
    if ($piece === false || !is_file($piece) || !is_readable($piece)) {
        fwrite(STDERR, "Fichier fictif introuvable ou illisible.\n");
        exit(1);
    }
    $taille = filesize($piece);
    if ($taille === false || $taille > 20_000_000) {
        fwrite(STDERR, "Utilisez un témoin fictif de 20 000 000 octets maximum.\n");
        exit(1);
    }
}

try {
    $mail = new PHPMailer(true);
    $mail->isSMTP();
    $mail->setFrom('origine@example.test');
    $mail->addAddress('capture@example.test');
    $mail->Subject = 'RECETTE-TAILLE';
    $mail->Body = 'Message de recette.';
    if ($piece !== null) {
        $mail->addAttachment($piece, 'temoin.bin', PHPMailer::ENCODING_BASE64, 'application/octet-stream');
    }
    $mail->preSend();
    printf("piece_octets=%d mime_octets=%d\n", $taille, strlen($mail->getSentMIMEMessage()));
} catch (Throwable $error) {
    fwrite(STDERR, "Impossible de préparer le message témoin.\n");
    exit(1);
}

Réduire la taille sur la route qui a échoué

Commencez par le contenu que vous contrôlez. Si le rapport joint utilise des images surdimensionnées, corrigez le modèle qui génère le document. Gardez un document lisible et vérifiez que ses pages, son texte et ses tableaux restent complets. Si la notification joint deux variantes du même fichier, retirez la copie superflue dans le modèle de recette. Si le fichier doit être transmis à l’identique, une page de téléchargement dont les accès sont adaptés au destinataire peut convenir. Vérifiez le lien depuis le profil qui devra l’utiliser, ainsi que l’expiration éventuelle. Un fichier privé placé dans un répertoire public pour réduire le courriel reste accessible selon les règles du répertoire.

Si le contenu doit rester identique et que vous gérez le relais, vérifiez si le plafond s’applique au compte, à un connecteur ou au serveur. Vous pouvez proposer une hausse ciblée seulement lorsque ce réglage est documenté et que le chemin suivant accepte aussi la nouvelle taille. Prenez une copie du réglage précédent. Si le fournisseur impose un plafond fixe, adaptez la notification ou passez par une route approuvée qui convient au volume. Vérifiez aussi l’expéditeur autorisé et le suivi des échecs sur cette route. Recréer le compte SMTP ou changer les enregistrements DNS ne résout pas un refus de taille confirmé pour un message qui arrive déjà au relais.

Un fichier redimensionné doit passer la même action que l’original. Un succès depuis l’outil d’envoi de test ne démontre pas que la notification de production a changé de modèle. Comparez à nouveau les messages en recette, puis vérifiez la réception du message complet. Si vous remplacez la pièce par un lien, testez le lien avec et sans les droits attendus selon la politique du document. Si la notification sort du bon plafond mais perd une information indispensable, rétablissez le modèle de recette et essayez une autre réduction.

1. Changez le seul réglage qui contrôle la pièce ou le plafond confirmé. Notez sa valeur précédente, la nouvelle taille MIME et l’emplacement de la modification.
2. Rejouez le petit témoin puis le cas corrigé. Vérifiez l’acceptation à la fin de DATA, le statut de remise et le contenu effectivement reçu.
3. Si le cas échoue encore, comparez le serveur et le code à la trace initiale. Un refus nouveau sur le saut suivant appelle un diagnostic distinct. Rétablissez le réglage de recette qui ne donne pas le résultat prévu.

Reprendre un événement précis et vérifier la réception

Pour une notification qui a échoué avec un refus permanent, vérifiez d’abord que l’extension ou le relais n’a pas conservé d’autre tentative de ce même événement. Selon l’application, la file peut avoir mémorisé le MIME ancien ou peut le reconstruire à partir du modèle courant. Relancer une copie déjà assemblée peut envoyer encore l’ancienne pièce. Si la fonction permet de régénérer le message pour un seul événement, choisissez cette opération et contrôlez l’objet, les pièces et l’adresse avant de poursuivre. Si vous n’avez pas cet accès, transmettez la référence de l’événement et le résultat du test à la personne qui le gère.

Gardez trois preuves séparées. La notification a été produite par WordPress ou son extension. Le relais a accepté sa transmission. La boîte de test a reçu un contenu utilisable. La documentation de wp_mail() précise qu’un retour positif ne garantit pas la réception. Lors d’un refus sur un serveur en aval, attendez le résultat final du relais et vérifiez l’avis éventuel avant de décider de renvoyer. Si le courriel contient un lien temporaire, régénérez le lien avec le mécanisme prévu plutôt que de récupérer une ancienne copie.

Terminez par un second événement fictif avec la configuration corrigée. Si le premier a réussi seulement après un envoi manuel, vérifiez que le déclencheur normal utilise bien la même règle et le même transport. Retirez le script de mesure et les documents fictifs du dossier de recette lorsque les résultats sont consignés. Pour un cas réel, gardez le volume mesuré, le code et l’identifiant technique dans le journal autorisé. Ces éléments suffisent pour comparer une éventuelle rechute sans archiver le contenu du courriel.