Que faire en cas d’erreur d’e-mail non ASCII dans Python 3.15.2 ?

Le message échoue à la création, ou le serveur SMTP refuse une adresse internationale : ces symptômes ne désignent pas forcément le même problème.

Réponse rapide : dans Python 3.15.2, commencez par repérer si l’exception survient pendant la sérialisation de l’en-tête ou pendant l’envoi. Le générateur peut refuser de mettre à plat un en-tête contenant une adresse non ASCII qu’il ne sait pas représenter correctement ; cela ne signifie pas que toutes les adresses internationales sont inutilisables. Vérifiez ensuite la stratégie de message, la prise en charge de SMTPUTF8 par le serveur et, enfin, la réception effective dans une boîte contrôlée.

Cet article s’adresse aux développeurs qui exécutent Python 3.15.x et rencontrent une erreur de sérialisation d’adresse.
Il concerne aussi les équipes QA qui testent, pour leur propre produit, la génération et la réception d’e-mails internationaux.
Les personnes responsables d’un relais SMTP y trouveront une façon de distinguer une erreur de génération, un refus du serveur et un échec de réception.

Dernière vérification : 1 novembre 2026, à partir de la documentation Python 3.15, de la page de publication de Python 3.15.2 et des documentations officielles de email et smtplib.

Erreur d’e-mail non ASCII dans Python 3.15.2 : identifier l’étape fautive

Le premier diagnostic consiste à repérer l’opération exacte qui échoue. Une ligne de journal contenant tout le message ne suffit pas : elle peut afficher ensemble un nom d’expéditeur accentué, une adresse ASCII et une adresse dont la partie locale contient des caractères non ASCII. Ces éléments n’ont pas les mêmes exigences.

Dans Python 3.15, la documentation indique que le générateur de messages peut lever une erreur s’il ne peut pas mettre à plat correctement un en-tête qui contient une adresse e-mail non ASCII. La limite annoncée porte sur la représentation de l’adresse dans l’en-tête ; elle ne permet pas de conclure que tout texte accentué dans le corps du message pose problème. Elle ne permet pas non plus d’affirmer que toute adresse internationale échouera, quels que soient la stratégie et le serveur utilisés. Le comportement de la version 3.15.2 doit être vérifié avec le cas concret et la documentation de cette version, plutôt que déduit d’un message d’erreur isolé.

La publication officielle confirme que Python 3.15.2 est sortie le 25 octobre 2026. Cette date identifie la version à tester, mais ne prouve pas à elle seule qu’un problème particulier a été corrigé dans cette mise à jour : il faut consulter la page officielle de Python 3.15.2 et reproduire le défaut avec les dépendances réellement déployées.

Pour conserver une preuve utile, notez le type d’adresse testé, la stratégie appliquée au message, l’appel qui déclenche l’exception et le texte de l’erreur. Gardez également un exemple minimal reproductible. Retirez les identifiants, les adresses personnelles et tout contenu client avant de partager ce cas.

Le nom affiché est international, mais l’adresse reste ASCII

Un nom affiché comme Équipe produit et une adresse comme qa@example.test sont deux composants différents. Le premier peut nécessiter un encodage adapté dans l’en-tête ; le second ne contient que des caractères ASCII. Une troisième situation apparaît lorsque l’adresse elle-même contient des caractères non ASCII, par exemple dans sa partie locale. Cette différence est déterminante pour le diagnostic.

Testez d’abord un nom affiché international avec une adresse ASCII. Sérialisez ensuite le message et examinez l’en-tête obtenu, en particulier les champs From et To. Si l’en-tête produit un nom encodé mais que l’adresse reste ASCII, l’erreur ne doit pas être attribuée automatiquement à une adresse EAI. À l’inverse, si l’adresse comporte des caractères non ASCII, consignez-la comme telle et comparez le résultat avec un cas témoin entièrement ASCII.

L’inspection doit porter sur les champs concernés et sur l’exception levée au moment précis de l’opération. Une représentation textuelle complète peut être trompeuse : elle mélange le corps, les noms affichés et les adresses, alors que le générateur traite ces parties selon des règles différentes. En cas d’échec, réduisez le message à un expéditeur, un destinataire et un sujet, puis réintroduisez séparément le nom affiché et l’adresse internationale.

Adresse EAI : examiner la stratégie avant l’envoi

Une adresse EAI comporte des caractères non ASCII dans l’adresse elle-même. Elle ne se valide pas comme une adresse traditionnelle entièrement ASCII en se contentant de vérifier que le champ ressemble à une chaîne bien formée. Le parseur utilisé par l’application, la construction de l’objet message, la sérialisation et le serveur distant forment plusieurs étapes distinctes. La réussite de l’une ne garantit pas celle des autres.

La documentation Python associe la prise en charge des en-têtes internationaux à l’option EmailPolicy.utf8. La stratégie email.policy.SMTPUTF8 est la variante SMTP avec cette option activée. Il faut donc comparer, dans le contexte de l’application, une sérialisation avec la stratégie prévue et le comportement de la stratégie par défaut. Consultez la documentation officielle de email.policy : elle décrit les stratégies et les paramètres qui déterminent la représentation du message.

Voici un test minimal pour isoler la sérialisation. Les adresses de domaine .test sont des valeurs d’exemple ; elles ne doivent pas être utilisées comme destinataires réels.

from email.message import EmailMessage
from email.policy import SMTPUTF8

message = EmailMessage(policy=SMTPUTF8)
message["From"] = "Équipe <sender@example.test>"
message["To"] = "δοκιμή@example.test"
message["Subject"] = "Essai d’adresse internationale"
message.set_content("Message de contrôle.")

try:
    contenu = message.as_bytes()
except (TypeError, ValueError, UnicodeError) as exc:
    print(type(exc).__name__, str(exc))
else:
    print(contenu.decode("utf-8", errors="replace"))

Ce test ne démontre pas que le message peut être transmis ni reçu. Il vérifie seulement que le message construit peut être sérialisé avec la stratégie choisie dans cet environnement. Si l’exception apparaît dès l’affectation d’un champ, conservez aussi cette étape dans le diagnostic : l’échec ne se situe alors pas nécessairement dans as_bytes().

Les options d’internationalisation ne doivent pas être confondues avec une garantie de compatibilité universelle. Le protocole SMTPUTF8 est défini dans la spécification RFC 6531, mais l’application doit toujours tenir compte des capacités annoncées par le serveur et des règles des systèmes destinataires. Une boîte temporaire, une boîte de test ou une adresse créée pour les essais ne prouve pas à elle seule qu’une partie locale internationale est prise en charge. Vérifiez cette capacité explicitement.

La sérialisation réussit, mais le serveur SMTP ne prend pas SMTPUTF8 en charge

Un message qui se sérialise sans exception peut encore être refusé lors de l’envoi. Avec smtplib.SMTP.send_message, Python examine les adresses d’enveloppe. Si une adresse nécessite SMTPUTF8, la méthode demande cette extension au serveur. Lorsque celui-ci ne l’annonce pas parmi ses capacités, l’envoi peut échouer avec SMTPNotSupportedError. Les règles précises de négociation et les exceptions sont décrites dans la documentation officielle de smtplib.

Le contrôle utile consiste à séparer les résultats :

• Échec de génération : l’objet message ou un champ ne peut pas être construit correctement.
• Échec de sérialisation : la conversion du message en octets déclenche une exception.
• Capacité SMTP absente : le serveur ne propose pas l’extension requise pour l’adresse concernée.
• Demande acceptée par le serveur : la transaction SMTP se termine sans refus à ce stade.
• Réception non vérifiée : aucun élément ne prouve encore que le message est visible dans la boîte attendue.

Pour reproduire l’envoi dans un environnement autorisé, consignez les capacités retournées par le serveur après la connexion, le type d’exception ou le code de réponse, ainsi que les adresses d’enveloppe effectivement utilisées. Ne publiez pas les secrets de connexion ni les réponses contenant des données sensibles. L’API send_message prend en charge la négociation décrite par la documentation, mais son succès signifie que le serveur a accepté la demande selon le protocole ; il ne constitue pas un reçu de livraison dans la boîte finale.

La stratégie du message doit correspondre aux exigences de l’adresse. La documentation de email.message.EmailMessage décrit la création et la sérialisation des objets message. Évitez de contourner une erreur en convertissant arbitrairement l’adresse en chaîne, en remplaçant ses caractères ou en envoyant des octets construits à la main : une telle manipulation peut rendre le test différent du comportement de production sans résoudre l’incompatibilité du serveur.

Choisir le test selon l’adresse et le résultat recherché

Le tableau suivant aide à choisir le contrôle utile. Il distingue le composant modifié et la preuve obtenue ; il ne promet pas qu’un seul test couvre toute la chaîne.

En pratique, la meilleure comparaison utilise deux messages dont le contenu est identique : l’un avec une adresse ASCII de contrôle, l’autre avec l’adresse internationale à tester. Gardez la même stratégie, le même serveur, le même expéditeur et le même destinataire contrôlé lorsque cela est possible. Si plusieurs paramètres changent ensemble, il devient difficile d’identifier la cause d’une différence.

Procédure de validation dans un environnement maîtrisé

Pour tester le produit de l’équipe ou un environnement pour lequel une autorisation a été obtenue, procédez par étapes et associez chaque observation au même identifiant de test.

1. Définissez le cas. Indiquez si les caractères non ASCII se trouvent dans le nom affiché, dans l’adresse elle-même ou dans les deux. Utilisez des adresses de test dont l’équipe maîtrise la réception.
2. Conservez un cas témoin ASCII. Utilisez le même modèle de message avec une adresse entièrement ASCII. Ce contrôle permet de séparer un défaut général de construction d’un problème lié à l’internationalisation.
3. Testez la construction et la sérialisation. Consignez la stratégie, l’opération qui échoue, la classe d’exception et l’en-tête produit. Ne copiez pas de données personnelles dans les journaux.
4. Vérifiez les capacités du serveur. Relevez les extensions annoncées, puis notez si smtplib.SMTP.send_message réussit ou lève une exception. Gardez la réponse du serveur sans y joindre les identifiants de connexion.
5. Contrôlez la réception réelle. Ouvrez la boîte de réception autorisée et recherchez le message de contrôle. Vérifiez l’adresse destinataire, le sujet, l’expéditeur et les en-têtes pertinents ; une réponse SMTP favorable ne remplace pas cette vérification.
6. Reliez les preuves. Attribuez un identifiant au test et associez-lui le type d’adresse, la stratégie de message, l’exception ou la réponse SMTP et le résultat observé dans la boîte.
7. Répétez dans les conditions utiles. Si la production emploie un autre serveur, une autre politique ou un autre chemin d’envoi, reproduisez le cas dans cet environnement autorisé avant de conclure sur la compatibilité.

Cette méthode évite notamment de confondre « le code a créé un message », « le serveur a accepté la transaction » et « le destinataire a effectivement reçu le message ». Elle améliore aussi la qualité des rapports de bogue : un développeur peut reproduire une erreur de sérialisation sans avoir à deviner si le message a été envoyé ou si la boîte de réception a été consultée.

La protection des données doit faire partie du montage de test. Les environnements de préproduction n’ont généralement pas besoin de vraies adresses personnelles pour valider le chemin technique. Réduisez les données présentes dans les en-têtes et les corps, limitez l’accès aux journaux et vérifiez les règles de conservation applicables au projet. La politique de confidentialité de MXTemp peut aider à examiner les questions de traitement liées à un service de réception. Avant d’y déposer des messages de test, vérifiez également les conditions d’utilisation de MXTemp et les règles internes applicables ; ces documents ne remplacent pas l’évaluation de conformité propre à l’organisation.

Décider de la correction sans généraliser le résultat

Si l’adresse est ASCII et que seul son nom affiché contient des caractères internationaux, examinez d’abord l’en-tête généré et la stratégie appliquée aux noms affichés. Ne modifiez pas la partie locale de l’adresse pour résoudre un problème qui se situe ailleurs.

Si la partie locale est internationale, vérifiez que le message est construit avec la stratégie appropriée, que la version réellement exécutée correspond à celle testée et que le serveur d’envoi annonce la capacité nécessaire. Un ajustement de EmailPolicy.utf8 peut concerner la représentation du message ; il ne transforme pas un serveur SMTP incompatible en relais prenant en charge SMTPUTF8.

Si le serveur n’annonce pas l’extension, le choix dépend du service d’envoi réellement utilisé et des exigences du produit. Il peut être nécessaire de sélectionner un chemin d’envoi compatible ou de traiter explicitement l’adresse comme non prise en charge par ce chemin. La décision doit être prise à partir de la documentation du service et d’un test autorisé, pas d’une supposition tirée de la seule réussite de as_bytes().

Enfin, formulez la conclusion à la mesure de la preuve : version de Python testée, type d’adresse, stratégie de message, serveur et résultat de réception. Par exemple, « le cas de nom affiché non ASCII est sérialisé dans cet environnement » est une conclusion vérifiable. « Python prend en charge toutes les adresses internationales » ne l’est pas si la chaîne complète, du code à la boîte de réception, n’a pas été testée.

Lorsqu’il faut vérifier la réception d’un message généré par le produit, une boîte contrôlée peut compléter les tests de sérialisation et de négociation SMTP. MXTemp peut être envisagé comme une option de réception pour les essais autorisés, sans présumer de sa compatibilité avec les adresses EAI ni d’une livraison garantie. Pour un test ponctuel, l’intérêt est de séparer cette vérification de la boîte principale ; pour un compte important, un échange nécessitant une réponse ou une adresse à conserver durablement, une boîte maîtrisée par l’équipe reste préférable.