Réglage de la livraison par le MTA

Si vos files d’attente sortantes grossissent ou si les fournisseurs reportent vos messages, la cause tient souvent à l’intensité avec laquelle votre serveur de messagerie sollicite chaque destination. Le réglage de la livraison couvre la façon dont un agent de transfert de courrier (MTA) décide de cette pression, et la façon dont 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 viennent 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 et fait vieillir ses files d’attente. Chez les fournisseurs qui notent les « schémas de trafic inhabituels », il abîme aussi la réputation de ses adresses 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 problèmes de file d’attente lorsqu’ils 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, avec le domaine de destination sur un axe et l’âge des messages sur l’autre, et un décompte dans chaque cellule. Postfix fournit cette vue 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-la séparément sur les files entrante et 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 sur un 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 compte plus qu’un arriéré dans la file des messages reportés. Les messages bloqués dans la file active empêchent le traitement des nouveaux, tandis que les messages reportés attendent seulement 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 les messages n’arrivent pour elles.
5. Une vue par expéditeur détecte le backscatter. Pivoter le même tableau par expéditeur plutôt que par destinataire montre quand la file est dominée par des messages de rebond (MAILER-DAEMON), ce qui signifie 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, et de bonnes performances sont peu probables au-delà.

Adaptation de la concurrence par destination

Les MTA ouvrent un nombre limité de connexions parallèles vers chaque destination, et ajustent ce nombre en fonction des résultats de livraison. Ce mécanisme ressemble délibérément au démarrage lent (slow start) de TCP.

• La concurrence initiale est faible (valeur par défaut de Postfix : 5 livraisons simultanées), afin de sonder avec douceur une destination nouvelle ou en cours de rétablissement.
• La concurrence maximale plafonne le parallélisme pour chaque destination (valeur par défaut de Postfix : 20). Les réglages propres à une destination permettent de respecter les plafonds des fournisseurs, par exemple pour un fournisseur qui ne tolère que 2 connexions.
• La rétroaction positive augmente la concurrence après des livraisons réussies, et la rétroaction négative la diminue après des échecs de connexion ou de négociation. L’incrément de rétroaction est une fonction de la concurrence actuelle N :
  • +1 par succès donne une montée exponentielle (5, puis 10, puis 20) : rapide, mais sujette aux oscillations ;
  • +1/N par succès donne une montée linéaire, un emplacement de plus après N succès : la plus douce ;
  • +1/√N se situe entre les deux. 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 »), afin que la surcharge soit corrigée immédiatement, et non après toute une fenêtre d’échecs.
• Effet mesuré (tests de l’ordonnanceur de Postfix face à un serveur de réception 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 serveurs de réception 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

Ce mécanisme est distinct 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 : elles sont complètement ignorées 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 vers chaque destination selon plusieurs axes indépendants (les noms viennent de KumoMTA, et tout MTA a des équivalents) :

La réutilisation des connexions (envoyer de nombreux messages par une seule connexion) est un levier important. L’établissement d’une connexion, la négociation TLS et la comptabilité par connexion du serveur de réception 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 », donc la bonne valeur dépend du fournisseur (50 pour Gmail, 20 pour Yahoo, 5 pour Apple dans les valeurs de référence de la communauté). Un réglage voisin est le nombre de destinataires par copie d’un message (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 à chaque infrastructure de réception, et non à chaque 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 d’adaptation tous les domaines dont les enregistrements MX correspondent à un suffixe (par exemple .google.com ou .googlemail.com) vous é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, ce qui prive les messages livrables de ressources. Corriger la cause fonctionne toujours mieux que réessayer plus fort.
• Les délais d’expiration bornent le débit dans le pire des cas. Par exemple, avec 100 agents de livraison, une destination qui a 2 hôtes MX dont un est hors service, et un délai de connexion de 30 secondes, le débit plafonne à 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 pendant une 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, afin qu’elles ne puissent pas dégrader 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 (FIFO) 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 priver ces derniers de ressources. À 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. Cela accélère 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 fournisseurs de services de messagerie (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, et 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 est la Traffic Shaping Automation de KumoMTA, qui fonctionne comme un démon séparé : il surveille les journaux de livraison et renvoie la configuration au MTA. Il peut fonctionner en grappe, afin que tous les nœuds réagissent ensemble :

• Correspondance : des règles d’expressions régulières sur le texte des réponses de rebond et de report, limitées à un fournisseur ou un site, à un client (tenant) ou à une campagne.
• Déclenchement : immédiat, ou seulement au-delà d’un seuil (par exemple 2 correspondances par heure, ce qui distingue 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 par minute, réduire max_deliveries_per_connection). Une suspension limitée à un 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 par 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 vus chez plusieurs fournisseurs, comme « temporarily deferred », « rate limited due to IP reputation » et « Server busy », et ramène à la fois le débit de messages à 1 par 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, tandis que [TS02], [TS03] et « Max message per connection reached » appellent chacun une réponse différente (voir les guides des codes d’erreur de Gmail, de Yahoo et de Microsoft).
2. Adaptez l’action au reproche. Pour les reproches sur les connexions, réduisez les connexions. Pour les reproches sur le volume, réduisez le débit de messages. Pour les reports liés à la réputation ou aux plaintes, et pour les inscriptions sur des listes de blocage, suspendez et laissez la réputation retomber. Pour les rejets de contenu, suspendez et alertez une personne, car 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, afin 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 prennent le pas sur les précédentes, avec une option explicite pour « tout remplacer pour ce domaine ». Ne modifiez jamais directement les couches distribuées, car les mises à niveau les écrasent. La plupart des déploiements ont besoin de règles locales, car 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, avec des valeurs de départ 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