Réglage de la livraison par le MTA

Comment un serveur de messagerie sortant décide avec quelle intensité solliciter chaque destination, et comment les opérateurs diagnostiquent et corrigent l’engorgement de la livraison. Les notions ci-dessous valent pour tout MTA ; les modèles de diagnostic des files d’attente, de rétroaction sur la concurrence et d’ordonnancement viennent de la documentation de Postfix, et les modèles de règles d’adaptation du trafic et d’automatisation de celle de KumoMTA. Tout MTA sérieux (commercial ou open source) en implémente une variante. Pour les valeurs concrètes par fournisseur que ces mécanismes appliquent, voir Réglages de référence par fournisseur.

Pourquoi c’est une discipline de la délivrabilité

Les fournisseurs de messagerie imposent par expéditeur des plafonds de connexions, de débit de messages et de messages par connexion, et répondent aux dépassements par des reports de remise 4xx (souvent 421) ou des pénalités de limitation de débit. Un MTA qui dépasse ces limites transforme de bons messages en messages reportés, fait vieillir ses files d’attente et, chez les fournisseurs qui notent les « schémas de trafic inhabituels », abîme la réputation de ses IP. Régler la livraison consiste à maintenir la pression sortante juste sous la tolérance de chaque destination, à ralentir automatiquement lorsque la destination signale une difficulté, et à diagnostiquer vite les anomalies de file d’attente lorsqu’elles apparaissent.

La répartition par âge des files d’attente comme outil de diagnostic (le modèle « qshape »)

La vue la plus informative d’un MTA sortant est un tableau à deux dimensions : le domaine de destination sur un axe, l’âge des messages sur l’autre, avec un décompte dans chaque cellule (Postfix le fournit sous le nom qshape). Les tranches d’âge sont fines pour les messages récents (typiquement 5, 10, 20, 40, 80, 160, 320, 640, 1280 et 1280+ minutes), avec une colonne de total par domaine. Lancez-le séparément sur la file entrante/active (les messages en cours de traitement) et sur la file des messages reportés (ceux qui ont déjà subi un échec temporaire).

Règles de lecture :

1. Les problèmes se trouvent en haut à gauche. De gros décomptes pour un seul domaine dans les tranches récentes signalent un problème actif, en cours. Une concentration dans les tranches anciennes signale un problème passé en train de se résorber.
2. La concentration par domaine désigne le goulet d’étranglement. Triez par total de ligne ; les domaines dominants sont ceux où la livraison échoue ou est limitée.
3. Un arriéré dans la file active est plus grave qu’un arriéré de messages reportés. Les messages bloqués dans la file active empêchent le traitement des nouveaux ; les messages reportés attendent simplement leur prochaine tentative.
4. Une file active pleine alors que la file entrante ne l’est pas signifie qu’une ou plusieurs destinations se vident plus lentement que leur débit d’arrivée.
5. La vue par expéditeur détecte le backscatter : pivoter le même tableau par expéditeur plutôt que par destinataire révèle quand la file est dominée par des messages de rebond (MAILER-DAEMON), c’est-à-dire que la charge vient du traitement de rebonds auto-infligés, pas de nouveaux messages.

Schémas caractéristiques :

Ordres de grandeur (chiffres de Postfix, indicatifs pour tout MTA de type stockage et retransmission) : une file de messages reportés supporte de 100 000 à 1 000 000 de messages environ ; au-delà, de bonnes performances sont peu probables.

Adaptation de la concurrence par destination

Les MTA ouvrent un nombre limité de connexions parallèles par destination et ajustent ce nombre en fonction des résultats de livraison, par analogie délibérée avec le démarrage lent (slow start) de TCP.

• La concurrence initiale est faible (valeur par défaut de Postfix : 5 livraisons simultanées) pour sonder avec douceur une destination nouvelle ou en cours de rétablissement.
• La concurrence maximale plafonne le parallélisme par destination (valeur par défaut de Postfix : 20). Les réglages spécifiques par destination permettent de respecter les plafonds des fournisseurs (par exemple un fournisseur qui ne tolère que 2 connexions).
• La rétroaction positive augmente la concurrence à chaque livraison réussie ; la rétroaction négative la diminue en cas d’échec de connexion ou de négociation. L’incrément de rétroaction est une fonction de la concurrence actuelle N :
  • +1 par succès → montée exponentielle (5→10→20), rapide mais sujette aux oscillations ;
  • +1/N par succès → montée linéaire, un emplacement de plus après N succès, la plus douce ;
  • +1/√N → intermédiaire. Une rétroaction fractionnaire associée à une troncature entière produit une hystérésis naturelle : la concurrence n’augmente d’un cran qu’après 1/g(N) succès consécutifs.
• L’asymétrie compte : la rétroaction négative s’applique dès le début d’une série d’échecs (« hystérésis inverse »), si bien que la surcharge est corrigée immédiatement, et non après toute une fenêtre d’échecs.
• Effet mesuré (tests de l’ordonnanceur de Postfix face à un récepteur qui impose des limites de concurrence par des réponses 421) : une rétroaction fixe de ±1 a reporté environ 50 % des messages ; une rétroaction en 1/N environ 16,5 % ; en 1/√N environ 24,5 %. Une rétroaction plus douce réduit fortement les reports de remise chez les récepteurs qui imposent des limites.
• Réserve : une rétroaction inférieure à 1 a peu d’effet quand le volume vers une destination est faible, car les livraisons sont trop rares pour que les compteurs évoluent.

Détection des sites hors service et mise en pénitence

À distinguer de la rétroaction sur la concurrence : lorsqu’une cohorte entière de tentatives de livraison (N tentatives, N étant la concurrence actuelle) échoue avec des erreurs de connexion ou de négociation, la destination est déclarée hors service après un nombre configurable de cohortes en échec (valeur par défaut de Postfix : 1 cohorte). Les destinations hors service sont mises en pénitence (ignorées complètement pendant une période) au lieu d’être sollicitées sans relâche avec une concurrence de 1. Séparer « le site est hors service » de « le site est lent » permet de garder une rétroaction douce sur la concurrence sans gaspiller des agents de livraison sur des hôtes injoignables.

Adaptation du débit, réutilisation des connexions et vocabulaire des paramètres

Au-delà de la concurrence, les MTA modernes adaptent le trafic par destination selon plusieurs axes indépendants (noms tirés de KumoMTA ; tout MTA a des équivalents) :

La réutilisation des connexions (envoyer de nombreux messages par connexion) est un levier important : l’établissement de la connexion, la négociation TLS et la comptabilité par connexion du récepteur coûtent tous plus cher qu’un MAIL FROM supplémentaire. Mais les fournisseurs plafonnent le nombre de messages par connexion et répondent aux dépassements par des erreurs comme « Max message per connection reached » : la valeur dépend donc du fournisseur (50 pour Gmail, 20 pour Yahoo, 5 pour Apple dans les valeurs de référence de la communauté). Le nombre de destinataires par copie du message est un réglage voisin (valeur par défaut de Postfix : 50 destinataires par copie ; les listes de destinataires plus longues sont réparties en copies parallèles).

Regroupement des destinations (MX rollup) : les limites d’adaptation devraient s’appliquer par infrastructure de réception, pas par domaine de destinataire. Des milliers de domaines hébergés partagent le parc MX de Google ou de Microsoft ; regrouper dans un même compartiment tous les domaines dont les enregistrements MX correspondent à un suffixe (par exemple .google.com/.googlemail.com) évite de multiplier par inadvertance votre nombre effectif de connexions par le nombre de domaines de destinataires. À l’inverse, un fournisseur dont les noms MX correspondent à des silos régionaux (par exemple les noms de sites de Mimecast) devrait être limité par site MX, et non par fournisseur.

Calendrier des nouvelles tentatives et temporisation adaptative sur les 4xx

Les messages en échec temporaire (4xx) reçoivent un horodatage dans le futur avec une temporisation exponentielle entre un plancher et un plafond (valeurs par défaut de Postfix : minimum 300 s, maximum 4 000 s), et la file des messages reportés est réexaminée périodiquement (par défaut toutes les 300 s). Les messages qui ne peuvent pas être livrés pendant la durée de vie en file d’attente (5 jours par défaut ; les rebonds ont souvent leur propre durée, également de 5 jours) sont renvoyés comme échecs permanents.

Règles opérationnelles :

• Ne raccourcissez pas les intervalles entre tentatives pour « vider l’arriéré ». Retenter plus souvent des messages non livrables sature la file active et monopolise les agents de livraison sur des sites hors service, au détriment des messages livrables. Corriger la cause vaut toujours mieux que réessayer plus fort.
• Les délais d’expiration bornent le débit dans le pire des cas. Exemple : 100 agents de livraison, une destination avec 2 hôtes MX dont un est hors service, un délai de connexion de 30 secondes → plafond d’environ 6 messages par seconde, car la moitié des tentatives de connexion consomment un délai complet. Des délais de connexion plus courts (et un passage rapide au MX suivant) rétablissent le débit en cas de panne partielle.
• Isolez les destinations problématiques. Attribuez aux destinations chroniquement lentes ou instables un pool de livraison dédié avec des délais réduits et une concurrence ajustée, ou dirigez-les vers un relais de repli (« cimetière ») avec son propre rythme de tentatives, pour qu’elles ne dégradent pas la livraison principale.

Équité de l’ordonnanceur et préemption

À l’intérieur du MTA, un ordonnanceur décide quel message obtient le prochain emplacement de livraison libre :

• Le tourniquet entre transports et destinations garantit qu’aucune destination ne monopolise les agents de livraison.
• Premier entré, premier sorti au sein d’une destination, selon l’heure d’entrée en file, sauf en cas de préemption.
• La préemption permet aux petits messages de passer devant les envois de masse sans affamer ces derniers : à mesure que les destinataires d’un gros message sont servis, celui-ci accumule des « emplacements de livraison » (un pour K destinataires servis ; coût par défaut de Postfix K=5). Un candidat à la préemption est choisi en maximisant enqueue_time / recipient_count (le plus ancien relativement à sa taille en premier) et doit disposer d’un nombre minimal d’emplacements (3 par défaut). Les prêts d’emplacements (jusqu’à 3 emplacements par défaut, avec une remise de 50 %) permettent à un petit message de passer immédiatement et de « rembourser » l’avance sur les livraisons suivantes : un traitement accéléré pour les messages de taille transactionnelle sans renoncer à l’équité envers les campagnes de masse. C’est l’équivalent, dans le MTA, de la pratique des ESP qui séparent les flux transactionnels et de masse.

Automatisation de l’adaptation du trafic pilotée par les rebonds

Les tables d’adaptation statiques fixent le plafond ; l’automatisation ajuste le trafic en dessous en temps réel, en analysant ce que disent les fournisseurs dans leurs réponses SMTP. Le modèle (Traffic Shaping Automation de KumoMTA, exécuté comme un démon séparé qui surveille les journaux de livraison et renvoie la configuration au MTA, et qui peut fonctionner en grappe pour que tous les nœuds réagissent ensemble) :

• Correspondance : règles d’expressions régulières sur le texte des réponses de rebond ou de report, par fournisseur ou site, par client (tenant) ou par campagne.
• Déclenchement : immédiat, ou seulement au-delà d’un seuil (par exemple 2 correspondances par heure, pour distinguer un cas isolé d’une tendance).
• Action : soit Suspend (arrêter complètement l’envoi vers cette destination depuis cette file), soit SetConfig (resserrer un paramètre d’adaptation : ramener connection_limit à 1, plafonner max_message_rate à 1/minute, réduire max_deliveries_per_connection). Une suspension limitée au client existe pour les réponses qui signalent un problème d’expéditeur (par exemple une authentification absente) plutôt qu’un problème de trafic.
• Expiration : chaque action a une durée (couramment de 15 minutes à 4 heures) ; à son terme, l’adaptation normale reprend automatiquement. La limitation automatique se rétablit ainsi d’elle-même : aucun opérateur n’a besoin de penser à la lever.

Règles représentatives de la communauté (voir Réglages de référence par fournisseur pour le tableau complet) : réponses « unusual rate » de Gmail → plafond de 10 messages/minute pendant 30 minutes ; reports pour plaintes [TSS04] de Yahoo → suspension de 2 heures ; « exceeded the maximum number of connections » d’Outlook → limite de 1 connexion pendant 1 heure ; une règle générique par défaut couvre la famille de textes communs à plusieurs fournisseurs « temporarily deferred / rate limited due to IP reputation / Server busy » et ramène simultanément le débit de messages à 1/minute et les connexions à 1 pendant 90 minutes.

Principes de conception pour écrire vos propres règles :

1. Analysez les mots du fournisseur, pas seulement le code. 421 seul est ambigu ; [TS02], [TS03] et « Max message per connection reached » appellent chacun une réponse différente (voir les articles sur les codes d’erreur des fournisseurs : Gmail, Yahoo, Microsoft).
2. Adaptez l’action au reproche. Reproches sur les connexions → réduire les connexions ; reproches sur le volume → réduire le débit de messages ; reports liés à la réputation ou aux plaintes et inscriptions sur des listes de blocage → suspendre et laisser la réputation retomber ; rejets de contenu → suspendre et alerter un humain (la limitation de débit ne corrigera pas le contenu).
3. Ralentissez davantage pour les signaux de réputation que pour les limites mécaniques. Atteindre un plafond de connexions est une erreur de réglage ; « deferred due to user complaints » est un événement de réputation.
4. Gardez des durées courtes et laissez les règles se redéclencher. Une pénalité de 30 à 120 minutes qui se renouvelle tant que le fournisseur continue de se plaindre converge vers le bon débit sans paralyser durablement la file d’attente.

Organiser la configuration d’adaptation en couches

Conservez les données d’adaptation en couches pour que les mises à jour ne détruisent pas les connaissances locales : une couche éditeur ou par défaut, une couche communautaire ou partagée, et une couche locale avec vos propres règles, les couches ultérieures prenant le pas sur les précédentes (avec une échappatoire explicite « tout remplacer pour ce domaine »). Ne modifiez jamais directement les couches distribuées : elles sont écrasées lors des mises à niveau. La plupart des déploiements ont besoin de règles locales : les valeurs de référence partagées ne prétendent volontairement pas tout couvrir.

Voir aussi

• Réglages de référence par fournisseur : des valeurs de départ concrètes, maintenues par la communauté, pour chaque fournisseur.
• Recommandations pour la chauffe d’IP : la politique de montée en charge que ces mécanismes appliquent.
• Codes d’état étendus : le vocabulaire de codes qu’analysent les règles d’automatisation.
• Erreurs SMTP de Gmail et dépannage · Codes d’erreur SMTP de Yahoo · Comcast/Xfinity : les catalogues de réponses des fournisseurs.