Limites de taille des messages e-mail : augmentez-les en toute sécurité sans ouvrir la porte aux abus

Ce qui limite réellement la taille d’un e-mail (et pourquoi «il suffit d’augmenter» échoue)

La taille d’un message e-mail n’est pas un seul réglage. C’est une chaîne de contraintes : client → serveur de soumission → passerelle entrante → filtres de contenu → magasin de boîtes → passerelle sortante → MX distant.
Si un maillon rejette, l’expéditeur reçoit un NDR, un bounce, ou (pire) un report silencieux qui se transforme en file bloquée. L’astuce est d’identifier quel maillon est la vraie contrainte, puis d’augmenter uniquement jusqu’à ce que votre système et votre modèle de risque l’acceptent.

La taille que vous voyez n’est pas la taille qui est envoyée

Les pièces jointes sont généralement encodées en base64, ce qui ajoute environ 33 % d’overhead. Il y a ensuite la structure MIME, les en-têtes, et parfois une ré-encodage par des passerelles.
Une «limite de pièce jointe à 25 Mo» se traduit souvent par une limite de message dans le MTA de l’ordre de 33–36 Mo sur le réseau. Si vous n’en tenez pas compte, vous «augmentez à 30 Mo» et bloquez encore des PDF de 23 Mo qui deviennent 31 Mo à l’envoi.

Où les limites se cachent

• MUA (client) : Outlook, clients mobiles et webmail peuvent imposer des limites d’interface ou des politiques fournies par le serveur.
• Soumission (MSA) : le point de terminaison SMTP authentifié peut avoir des limites plus strictes que le MX entrant.
• MTA : règles de transport Postfix/Exim/Sendmail/Exchange, plus les plafonds par connecteur.
• Proxies SMTP : load balancers, terminateurs TLS, proxies mail (et des middleboxes «aidantes») peuvent limiter la taille du corps de requête ou les timeouts.
• Filtrage : antivirus, DLP, sandboxing et filtres anti-spam peuvent refuser de gros payloads ou expirer lors de leur analyse.
• Magasin de boîtes : quotas par boîte, limites par message et contraintes de base de données.
• Côté distant : votre limite sortante ne compte pas si la destination rejette tout au-dessus de 10–25 Mo.

Une citation pratique pour les revues de changement : L’espoir n’est pas une stratégie. — Gene Kranz.

Voici la réalité inconfortable : augmenter votre limite ne garantit pas la délivrabilité. Cela garantit seulement que vous accepterez plus de données, les conserverez plus longtemps, et dépenserez plus de CPU et de disque dessus avant d’apprendre que le site distant ne les accepte pas.
C’est pourquoi la «sécurité» concerne les contrôles, l’observabilité et les plans de repli, pas seulement des nombres plus élevés.

Faits et contexte historique à utiliser en réunion

Voici des points petits et concrets qui vous aident à expliquer pourquoi vous ne pouvez pas transformer l’e-mail en Dropbox.

1. Les pièces jointes MIME n’étaient pas prévues dans le design initial de l’e-mail. Les premiers e-mails étaient principalement du texte brut ; MIME (multipurpose internet mail extensions) est arrivé plus tard pour standardiser les pièces jointes et le contenu riche.
2. L’encodage base64 gonfle les données. Les fichiers binaires sont encodés en texte ASCII sûr pour le transport, coûtant environ un tiers en overhead dans les cas courants.
3. «SIZE» est une extension SMTP, pas une garantie. Beaucoup de MTAs annoncent une taille maximale dans les salutations SMTP, mais des intermédiaires peuvent encore rejeter plus tard.
4. 25 Mo est devenu un défaut social, pas une norme. De nombreux fournisseurs ont convergé autour de 10–25 Mo parce que c’est un compromis entre utilisabilité et risque d’abus ; c’est une commodité opérationnelle avec un habit de soirée.
5. Les gros messages sont un risque de disponibilité. Un message géant peut monopoliser l’analyse, créer de longues sessions SMTP et augmenter la latence des files ; ce n’est pas «juste plus de stockage».
6. Les magasins de mail étaient optimisés historiquement pour beaucoup de petits éléments. Beaucoup de petits messages constituent la charge normale ; les grosses pièces jointes créent des schémas IO différents, des comportements de compactage et des coûts d’index.
7. Certains filtres décompressent les pièces jointes. Un zip «petit» peut prendre beaucoup de place à l’analyse ; les limites peuvent s’appliquer à la taille étendue, pas seulement au payload SMTP brut.
8. Les timeouts comptent davantage à mesure que la taille augmente. Un message de 40 Mo sur une liaison montante lente peut maintenir une transaction SMTP ouverte assez longtemps pour atteindre des limites par connexion ou des timeouts de reverse proxy.

Blague #1 : L’e-mail est le seul protocole de transfert de fichiers qui vous présente des excuses en échouant.

Un cadre de décision : devez-vous vraiment augmenter les limites ?

Augmenter les limites est parfois la bonne décision. Parfois c’est le faux-semblant du service client. Décidez comme un opérateur, pas comme quelqu’un qui veut juste fermer un ticket.

Quand augmenter les limites a du sens

• Des flux métier critiques reposent sur l’e-mail. Les parties externes n’utilisent pas votre portail et vous ne pouvez pas imposer un autre canal.
• Vous avez des contrôles entrants solides. Filtrage anti-spam moderne, scan de malware et limitation de débit sont en place et surveillés.
• Votre stockage et vos systèmes de file sont dimensionnés pour le pire cas. «Un jour normal» ne suffit pas ; prévoyez «campagne marketing + incident + pannes distantes».
• Vous pouvez tolérer la non-livraison pour certains destinataires. Vous rencontrerez toujours des limites distantes ; les utilisateurs doivent accepter des solutions alternatives (liens, partages, transfert sécurisé).

Quand augmenter les limites est un piège

• Vous tentez de compenser un partage de fichiers cassé. Réparez le partage de fichiers. L’e-mail n’est pas votre plan de secours pour l’outil de collaboration.
• Vous ne contrôlez pas votre réputation sortante. Des messages plus volumineux peuvent augmenter les retries, la latence de la file et influencer les scores de spam ; la délivrabilité peut devenir étrange.
• Votre chaîne de filtrage est déjà surchargée. Si votre sandbox AV est proche de la saturation, de plus gros payloads transformeront «près de la saturation» en «down».

Définissez deux limites, pas une

Les opérateurs qui tiennent le coup définissent des limites séparées pour :

• Entrant depuis Internet (plus strict ; risque d’abus plus élevé).
• Soumission authentifiée / sortant (un peu plus élevé ; contrôlé par des limites de débit et des politiques utilisateur).

Puis ils créent des exceptions pour des expéditeurs/destinataires ou domaines spécifiques, pas une fête globale «tout le monde a 100 Mo maintenant».

Mode opératoire de diagnostic rapide (premières / secondes / troisièmes vérifications)

Si vous êtes d’astreinte et que quelqu’un hurle «les gros e-mails échouent», n’allez pas fouiller les configs en premier. Localisez le goulet.
Le geste gagnant est de trouver le premier composant qui connaît la vérité : le composant qui renvoie le code SMTP.

Premier : identifiez où ça échoue (et obtenez le code SMTP)

• Demandez le texte du bounce / NDR ou les en-têtes du message. Vous cherchez des codes comme 552, 554, 451 et des chaînes «message too big».
• Vérifiez les logs du MTA pour la transaction : avez-vous rejeté au moment du DATA SMTP, ou accepté puis bounce plus tard ?
• Si l’expéditeur est interne, reproduisez avec swaks ou un test contrôlé depuis un hôte connu.

Second : décidez si c’est une limite annoncée, un proxy ou un timeout de filtre

• 552 immédiat sur DATA : une taille maximale configurée dans le MTA/proxy récepteur.
• Accepté puis bounce plus tard : rejet du filtre/mailstore en aval ou résultat de l’analyse de contenu.
• Long délai puis expiration : timeout d’un proxy, backlog du scanner de contenu, ou disque lent.

Troisième : vérifiez la santé des files et la pression disque

• Recherchez croissance de la file, messages différés et tempêtes de retries.
• Confirmez l’espace disque et la disponibilité des inodes ; les gros messages peuvent créer de nombreux fichiers temporaires.
• Vérifiez l’iowait ; le traitement de gros messages est souvent un problème de débit/latence disque.

Si vous ne pouvez pas répondre «où ça échoue ?» en cinq minutes, vous n’avez pas un problème de taille d’e-mail ; vous avez un problème d’observabilité.

Tâches pratiques avec commandes, sorties et décisions (12+)

L’objectif de ces tâches n’est pas de mémoriser des commandes. C’est de construire une méthode reproductible pour prouver où se trouve la limite, si votre système peut gérer la nouvelle taille, et si les contrôles anti-abus fonctionnent toujours.

Task 1: Confirm Postfix maximum message size

cr0x@server:~$ postconf message_size_limit
message_size_limit = 10485760

Ce que signifie la sortie : Postfix rejettera les messages supérieurs à 10,485,760 octets (~10 Mo) au moment du DATA SMTP.

Décision : Si vous augmentez pour des «pièces jointes 25 Mo», envisagez de régler message_size_limit à ~35–40 Mo pour tenir compte de l’overhead base64/MIME, et validez d’abord les limites en aval.

Task 2: Check mailbox size and message limits in Dovecot (common for IMAP backends)

cr0x@server:~$ doveconf -n | egrep 'mail_max_size|quota'
mail_max_size = 0
plugin {
  quota = maildir:User quota
}

Ce que signifie la sortie : mail_max_size = 0 signifie souvent «pas de plafonnement par-message imposé par Dovecot», mais les quotas s’appliquent toujours via le plugin quota.

Décision : Si mail_max_size est non nul et inférieur à votre nouvel objectif, vous devez l’augmenter sinon vous accepterez via SMTP puis échouerez à la livraison en boîte.

Task 3: Identify the effective size advertised via SMTP (SIZE extension)

cr0x@server:~$ swaks --server mx1.example.net --ehlo test.example --quit-after EHLO
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<  220 mx1.example.net ESMTP Postfix
 > EHLO test.example
<  250-mx1.example.net
<  250-SIZE 10485760
<  250-PIPELINING
<  250-STARTTLS
<  250 HELP
=== Connection closed with remote host.

Ce que signifie la sortie : Le serveur annonce une limite de 10 Mo via l’extension SMTP.

Décision : Si vous augmentez message_size_limit mais continuez d’annoncer l’ancienne taille, les clients peuvent refuser d’envoyer. Assurez-vous que le SIZE annoncé correspond à votre limite réelle de réception.

Task 4: Verify Nginx (or another proxy) isn’t capping SMTP/HTTP upload paths

cr0x@server:~$ nginx -T 2>/dev/null | egrep 'client_max_body_size|proxy_read_timeout|proxy_send_timeout'
client_max_body_size 10m;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Ce que signifie la sortie : Si ce Nginx fait front pour le webmail ou une soumission par API, il plafonne les requêtes à 10 Mo et a des timeouts courts.

Décision : Augmentez la taille du corps et les timeouts si de gros messages traversent ce proxy, ou acceptez que les utilisateurs webmail échouent même si le SMTP fonctionne.

Task 5: Check Postfix queue depth and deferred messages

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9D2F21C03A*    84231 Mon Jan  4 10:12:41  alerts@example.net
                                         user@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
-- 1 Kbytes in 1 Request.

Ce que signifie la sortie : Vous avez au moins une livraison différée à cause de timeouts de connexion distante ; la file n’est pas énorme ici, mais vous avez besoin de la vue complète.

Décision : Si la file augmente après l’augmentation de taille, vous pourriez accepter de gros messages qui ne peuvent être livrés. Ajoutez une politique : rejeter tôt pour les limites distantes connues ou fournir une guidance utilisateur.

Task 6: Summarize Postfix queue by status (active vs deferred)

cr0x@server:~$ postqueue -p | egrep -c '^[A-F0-9]'
42

Ce que signifie la sortie : Il y a 42 entrées en file (compte approximatif basé sur les lignes d’ID de file).

Décision : Si ce nombre monte en flèche lors d’envois de gros fichiers, vous aurez besoin de throttling, d’un meilleur routage de livraison, ou de limites sortantes internet plus basses.

Task 7: Watch log evidence of size-based rejects

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | egrep 'message size|too large|552' | tail -n 5
Jan 04 10:14:22 mx1 postfix/smtpd[23144]: NOQUEUE: reject: RCPT from mail.remote.tld[203.0.113.55]: 552 5.3.4 Message size exceeds fixed maximum message size; from=<sender@remote.tld> to=<user@example.com> proto=ESMTP helo=<mail.remote.tld>

Ce que signifie la sortie : Le rejet a lieu sur votre daemon SMTP. C’est un plafond configuré localement, pas un souci du magasin de boîtes en aval.

Décision : Augmentez la limite de réception pertinente (et confirmez que vous n’avez pas raté un réglage plus strict par service comme soumission vs entrant).

Task 8: Confirm disk space and inode availability (large mail stresses both)

cr0x@server:~$ df -h /var/spool/postfix /var/mail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       200G  176G   15G  93% /
/dev/sdb1       500G  120G  355G  26% /var/mail

Ce que signifie la sortie : Le spool est sur / et est utilisé à 93 %. C’est une panne de file en attente.

Décision : Déplacez le spool vers un système de fichiers dédié ou augmentez la capacité avant d’augmenter les limites ; les gros messages augmentent fortement l’utilisation transitoire du spool.

Task 9: Check IO pressure during message ingestion

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (mx1) 	01/04/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    4.12   32.55    0.00   53.12

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
sda              3.00     64.00     0.00   0.00    2.10    21.33  220.00  18432.00    12.00   5.17   45.30    83.78   9.96  98.00

Ce que signifie la sortie : Un %iowait élevé et une utilisation disque proche de 100 % indiquent que le serveur est lié par l’IO. Le traitement de gros messages amplifiera cela.

Décision : Avant d’augmenter les limites, corrigez l’IO (stockage plus rapide, séparation du spool, ajustement de la concurrence de scan). Sinon vous transformerez un serveur «parfois lent» en serveur «principalement en panne».

Task 10: Confirm Postfix recipient restrictions and auth separation (abuse control baseline)

cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_client_restrictions|smtpd_tls_security_level|smtpd_sasl_auth_enable'
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_tls_security_level = may
smtpd_sasl_auth_enable = yes

Ce que signifie la sortie : Le relay est restreint (bien), et les utilisateurs authentifiés sont autorisés. TLS est opportuniste (may), ce qui peut être acceptable selon la politique.

Décision : Si vous augmentez les tailles pour la soumission authentifiée, maintenez des limites entrantes anonymes plus strictes. Et assurez-vous de ne pas permettre un relais ouvert par inadvertance.

Task 11: Spot rate limiting gaps (connection and message concurrency)

cr0x@server:~$ postconf -n | egrep 'smtpd_client_connection_count_limit|smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit'
smtpd_client_connection_count_limit = 50
smtpd_client_message_rate_limit = 0
smtpd_client_recipient_rate_limit = 0

Ce que signifie la sortie : Le nombre de connexions est limité, mais les limites de message et de destinataire sont désactivées (0). Si vous augmentez les tailles, l’abus peut coûter cher rapidement.

Décision : Mettez en place des limites de débit pour l’entrée anonyme et envisagez des politiques séparées par écoute (MX entrant vs soumission). Les messages plus volumineux augmentent le coût par message ; traitez-les comme une ressource rare.

Task 12: Measure the largest messages you’re already processing (reality check)

cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n 5
38912044 /var/spool/postfix/deferred/9/9D2F21C03A
22100412 /var/spool/postfix/deferred/1/1A7B0D11F2
18000210 /var/spool/postfix/deferred/C/C2D11E9AA0
15011401 /var/spool/postfix/deferred/4/45B2A9B1C3
12000877 /var/spool/postfix/deferred/7/7CC9F1022B

Ce que signifie la sortie : Vous avez déjà des éléments d’environ ~39 Mo en différé. Soit votre limite d’entrée est plus élevée que vous ne le pensez, soit ces messages ont grossi plus tard à cause du traitement interne.

Décision : N’augmentez pas les limites à l’aveugle. D’abord, comprenez pourquoi de gros éléments sont présents : acceptés avant un changement de config, injectés localement, ou arrivant via un écouteur différent avec des plafonds différents.

Task 13: Validate end-to-end delivery to a known external provider (the uncomfortable truth)

cr0x@server:~$ swaks --server submission.example.net --port 587 --auth LOGIN --auth-user user@example.com --auth-password 'REDACTED' --tls --to external-test@remote.tld --from user@example.com --attach /tmp/25mb.bin
=== Trying submission.example.net:587...
=== Connected to submission.example.net.
<  220 submission.example.net ESMTP Postfix
 > EHLO mx1.example.net
<  250-submission.example.net
<  250-SIZE 41943040
<  250-STARTTLS
<  250-AUTH PLAIN LOGIN
<  250 HELP
...
<  250 2.0.0 Ok: queued as 3F1A2B9C0D

Ce que signifie la sortie : La soumission annonce ~40 Mo, et le message a été accepté et mis en file. Ce n’est que la moitié de l’histoire.

Décision : Suivez l’ID de file dans les logs de livraison sortante. S’il est ensuite différé ou bounce à cause des limites distantes, vous devez fournir des instructions aux utilisateurs et éventuellement réduire la taille max sortante pour les destinations internet.

Task 14: Track that queue ID until delivered or bounced

cr0x@server:~$ sudo journalctl -u postfix --since "10 min ago" | egrep '3F1A2B9C0D' | tail -n 8
Jan 04 10:20:18 mx1 postfix/qmgr[1022]: 3F1A2B9C0D: from=<user@example.com>, size=35781234, nrcpt=1 (queue active)
Jan 04 10:20:49 mx1 postfix/smtp[24110]: 3F1A2B9C0D: to=<external-test@remote.tld>, relay=mx.remote.tld[203.0.113.10]:25, delay=31, delays=0.2/0.1/10/21, dsn=5.2.3, status=bounced (host mx.remote.tld[203.0.113.10] said: 552 5.2.3 Message size exceeds fixed maximum message size (in reply to end of DATA command))

Ce que signifie la sortie : Votre système a accepté et tenté de livrer un message d’environ ~35.8 Mo, mais le distant l’a rejeté avec 552 à la fin du DATA.

Décision : Aucune augmentation locale ne corrige les politiques distantes. Fournissez des alternatives : partage de fichiers, transfert sécurisé, ou routage spécifique par domaine (si vous avez des partenaires de confiance avec des plafonds plus élevés).

Task 15: Confirm content filter performance and backlog (example with Amavis-like log grep)

cr0x@server:~$ sudo journalctl --since "30 min ago" | egrep 'amavis|clamd|timeout|too large' | tail -n 8
Jan 04 10:18:03 mx1 amavis[1888]: TIMING [abc123]: smb=0.012 (0.012+0.000) out=0.004 (0.004+0.000) m=1.234 (1.221+0.013)
Jan 04 10:18:04 mx1 amavis[1888]: (1888-12) WARN: timed out while scanning, quarantined
Jan 04 10:18:05 mx1 postfix/smtp[24002]: warning: conversation with content-filter.example.net[192.0.2.25] timed out while sending message body

Ce que signifie la sortie : L’analyse a expiré, et Postfix a expiré en envoyant le message au filtre de contenu. Les gros messages déclencheront davantage ces cas.

Décision : Ajustez les timeouts et la concurrence du filtre, scalez la couche de filtrage, ou maintenez des limites conservatrices. Votre goulot est l’analyse, pas le SMTP.

Task 16: Verify TLS and session timeouts that matter more for large payloads

cr0x@server:~$ postconf -n | egrep 'smtp_data_xfer_timeout|smtpd_timeout|smtpd_data_restrictions'
smtp_data_xfer_timeout = 180s
smtpd_timeout = 60s
smtpd_data_restrictions = reject_unauth_pipelining

Ce que signifie la sortie : Le timeout de transfert de données pour l’outbound est de 180s ; le timeout de session inbound est de 60s. Les gros uploads depuis des clients lents peuvent être coupés.

Décision : Augmentez les timeouts avec parcimonie sur la soumission (utilisateurs authentifiés) si nécessaire, mais gardez l’entrée MX stricte pour réduire l’exposition aux abus et au blocage des ressources.

Contrôles anti-abus lors de l’augmentation des limites

Lorsque vous augmentez les limites de taille, vous augmentez le coût de chaque message accepté : disque, CPU, temps d’analyse et bande passante de retry.
Les attaquants adorent les opérations coûteuses. Vous leur offrez un jouet plus onéreux.

Séparez les zones de confiance : MX entrant vs soumission authentifiée

N’appliquez pas la même politique aux expéditeurs anonymes d’internet et aux utilisateurs authentifiés. Ils n’ont pas le même modèle de menace.
Une configuration propre :

• MX entrant : limite de taille plus basse, timeouts stricts, limitation de débit agressive, rejet précoce.
• Soumission (587/465) : limite plus haute, throttles par utilisateur, authentification forte, surveillance liée à l’identité.

Limitation de débit qui compte vraiment

Pour les gros messages, la limitation n’est pas seulement «messages par minute». Il s’agit aussi de :

• Connexions simultanées par IP client (empêche les essaims d’upload).
• Livraisons simultanées par domaine (empêche les tempêtes de retries vers un distant en échec).
• Octets par unité de temps (beaucoup de MTAs ne le gèrent pas directement ; vous l’approchez avec des limites de session et de message).

Rejets précoces : le cheap est beau

Le meilleur rejet est celui que vous effectuez avant d’écrire 80 Mo sur disque et de passer le message dans trois scanners.
Si vous savez qu’un domaine partenaire n’accepte que 10–15 Mo, n’acceptez pas 40 Mo destiné là-bas puis ne le rebouchez pas après. C’est impoli opérationnellement.
Utilisez des transport maps ou des services de politique pour faire respecter des plafonds par destination si votre MTA le permet.

Contrôles basés sur l’identité pour l’outbound

Une fois que vous autorisez de plus gros messages sortants, la compromission de compte devient plus coûteuse. Ajoutez :

• Limites d’envoi quotidiennes par utilisateur (messages et destinataires).
• Contrôles sur les types de pièces jointes (bloquer les exécutables, archives risquées).
• Alertes sur les patterns d’envoi massif : «Un utilisateur qui n’envoie jamais de pièces jointes vient d’envoyer 60 messages de 30 Mo chacun.»

Blague #2 : Le moyen le plus rapide d’apprendre que votre limite est trop haute est de voir un spammeur traiter votre serveur SMTP comme un CDN gratuit.

Stockage et performance : le gros mail est un problème disque en costume

La plupart des incidents «on a augmenté la limite et l’e-mail est devenu instable» ne sont pas des bugs SMTP. Ce sont des problèmes de ressources :
disque rempli, pics de latence IO, scanners qui expirent, files qui gonflent, puis les retries créent plus de charge. Une boucle de rétroaction positive classique, juste avec moins de graphes et plus de cadres furieux.

Spool vs mailstore : séparez-les

La file/spool Postfix est un ensemble de travail transitoire. Elle veut :

• latence prévisible (faibles temps d’attente),
• marge de manœuvre (espace pour les pics),
• comportement fsync rapide (journaling réglé sensément),
• et isolation des compactages et sauvegardes du mailstore.

Si votre spool partage un système de fichiers avec des logs OS, images de conteneurs ou «exports analytiques temporaires», vous faites fonctionner votre serveur mail sur des impressions.
Placez le spool sur un stockage dédié, dimensionné pour les files différées au pire cas.

Les gros messages changent le schéma IO

Les petits mails sont riches en métadonnées : beaucoup de petits fichiers, recherches dans les répertoires, index. Les gros mails ajoutent des écritures et lectures à haut débit.
Votre système doit maintenant gérer les deux : bonne performance métadonnée et débit massif. Sur des disques rotatifs, c’est là que les rêves meurent.

Le scan de contenu est la taxe cachée CPU/disque

L’antivirus et le DLP peuvent :

• décompresser des archives (augmentant la charge),
• réassembler des parties MIME,
• exécuter des heuristiques qui croissent avec la taille,
• et tenir les messages dans un stockage temporaire pendant l’analyse.

Si vous augmentez les limites, considérez la capacité de scan comme une dépendance de première classe. Sinon vous accepterez des mails puis bloquerez dans votre propre chaîne de filtres.

Les timeouts ne sont pas «juste réseau»

Les gros messages augmentent le temps passé dans chaque phase : upload, passage au filtre, scan, mise en file, livraison. Un timeout qui était «sûr» à 10 Mo peut être inadapté à 40 Mo.
Mais ne résolvez pas cela en rendant tous les timeouts énormes. C’est ainsi que les sessions SMTP de type slowloris monopolisent les sockets toute la journée.
Timeouts serrés sur l’entrée anonyme, plus lâches sur la soumission authentifiée—répétez jusqu’à ce que ça devienne politique.

Trois mini-récits d’entreprise (ce qui arrive réellement)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exécutait une stack mail propre : passerelles entrantes, Postfix, filtrage de contenu, magasin de boîtes. Des tickets support arrivent : «Impossible d’envoyer des fichiers de 20–30 Mo aux clients.»
L’administrateur mail a augmenté message_size_limit sur les passerelles entrantes et a considéré le travail fait. Tout le monde a applaudi.

Deux jours plus tard, les files sortantes ont grossi. Pas énormément au début—juste une augmentation régulière. Puis lundi matin est arrivé. Les utilisateurs envoyaient de plus grandes pièces jointes aux partenaires, la passerelle les acceptait, et la livraison sortante a commencé à rebondir avec des erreurs 552 depuis plusieurs domaines destinataires.
Maintenant la file contenait une pile de gros messages non livrables. Chaque tentative de retry créait plus de bruit dans les logs, plus de churn disque, et plus de confusion.

La mauvaise hypothèse était simple : «Si on accepte plus, ça sera livré.» L’internet ne signe pas votre note de politique interne.
Beaucoup de domaines destinataires appliquent des plafonds de 10–25 Mo et ne négocient pas. Votre MTA le découvre seulement après avoir lu tout le payload DATA et tenté la livraison.

La correction n’a pas été «augmenter encore les limites». La correction a été d’appliquer des politiques conscientes de la destination et de fournir une alternative sanctionnée pour le transfert de fichiers.
Ils ont fini par garder des limites plus hautes seulement pour une poignée de domaines partenaires de confiance (avec plafonds confirmés), tandis que la limite internet générale est restée conservatrice.

La vraie leçon : vous ne relevez pas simplement une limite ; vous changez la forme du trafic. Et la forme du trafic change vos modes de défaillance.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a essayé d’être futée. Ils avaient des délais d’analyse antivirus, donc ils ont «optimisé» en sautant le scan profond pour les messages au-delà d’une certaine taille.
La logique semblait pragmatique : «Les gros PDF clients sont généralement OK, et les scanner prend trop de temps. On réduira la latence.»

Ça a marché une semaine. La latence mail est tombée. La file semblait plus saine. Puis ils ont subi une campagne qui utilisait de grosses pièces jointes comme vecteur de livraison—suffisamment grandes pour échapper à leur raccourci et pour ralentir l’examen manuel.
Quelques points d’accès compromis plus tard, l’équipe sécurité est intervenue, et soudain l’équipe mail revivait toute la réunion d’approbation du changement, mais avec plus de monde et moins de blagues.

L’optimisation était basée sur une fausse prémisse : que «taille corrèle avec sécurité». Les attaquants peuvent payer les octets. Vous ne pouvez pas payer la confiance.
Les grosses pièces jointes sont mieux pour dissimuler des payloads et épuiser les systèmes ; elles ne sont pas «probablement sûres».

La correction a été ennuyeuse : scaler correctement la couche de scan, garder une politique de scan cohérente, et ajouter des caps et timeouts sensés pour qu’un message ne monopolise pas les ressources.
Ils ont aussi mis en place des throttles par expéditeur pour empêcher «un compte compromis envoie 500 grosses pièces jointes» de devenir un problème d’infrastructure.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée voulait augmenter la taille des messages pour les soumissions authentifiées parce qu’un fournisseur spécifique ne communiquait que par e-mail et envoyait régulièrement de grands documents annotés.
L’équipe messagerie a fait quelque chose de profondément peu tendance : ils l’ont déployé dans un environnement de test qui reproduisait le chemin mail réel, y compris les filtres de contenu et les quotas de boîte.

Ils ont réalisé des tests de charge : dix envois concurrents de 35 Mo, puis vingt, puis une charge mixte avec du mail normal plus de gros messages.
Ils ont surveillé l’IO disque, les latences des filtres, les tailles de file et les performances d’écriture des boîtes. Ils n’ont pas supposé. Ils ont mesuré.

Pendant les tests ils ont découvert un point d’étranglement inattendu : un filesystem temporaire utilisé par le scanner DLP avait une petite taille et des options de montage par défaut. Sous charge de rafale, il s’est rempli et a commencé à échouer les scans.
En production, cela aurait ressemblé à des reports de livraison aléatoires, ce qui est le pire type de panne : intermittent au point d’être remis en question.

Ils ont corrigé le dimensionnement du stockage temporaire, séparé le stockage du spool, et défini des throttles par utilisateur. Quand ils ont finalement augmenté la limite, rien de dramatique ne s’est produit.
Le changement a fonctionné, les utilisateurs ont obtenu leurs e-mails plus volumineux, et l’astreinte a gardé son week-end.

La pratique qui les a sauvés n’était pas un outil chic. C’était des tests de bout en bout incluant des goulets réalistes.

Listes de contrôle / plan étape par étape

Plan étape par étape pour augmenter les limites en toute sécurité

1. Clarifiez l’exigence métier en octets, pas en impressions. «25 Mo de pièces jointes» n’est pas une valeur technique. Décidez la taille cible de pièce jointe et calculez la taille filaire avec overhead (prévoir ~1,35x pour base64/MIME).
2. Cartographiez votre vrai chemin mail. Dessinez la chaîne : client → soumission → passerelles → filtres → mailstore → sortant. Incluez proxies, DLP, archivage, journalisation et sauvegardes.
3. Trouvez les plafonds actuels à chaque couche. Paramètres MTA, proxies, filtres, limites de boîte, quotas, plafonds de connecteurs.
4. Choisissez des limites séparées par zone de confiance. Cap MX entrant plus bas ; soumission authentifiée peut être plus haute avec contrôles par utilisateur.
5. Confirmez le comportement de scan et du stockage temporaire. Sachez où les gros messages sont mis en scène pendant l’analyse et ce qui se remplit d’abord (espace disque, inodes, RAM, tempfs).
6. Planifiez la capacité du spool. Taille de file au pire cas : considérez les pannes distantes où les messages sont différés pendant des heures. Les gros messages rendent les «heures» coûteuses.
7. Mettez en place des limites de débit et contrôles d’identité avant d’augmenter la taille. N’augmentez pas la surface d’attaque sans garde-fous.
8. Augmentez les limites par paliers. Exemple : 10 Mo → 20 Mo → 35–40 Mo filaire. Observez après chaque étape.
9. Testez de bout en bout avec de vrais clients et des outils SMTP. Validez à la fois la soumission et l’entrée. Validez la livraison vers des domaines externes courants.
10. Actualisez la communication aux utilisateurs. Rendez explicite le chemin «que faire quand ça rebondit» : partage de liens, conseils de compression, options de transfert sécurisé.
11. Ajoutez des tableaux de bord et alertes spécifiques à la pression des gros mails. Profondeur de file, distribution de taille des éléments en file, timeouts de filtre, IO wait, usage de files temporaires.
12. Revue post-changement. Cherchez des décalages : augmentation de la taille moyenne des messages, churn de file, augmentation des retries, latence de scan accrue.

Checklist go/no-go pour la fenêtre de changement

• Le filesystem du spool a au moins 30–40 % d’espace libre et une latence IO saine en charge.
• La couche de filtres de contenu a de la capacité disponible ; pas de timeouts dans les logs sous charge de test.
• Les listeners de soumission et d’entrée ont des politiques clairement différentes.
• Les limites de débit sont configurées et testées (y compris le comportement en cas de faux positifs).
• La surveillance existe pour la croissance de la file, les comptes différés et les tendances d’utilisation disque.
• Un plan de rollback est rédigé et rapide (revenir la config + reload).
• La communication aux utilisateurs est prête : «Certains destinataires externes peuvent toujours rejeter les messages au-dessus de X Mo ; utilisez Y à la place.»

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: Users still can’t send large attachments after you raised Postfix

Cause racine : Le client ou le service de soumission impose un plafond plus bas que votre MX entrant, ou un proxy limite la taille de requête.

Correction : Vérifiez l’écouteur de soumission authentifiée (587/465) séparément, confirmez l’annonce SIZE via swaks, et vérifiez tout client_max_body_size webmail/proxy ou équivalent.

2) Symptom: Mail is accepted but bounces hours later

Cause racine : Les domaines distants rejettent les gros messages (552) et votre serveur retry jusqu’au bounce ; ou un filtre/mailstore en aval rejette après acceptation.

Correction : Suivez les IDs de file. Si le distant rejette, appliquez des limites/consignes par destination. Si des composants internes rejettent, alignez les plafonds entre filtre et mailstore pour rejeter tôt au SMTP.

3) Symptom: Queue size explodes after raising limit

Cause racine : Vous acceptez des messages coûteux qui ne peuvent pas être livrés rapidement ; les retries s’accumulent. Souvent déclenché par des pannes distantes, de mauvais routes ou du throttling distant.

Correction : Ajoutez des contrôles de concurrence sortants, throttling par domaine, et des caps internet conservateurs. Envisagez des tailles max plus basses pour les routes internet et des plafonds plus hauts pour les partenaires de confiance.

4) Symptom: Random “timeout” errors in logs during large sends

Cause racine : Timeouts de proxy, backlog du filtre de contenu, ou saturation IO disque causant un traitement lent.

Correction : Augmentez les timeouts sur les chemins de soumission uniquement, scalez la capacité de filtre, et corrigez les goulets IO. Ne montez pas juste les timeouts globalement ; vous attirerez les sessions voraces.

5) Symptom: Disk fills even though average mail volume didn’t change much

Cause racine : Quelques gros messages peuvent consommer disproportionnellement l’espace du spool, surtout lorsqu’ils sont différés ou dupliqués dans des pipelines de scan/journaling.

Correction : Dimensionnez le spool pour les rafales, séparez spool et mailstore, surveillez les plus gros éléments en file, et appliquez une politique pour rejeter ou détourner les mails trop volumineux tôt.

6) Symptom: Some users can send big mail, others can’t

Cause racine : Différents endpoints de soumission avec des limites différentes (ex. passerelles régionales), ou différences de politique/connecteur par utilisateur.

Correction : Inventoriez tous les listeners et connecteurs ; standardisez la politique. Documentez explicitement les exceptions au lieu de les découvrir via les plaintes.

7) Symptom: Security team reports increased malware detections after raising limits

Cause racine : Les pièces jointes plus grandes augmentent la surface d’attaque ; si le scan a été sauté ou les timeouts augmentés sans scaler, plus de contenu risqué passe ou est quarantaine de façon incohérente.

Correction : Gardez le scan consistant, scalez les ressources de scan, ajustez les timeouts avec soin, et implémentez des politiques de types de pièces jointes et du sandboxing lorsque pertinent.

8) Symptom: IMAP/webmail feels slow after the change

Cause racine : L’indexation du mailstore, la recherche et la synchronisation client traitent maintenant des blobs plus gros ; le tier de stockage peut souffrir d’une amplification de lecture.

Correction : Révisez la stratégie de stockage et d’indexation du mailstore, ajoutez du caching si approprié, et envisagez de limiter les grosses pièces jointes même si le SMTP peut en accepter davantage.

FAQ

1) If we set our limit to 100 MB, will partners be able to receive 100 MB?

Pas de façon fiable. Beaucoup de domaines distants rejetteront bien avant cela, souvent autour de 10–25 Mo. Votre serveur acceptera, mettra en file, réessaiera, puis renverra un bounce.
Si vous avez besoin d’un transfert garanti, utilisez un mécanisme de partage de fichiers et envoyez un lien.

2) How do I translate “attachment limit” into MTA bytes?

Prévoyez l’overhead base64/MIME. Une règle opérationnelle approximative : multipliez la taille de pièce jointe souhaitée par ~1.35 pour obtenir une cible message_size_limit sûre, puis ajoutez un peu pour les en-têtes et la structure multipart.
Testez avec de vrais types de fichiers et clients ; certains clients gonflent différemment.

3) Should inbound and outbound have the same maximum size?

Non. L’entrée depuis Internet présente un risque plus élevé. La soumission authentifiée présente un risque plus faible mais nécessite quand même des throttles car la compromission de compte est réelle.
Séparez les limites par listener et appliquez des contrôles identitaires pour l’outbound.

4) What’s the biggest operational risk when raising size limits?

L’explosion des files et du stockage lors d’échecs de livraison externes. Les gros messages différés consomment rapidement l’espace spool et augmentent le coût des retries.
Le second plus grand risque est la saturation/timeouts de la couche de filtrage.

5) Why do we see “accepted” but then a bounce later?

L’acceptation SMTP signifie que votre serveur a accepté la responsabilité de la livraison. Cela ne signifie pas que le destinataire l’acceptera.
De plus, des composants en aval (filtres, DLP, magasin) peuvent rejeter après acceptation si leurs limites sont plus basses.

6) Can’t we just increase timeouts so large sends don’t fail?

Vous pouvez, mais faites-le sélectivement. Des timeouts plus longs sur l’entrée anonyme permettent à des sessions lentes de monopoliser des sockets et des ressources.
Privilégiez des timeouts plus larges sur la soumission authentifiée, plus des limites de connexion et de débit.

7) How do we prevent abuse if we allow larger outbound attachments?

Utilisez des throttles par utilisateur et par IP, surveillez les anomalies d’envoi massif, et appliquez des politiques sur les pièces jointes. Assurez-vous que l’authentification est forte (MFA si possible) et que les comptes compromis ne peuvent pas envoyer un volume illimité de gros payloads.

8) What should we monitor specifically after raising limits?

Profondeur de file (active/différée), distribution de taille des éléments en file, usage disque et inodes sur spool/temp, IO wait, timeouts de filtres, et taux de bounce sortant (en particulier 552/5.2.3).
Suivez aussi le volume «accepté puis bounced»—ce sont des échecs coûteux.

9) Is it better to reject large messages at SMTP time or accept and handle later?

Rejetez tôt autant que possible. Le rejet précoce est peu coûteux et honnête. Accepter puis échouer gaspille des ressources et crée de la confusion pour l’utilisateur.
Alignez les limites sur toute la chaîne pour que le premier MTA puisse rejeter avec un message clair.

10) What do we tell users when a recipient rejects big messages?

Donnez-leur une politique qui reconnaît la réalité : «Nous supportons l’envoi jusqu’à X Mo, mais certains destinataires n’acceptent que Y Mo. Utilisez le partage de fichiers approuvé pour les fichiers plus volumineux.»
Si vous ne fournissez pas d’alternative, ils en créeront une, et vous n’allez pas aimer ça.

Conclusion : prochaines étapes pratiques

Augmenter les limites de taille des messages e-mail est facile à faire et étonnamment facile à regretter. La version sûre est délibérée : mesurez les goulets, alignez les limites sur toute la chaîne, ajoutez des contrôles anti-abus, et acceptez que l’internet public ne suivra pas votre note de politique interne.

Prochaines étapes que vous pouvez exécuter cette semaine

• Inventoriez les limites de bout en bout : soumission, MX entrant, proxies, filtres, magasin, quotas.
• Réalisez deux tests contrôlés : un gros message d’un client interne vers une boîte interne ; un vers un domaine externe courant. Suivez les IDs de file jusqu’au statut final.
• Corrigez votre goulot le plus probable : marge/IO du disque spool, timeouts de filtre, ou plafonds non alignés.
• Implémentez des garde-fous avant l’augmentation : limites de débit, contrôles par utilisateur, surveillance de la pression des gros messages.
• Augmentez les limites par paliers et surveillez les métriques comme un adulte surveillant un enfant près d’un escalier ouvert.

Si vous le faites correctement, les utilisateurs arrêtent de se plaindre et vos graphes de file restent ennuyeux. L’ennui est le compliment le plus élevé que peuvent vous adresser des systèmes de production.