En consultant les logs d’un serveur mail, vous pouvez tomber sur une erreur Postfix de ce type :
postfix/sendmail[6460]: fatal: www-data(33): message file too bigLangage du code : HTTP (http)Dans un contexte WordPress, cette erreur apparaît souvent lorsqu’une extension tente d’envoyer une sauvegarde de base de données, une archive ZIP, un export ou un rapport volumineux par email.
Le message est assez clair : l’utilisateur système www-data, donc PHP/WordPress sur Debian ou Ubuntu, essaye de soumettre un email trop gros pour la configuration Postfix actuelle.
La correction consiste à vérifier la limite configurée, l’ajuster si besoin, puis se demander si l’email est vraiment le bon transport pour ce type de fichier. Spoiler : pour des backups WordPress lourds, la réponse est souvent non.
Comprendre l’erreur “message file too big”
Postfix limite la taille maximale d’un message avec le paramètre message_size_limit. D’après la documentation officielle Postfix, sa valeur par défaut est 10240000 octets, soit environ 10 Mo. Cette limite concerne la taille complète du message, enveloppe comprise, et pas seulement la pièce jointe. Documentation officielle Postfix postconf(5).
C’est un détail important : une pièce jointe de 8 Mo peut produire un email plus gros que 8 Mo, car l’encodage MIME/Base64 ajoute du poids. En pratique, l’email final peut être environ un tiers plus gros que le fichier attaché.
Donc, si une sauvegarde SQL compressée pèse 9 Mo, elle peut tout à fait dépasser une limite Postfix de 10 Mo une fois transformée en pièce jointe email. Charmant, n’est-ce pas ?
Vérifier la limite actuelle de Postfix
Commencez par afficher la limite active :
postconf message_size_limitExemple de sortie :
message_size_limit = 10240000Pour afficher la valeur par défaut compilée dans Postfix :
postconf -d message_size_limitPour afficher uniquement les paramètres modifiés dans votre configuration :
postconf -n | grep '^message_size_limit'Langage du code : JavaScript (javascript)Si cette dernière commande ne retourne rien, Postfix utilise probablement sa valeur par défaut.
Vos sauvegardes sont-elles vraiment fiables ?
Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde — c'est une illusion de sécurité. Je mets en place des backups automatisés, hors-site, vérifiés, avec procédure de restauration documentée.
Mettons en place une vraie stratégie de backup →
Augmenter la limite de taille des messages
Pour augmenter la limite à 50 Mo, utilisez postconf -e. C’est plus propre que d’éditer main.cf à la main, car Postfix écrit lui-même la directive au bon format.
sudo postconf -e 'message_size_limit = 52428800'Langage du code : JavaScript (javascript)52428800 correspond à 50 MiB, soit 50 × 1024 × 1024 octets. Vous pouvez aussi utiliser 51200000 pour 50 millions d’octets. Les deux valeurs sont proches, mais la notation en MiB est plus rigoureuse.
Rechargez ensuite Postfix :
sudo systemctl reload postfixou, si votre distribution ne supporte pas le reload via systemd :
sudo postfix reloadVérifiez que la nouvelle limite est bien prise en compte :
postconf message_size_limitVous devriez obtenir :
message_size_limit = 52428800Quelle valeur choisir ?
Une limite de 25 Mo ou 50 Mo suffit dans la plupart des cas. Monter beaucoup plus haut n’est pas forcément une bonne idée : les gros emails consomment plus de mémoire, plus de disque dans la file d’attente, plus de bande passante, et passent souvent mal chez les destinataires.
| Limite souhaitée | Valeur Postfix | Commande |
|---|---|---|
| 25 MiB | 26214400 | sudo postconf -e 'message_size_limit = 26214400' |
| 50 MiB | 52428800 | sudo postconf -e 'message_size_limit = 52428800' |
| 100 MiB | 104857600 | sudo postconf -e 'message_size_limit = 104857600' |
Gardez aussi en tête que la limite de votre serveur ne suffit pas. Le serveur destinataire peut refuser un message plus gros que sa propre limite. Gmail, Microsoft 365, les relais SMTP transactionnels et les hébergeurs mail ont chacun leurs contraintes.
Autrement dit, augmenter Postfix permet d’accepter ou de soumettre un message plus lourd localement. Cela ne garantit pas que le reste d’Internet va l’aimer.
Vérifier les limites de boîtes mail
Selon votre configuration, d’autres limites peuvent intervenir. Si vous utilisez les boîtes virtuelles Postfix avec le transport virtual, vérifiez notamment virtual_mailbox_limit.
postconf virtual_mailbox_limitLa documentation Postfix indique que virtual_mailbox_limit définit la taille maximale d’une boîte virtuelle individuelle, ou 0 pour désactiver cette limite. Sa valeur par défaut est 51200000 octets. Documentation officielle Postfix virtual(8).
Si vous voulez désactiver cette limite côté Postfix virtual :
sudo postconf -e 'virtual_mailbox_limit = 0'
sudo systemctl reload postfixLangage du code : JavaScript (javascript)Attention toutefois : si vous utilisez Dovecot, quotas Maildir, une base SQL de quotas, un panel d’hébergement, ISPConfig, Virtualmin ou PostfixAdmin, la limite réelle peut être gérée ailleurs. Ne supposez pas que virtual_mailbox_limit = 0 désactive tous les quotas de messagerie.
Vérifier les logs Postfix
Après modification, surveillez les logs :
sudo journalctl -u postfix -fSur Debian ou Ubuntu avec syslog classique :
sudo tail -f /var/log/mail.log /var/log/mail.errLangage du code : JavaScript (javascript)Si l’erreur continue, vérifiez que vous avez bien rechargé Postfix, que la valeur active est correcte, et que l’email ne dépasse pas toujours la nouvelle limite.
Pour afficher les paramètres utiles d’un coup :
postconf -n | grep -E '^(message_size_limit|mailbox_size_limit|virtual_mailbox_limit|mailbox_transport|virtual_transport)'Langage du code : JavaScript (javascript)
Cas WordPress : éviter les sauvegardes lourdes par email
Dans le cas d’un site WordPress, l’erreur vient souvent d’une extension qui envoie une sauvegarde SQL ou ZIP par email. Techniquement, vous pouvez augmenter message_size_limit. Mais ce n’est pas forcément la meilleure solution.
Envoyer des sauvegardes WordPress par email pose plusieurs problèmes :
- les pièces jointes grossissent à cause de l’encodage MIME ;
- les gros emails sont souvent bloqués par les serveurs destinataires ;
- les sauvegardes peuvent contenir des données sensibles ;
- la boîte mail devient un mauvais système d’archivage ;
- les échecs de livraison peuvent passer inaperçus ;
- la file Postfix peut grossir si plusieurs envois échouent.
La meilleure pratique consiste à envoyer les sauvegardes vers un stockage adapté : SFTP, S3, Backblaze B2, Google Drive, Dropbox, Synology, serveur distant via rsync, ou système de backup géré par l’hébergeur.
Pour WordPress, l’email peut rester utile pour une notification de succès ou d’échec. En revanche, la pièce jointe de plusieurs dizaines de Mo, elle, mérite une retraite anticipée.
Alternative : sauvegarder WordPress sans email
Si vous avez accès au serveur, vous pouvez exporter la base avec WP-CLI :
cd /home/www/example.com/public_html
mkdir -p ~/backups
wp db export ~/backups/wordpress-db-$(date +%Y-%m-%d-%H%M%S).sqlCompressez ensuite le fichier :
gzip ~/backups/wordpress-db-*.sqlLangage du code : JavaScript (javascript)Puis envoyez-le vers un serveur distant avec rsync :
rsync -avz ~/backups/ user@backup.example.com:/srv/backups/example.com/Langage du code : JavaScript (javascript)Vous obtenez ainsi un vrai backup transféré vers un stockage externe, sans faire passer une archive SQL par un serveur mail. C’est plus fiable, plus propre, et beaucoup moins susceptible de finir dans les limbes SMTP.
Nettoyer la file d’attente si des messages sont bloqués
Si plusieurs messages trop gros ont été générés, inspectez la file Postfix :
mailqou :
postqueue -pSi vous voulez supprimer un message précis, utilisez son identifiant de queue :
sudo postsuper -d QUEUE_IDPour supprimer tous les messages différés, ce qui est plus radical :
sudo postsuper -d ALL deferredNe videz pas toute la queue Postfix à l’aveugle sur un serveur de production. Vérifiez d’abord ce qui est bloqué et pourquoi.
Tester l’envoi après modification
Après avoir augmenté la limite, testez un email raisonnable depuis le serveur. Si vous utilisez la commande mail :
echo "Test Postfix" | mail -s "Test message size limit" you@example.comLangage du code : PHP (php)Pour tester un fichier attaché, utilisez plutôt un outil adapté comme mutt ou mailx, selon votre distribution. Mais gardez un principe simple : ne testez pas directement avec un fichier énorme en production. Montez progressivement.
Checklist rapide de correction
Voici la séquence que j’utilise pour corriger cette erreur :
# 1. Vérifier l’erreur.
sudo tail -n 100 /var/log/mail.err
sudo journalctl -u postfix -n 100 --no-pager
# 2. Vérifier la limite actuelle.
postconf message_size_limit
# 3. Passer la limite à 50 MiB.
sudo postconf -e 'message_size_limit = 52428800'
# 4. Vérifier les limites de boîtes virtuelles si concerné.
postconf virtual_mailbox_limit
# 5. Recharger Postfix.
sudo systemctl reload postfix
# 6. Confirmer la nouvelle valeur.
postconf message_size_limit
# 7. Surveiller les logs.
sudo journalctl -u postfix -fLangage du code : PHP (php)Et si l’erreur vient d’une sauvegarde WordPress, je corrige aussi la stratégie de backup. L’email doit notifier, pas transporter la moitié du serveur.
Conclusion
L’erreur fatal: www-data(33): message file too big signifie que PHP, WordPress ou un autre script exécuté par www-data tente d’envoyer un email plus gros que la limite autorisée par Postfix.
La correction technique est simple :
sudo postconf -e 'message_size_limit = 52428800'
sudo systemctl reload postfixLangage du code : JavaScript (javascript)Mais la meilleure correction dépend du contexte. Pour une pièce jointe ponctuelle, augmenter la limite peut suffire. Pour des sauvegardes WordPress, mieux vaut arrêter d’envoyer les fichiers par email et utiliser un vrai stockage externe.
Postfix peut porter des messages plus lourds, oui. Mais ce n’est pas un camion de déménagement pour archives SQL compressées. À chacun son métier.
Sources
- Documentation officielle Postfix : postconf(5)
- Documentation officielle Postfix : virtual(8) et virtual_mailbox_limit
- Documentation officielle Postfix : postsuper(1)
- Documentation WP-CLI : wp db export
- Manuel rsync
Vos sauvegardes sont-elles vraiment fiables ?
Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde — c'est une illusion de sécurité. Je mets en place des backups automatisés, hors-site, vérifiés, avec procédure de restauration documentée.
Mettons en place une vraie stratégie de backup →
Merci!