Cinq nouveaux contrôles de délivrabilité dans PowerMTA 4.5

PowerMTA (PMTA Version 4.5) a toujours mis l’accent sur «envoyer des emails et le faire correctement». Cela peut sembler être une tâche simple. C’est en fait plus compliquée qu’il n’y paraît en fonction des volumes et du comportement différencié des systèmes récepteurs.

La version 4.5 de PowerMTA de Port25 apporte de nombreuses améliorations et de nouvelles fonctionnalités. Des modifications ont été apportées à la configuration, à l’envoi, à la comptabilité et à l’interface Web. Cet article présente cinq nouvelles fonctionnalités qui se concentrent sur l’objectif de base de PowerMTA: l’envoi de courriers électroniques. Nous allons détailler pourquoi et comment ces fonctionnalités améliorent la délivrabilité.

Bounces pour les domaines sans MX

Afin d’éviter des tentatives inutiles vers des domaines mal orthographiés qui existent mais qui n’acceptent pas d’emails, PMTA était déjà capable des de générer des bounces pour les messages vers des domains pour lesquels il n’existe pas d’enregistrement MX. Par exemple, bien que le domaine hotmial.com existe et qu’il résolve vers une adresse IP, il ne publie pas d’enregistrement MX. Lorsqu’on envoie vers ce domaine, chaque tentative aboutit à un timeout. Cependant, il peut être risqué de considérer ces timeouts comme des bounces immédiatement. La norme SMTP stipule que sans enregistrement MX, les MTAs doivent supposer que le domaine est l’hôte à contacter, et parfois c’est bien le cas.

PowerMTA 4.5 peut effectuer les lookup A requis pendant une courte période, par exemple une heure, puis renvoyer les mails en erreur si des enregistrements MX sont manquants. Cela permettra d’éviter des queues pleines de domaines mal orthographiés tout en délivrant occasionnellement des messages vers certains hôtes sans MX.

Augmentation des intervalles de re-tentative

Les re-tentatives d’envoi des messages étaient précédemment effectuées à intervalles réguliers. Cela signifie qu’avec un intervalle de retry de 10 minutes, 144 tentatives étaient effectuées en 24 heures. Cet intervalle peut maintenant être modifié après chaque tentative. Cela permet d’utiliser des intervalles de plus en plus longs et d’éviter des tentatives inutiles, car la probabilité que le message aboutisse diminue avec le temps. Par exemple, la séquence suivante peut être utilisée pour les cinq premières tentatives: 5m, 10m, 15m, 30m, 1h. Le dernier intervalle spécifié sera utilisé pour les tentatives suivantes jusqu’à l’expiration du message.

Rebonds sur des réponses 4XX spécifiques

Certains fournisseurs renvoient des réponses SMTP avec un code 4XX lorsqu’une boîte aux lettres est pleine, le compte est inactif ou même lorsque l’adresse n’existe pas. Par exemple, Google renvoie: 

452 4.2.2 The email account that you tried to reach is over quota. Please ...

La norme SMTP indique que les messages avec un code d’état 4XX doivent être retentés. Mais en pratique, ces mails resteront en file d’attente jusqu’à l’expiration du message. Il est peu probable qu’un destinataire ayant 15 Go de stockage du courrier soit encore actif. Avec la version 4.5, il est possible de configurer des ‘reply patterns’ qui généreront un bounce au lieu d’une nouvelle tentative.

Limitation du nombre de connexions par IP de destination

PowerMTA est depuis longtemps capable de limiter le nombre de connexions simultanées par domaine et par MX. PowerMTA 4.5 peut maintenant limiter ce nombre de connexions simultanées par IP de destination. C’est utile pour un fournisseur comme Aruba, qui héberge de nombreux domaines, chacun ayant son propre MX, mais qui pointent tous vers les mêmes adresses IP. Avec des limites de connexion par domaine ou par MX, cela peut entraîner l’erreur suivante:

421 ... Too many connections, try later.

En limitant le nombre de connexions aux adresses IP d’Aruba, ces erreurs peuvent être évitées.

Rollup queues basées sur les enregistrements MX 

PowerMTA utilise différentes queues pour chaque domaine destinataire. Cela permet une grande concurrence des envois et les problèmes vers un domaine n’affectent pas la délivrabilité vers un autre. Toutefois, les problèmes de diffusion se situent souvent au niveau d’un fournisseur et peuvent affecter tous les domaines destinataires hébergés par ce fournisseur. Prenez, par exemple, cette erreur commune chez Hotmail:

421 … We have limits for how many messages can be sent per hour and per day ...

Pour définir des limites au niveau d’un fournisseur, vous pouvez cumuler ses domaines dans une seule queue. Mais il s’agit alors d’une liste statique de domaines et la recherche MX n’est effectuée que sur l’un des domaines de la liste. Si un domaine passe chez un autre fournisseur, PMTA pourra tenter d’envoyer vers le mauvais MX. Dans le passé, Yahoo a déjà transféré des domaines vers un autre fournisseur. En outre, pour des fournisseurs hébergeant de nombreux domaines inhabituels, la liste ne serait jamais complète.

La version 4.5 propose une meilleure solution. PowerMTA est maintenant capable de regrouper des messages dans des queues en fonction des enregistrements MX de chaque domaine. Si les enregistrements MX correspondent à une liste configurée d’hôtes MX, les domaines en question seront placés dans une même ‘rollup queue’.

En plus de pouvoir appliquer des limites par fournisseur, le regroupement (rollup) peut être plus efficace pour certains fournisseurs. Pour des fournisseurs tels que Google Suite, de petites files d’attente pour différents domaines peuvent être combinées et envoyées via une seule connexion plutôt que via des connexions individuelles pour chaque domaine.

Plus d’information?
Si vous souhaitez en savoir plus, envoyez-nous simplement un message via notre page de contact.

Share this

Les commentaires sont fermés.

Vous trouverez ci-dessous une liste d’articles tout aussi intéressants classés par catégorie.