Réponse courte
Pour Zimbra Webmail, la modification d'un seul paramètre peut s'avérer insuffisante. Si les utilisateurs doivent joindre des fichiers volumineux à leurs messages sortants, il est nécessaire de coordonner la limite de chargement web, la limite de contenu SOAP de la boîte aux lettres et la limite de taille totale des messages imposée par le MTA. Vérifiez également l'existence d'une restriction spécifique au serveur ou d'un proxy externe imposant une limite de requêtes inférieure.
À titre d'exemple, supposons que votre organisation souhaite que les utilisateurs puissent joindre des fichiers jusqu'à 25 Mio. Les recommandations de Zimbra préconisent de prévoir environ 150 % de la taille du fichier d'origine pour le message MIME complet. Un plafond de 40 Mio (41 943 040 octets) constitue un point de départ raisonnable pour cette politique, sous réserve de tests et de votre capacité de stockage. La surcharge MIME variant selon les messages, aucun multiplicateur ne garantit que tous les messages pourront être joints.
Exécutez ces commandes en tant zimbraqu'utilisateur, après avoir examiné les valeurs actuelles et confirmé que la stratégie d'exemple convient à votre environnement :
su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize zimbraMtaMaxMessageSize
zmprov mcf zimbraFileUploadMaxSize 41943040
zmprov mcf zimbraMailContentMaxSize 41943040
zmprov mcf zimbraMtaMaxMessageSize 41943040
postfix reload
Ces commandes définissent des valeurs globales. Si un serveur de messagerie possède sa propre configuration de priorité inférieure, vérifiez et ajustez-la également. Les attributs exacts et le comportement au redémarrage peuvent varier selon la version et le déploiement de Zimbra ; vérifiez-les par rapport à votre version installée avant d’appliquer des modifications à l’ensemble du système.
Pourquoi il existe plus d'une limite
zimbraFileUploadMaxSizeCe paramètre contrôle les chargements de fichiers gérés par Zimbra, notamment le corps de la requête accepté par le proxy web intégré. La documentation de Zimbra relative au proxy associe la taille maximale du corps des requêtes HTTP et HTTPS à cet attribut ; une requête dépassant la limite du proxy peut recevoir une erreur HTTP 413. Dans un déploiement multi-boîtes aux lettres, cet attribut peut être défini globalement ou par serveur.
zimbraMailContentMaxSizeCe paramètre contrôle la taille du contenu des messages envoyés via l'interface SOAP de la boîte aux lettres. zimbraMtaMaxMessageSizeIl détermine la taille maximale des messages complets acceptés par le MTA, qui est Postfix dans un déploiement Zimbra standard. Cette taille inclut les en-têtes et le contenu encodé MIME, et non pas seulement le fichier original sur le disque.
L'article du centre technique de Zimbra concernant la configuration de la taille des messages est clairement indiqué comme étant en cours d'élaboration. Ses explications et commandes sont utiles, mais il est recommandé de vérifier les définitions et le comportement des attributs pour votre version de Zimbra installée. Les références sont le guide de Zimbra sur la taille maximale des messages et la documentation de référence des variables du proxy Zimbra .
Utilisez les paramètres correspondant à l'erreur : un fichier rejeté immédiatement lors de son rattachement indique d'abord une limite de chargement ou de proxy web. Un message rejeté lors de l'envoi ou de la distribution peut provenir du MTA ou du serveur du destinataire. Un chargement réussi mais dont l'envoi échoue ensuite signifie que la limite du MTA ou l'expansion MIME nécessite encore une intervention.
Choisissez une limite adaptée à votre police d'assurance.
Définissez une limite métier précise plutôt que d'augmenter systématiquement les plafonds. Par exemple, si les utilisateurs peuvent joindre des fichiers jusqu'à 25 Mio, la limite de 40 Mio permet de tenir compte de l'encodage et de la surcharge liée aux messages. Zimbra précise que l'augmentation de la taille des fichiers encodés n'est pas un pourcentage fixe et suggère d'utiliser 150 % comme hypothèse de base pour estimer les limites des messages.
Les messages volumineux consomment davantage d'espace de stockage, de bande passante et de capacité de boîte aux lettres. Zimbra avertit qu'une limite de taille Postfix excessivement élevée peut entraîner des problèmes de distribution du courrier si la partition de la file d'attente ne dispose pas de suffisamment d'espace libre. Des attributs de taille Zimbra très élevés peuvent également provoquer des problèmes de service dans certaines versions ; Zimbra a documenté des défaillances de l'application Web et de la console d'administration suite à des valeurs hors plage. Il est recommandé d'augmenter les limites progressivement et de tester le résultat plutôt que de fixer un plafond de plusieurs gigaoctets sans plan de capacité.
Vérifier la présence d'une substitution par serveur
La configuration globale est pratique lorsque tous les serveurs de messagerie doivent partager une même stratégie. Cependant, une valeur au niveau du serveur peut remplacer le paramètre global. Vérifiez les valeurs globales, puis le serveur de messagerie qui gère l'utilisateur concerné :
su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize
zmprov gs mailbox1.example.com zimbraFileUploadMaxSize zimbraMailContentMaxSize
Remplacez mailbox1.example.compar le nom réel du serveur de messagerie. Si sa valeur spécifique au serveur est inférieure et que votre politique autorise une taille supérieure, mettez à jour cet hôte :
zmprov ms mailbox1.example.com zimbraFileUploadMaxSize 41943040
zmprov ms mailbox1.example.com zimbraMailContentMaxSize 41943040
Répétez l'opération uniquement pour les serveurs de boîtes aux lettres concernés. Ne présumez pas que la modification de la configuration globale supprime les substitutions de serveur existantes. Dans un environnement multi-serveurs, vérifiez chaque nœud de boîte aux lettres et chaque MTA concernés.
Confirmation de l'entrée en vigueur de la limite MTA
Après avoir modifié l'attribut MTA global et rechargé Postfix, vérifiez la valeur Postfix effective sur chaque MTA Zimbra :
su - zimbra
zmprov gcf zimbraMtaMaxMessageSize
postconf message_size_limit
Les deux résultats doivent correspondre en octets. Si l'attribut LDAP est correct mais postconfaffiche toujours l'ancienne limite, consultez la procédure de configuration et les journaux de Zimbra MTA avant de procéder à un redémarrage complet. Un redémarrage peut interrompre les services de messagerie ; par conséquent, ne le planifiez que si la version installée et la topologie de déploiement l'exigent.
Le proxy de Zimbra détermine la limite de taille du corps des requêtes HTTP à partir de la configuration zimbraFileUploadMaxSizedu proxy. Si votre environnement inclut également un serveur Nginx, Apache, une passerelle cloud ou un dispositif de sécurité distinct devant Zimbra, ce composant peut avoir sa propre limite de taille d'envoi. Une réponse 413 ou une entrée dans les journaux du proxy indique qu'il faut vérifier la limite de taille du corps des requêtes au niveau de la couche ayant renvoyé l'erreur. Évitez de modifier directement les fichiers de proxy générés par Zimbra ; effectuez les modifications via les paramètres Zimbra compatibles et utilisez la procédure de régénération de la configuration ou de redémarrage documentée pour votre version.
Test avec un message contrôlé
- Utilisez une boîte mail de test et un fichier dont la taille est légèrement inférieure à la limite de pièces jointes prévue. N'utilisez pas le fichier le plus volumineux que le système puisse accepter.
- Joignez le fichier à votre messagerie web Zimbra. Si votre navigateur indique que le fichier est trop volumineux, vérifiez
zimbraFileUploadMaxSizeles paramètres du serveur de messagerie et les limites du proxy.
- Envoyez le message à une autre boîte mail de test interne. Si le chargement réussit mais que l'envoi échoue, vérifiez la limite SOAP et la limite MTA de la boîte mail.
- Veuillez consulter le texte de retour et les journaux. Les instructions MTA de Zimbra indiquent que Postfix rejette un message trop volumineux avec une erreur de taille 552 et recommandent de vérifier
/var/log/zimbra.logles événements de rejet, de dépassement, de limite ou d'avertissement.
- Si la distribution interne fonctionne mais qu'un destinataire externe rejette le message, vérifiez la limite de taille annoncée ou documentée par ce destinataire. Vos paramètres Zimbra ne peuvent pas augmenter cette limite sur un autre système de messagerie.
Pour les envois SMTP sortants, Postfix peut annoncer la taille maximale acceptée dans ses SIZEparamètres SMTP. Un serveur de messagerie distant peut annoncer une taille inférieure ou rejeter le message après son envoi par Zimbra. L'article de dépannage de Zimbra explique comment distinguer un rejet local du MTA d'un rejet côté destinataire. Consultez la documentation de référence sur les paramètres de taille des messages de Postfix et les exemples de dépannage relatifs à la taille des messages du MTA dans Zimbra .
Quand utiliser plutôt un lien de partage de fichiers
Les limites de taille des pièces jointes par courriel ne constituent pas une méthode fiable pour diffuser des fichiers multimédias volumineux, des images disque ou des archives de projets. Chaque système de messagerie du destinataire peut imposer une limite de taille de message différente, et les messages chiffrés sont plus volumineux que leurs pièces jointes d'origine. Si une limite plus élevée risque de saturer l'espace de stockage ou la capacité de la file d'attente, partagez le fichier via un service de partage de fichiers autorisé et envoyez par courriel un lien nécessitant une autorisation.
La modification est réussie lorsqu'un fichier de test, conformément à la nouvelle politique, est téléchargé, envoyé et reçu par un destinataire interne, et que Postfix indique la taille de message prévue. Si certains utilisateurs ou nœuds de serveur rencontrent toujours des problèmes, comparez leurs paramètres de serveur de messagerie et de proxy. Si seuls les destinataires externes rejettent les e-mails, vérifiez leur limite avant d'augmenter à nouveau les plafonds de Zimbra.