Message-Id invalide selon RFC 2822 + encoding

Bonjour,

Je remonte deux problèmes relatifs aux emails envoyés.

Message-Id Invalide

Suite à une analyse avec https://www.mail-tester.com/,
Il semblerait que le ‘Message-Id’ ne soit pas valide.

L’erreur mail-tester est :
INVALID_MSGID Message-Id is not valid, according to RFC 2822

Voici l’en-tête “Message-Id” selon mail-tester :

Message-Id: =?utf-8?q?=3C165306032961=2E3393=2E9803830538757387937=2EKyW?=
 =?utf-8?q?aOn82WZ=40www=2Eatelierdusoleiletduvent=2Eorg=3E?=

Peut-être un problème d’encodage ou de définition d’encodage ?

En effet, dans le “Journal des Emails” sous Dokos, le Message-Id est :
Message-Id: <165306032961.3393.9803830538757387937.KyWaOn82WZ@www.atelierdusoleiletduvent.org>

Avez-vous le même problème ?
Faut-il définir le type d’encodage des en-têtes du mail ?

Encodage du champ ‘sujet’

Aussi, j’ai une erreur sur l’encodage du champ sujet qui était “Bon de réservation”
Détails mail-tester :

-0.1 SUBJECT_NEEDS_ENCODING Subject is encoded but does not specify the encoding
-1.105 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters

1 Like

Bonjour,

Merci d’avoir fait remonter ce problème.

Il semblerait que la politique d’encodage des e-mails utilisée par Dokos, SMTPUTF8, ne convertit pas les charactères non-ASCII à l’intérieur des headers. Voilà l’explication pour l’erreur de Subject. Néanmoins, je n’ai pas réussi à reproduire le problème du Message-Id, qui n’est pas censé être encodé en Quoted-Printable peu importe son contenu, ni même découpé en plusieurs lignes (bien que cela soit autorisé).1

Apparemment, d’après le test que vous avez effectué, c’est SpamAssassin qui donne un mauvais score au mail pour deux raisons : le Message-Id ne devrait pas être encodé (même en Quoted-Printable), et le header Subject ne devrait pas contenir de caractères non-ASCII.

Une correction qui vise à changer la politique d’encodage vers SMTP, donc qui permettra d’améliorer le score SpamAssassin des mails envoyés par Dokos, est disponible ici : dokos/dodock #14.


1. Il me semble que l’usage des caractères non-ASCII dans les headers est parfois autorisé, sinon il peut se faire par des encodages comme Base64 ou Quoted-Printable.[RFC 6531, RFC 6532, SpamAssassin, rspamd]

2 Likes

Bonjour Corentin,

Au top, merci pour ces détails précis !
Le lien vers la demande de fusion ne fonctionne pas / plus mais j’ai retrouvé le commit via le graph du repo.

Je vois deux solutions :

  • (a) j’essaie d’appliquer les changements avec un patch sur mon instance dokos
  • (b) j’attend qu’une demande de fusion soit intégrée à la branche master de dodock

@chdecultot un avis ou un timing pour intégrer le commit de @corentin ?

Belle fin de journée,

Bonjour @guillaume.augais,

Je n’avais pas vu que les MR n’étaient pas accessibles à tous sur Gitlab, c’est corrigé.

J’ai fait plusieurs tests avec des passerelles SMTP différentes et je n’ai pas réussi à reproduire le problème d’encodage pour le Message-Id.
Du coup, serait-il possible de connaître la passerelle SMTP que vous utilisez ?

Je voudrais m’assurer que le problème vient bien de l’encodage de Dokos et pas de la passerelle sous-jacente.

Part contre j’ai bien la même erreur pour le sujet, donc il faut qu’on corrige.

J’essaye de m’en occuper cette semaine.

Bien reçu pour la visibilité des MR, merci.

La passerelle sous-jacente est Gandi et le DKIM est activé sur la boite mail d’envoi qui est bonjour@atelierdusoleiletduvent.org.

Voici la configuration du domaine sous Dokos :

  • IMAP en SSL sur le port 993 (pas pertinent à priori)
  • SMTP en SSL sans TLS sur le port 465

Si cela peut aider, voici le lien vers l’analyse mail-tester : Spam Test Result
L’email a été envoyé depuis le bouton “Nouvel Email” du pied de page d’une commande client Dokos.

Suite à vos remarques je constate que dans le “Journal des emails”, le Message-Id semble formatté correctement… C’est à dire avec les caractères ‘<’ et ‘>’ au lieu de ‘=?utf-8?q?=3C’ et ‘=3E?=’

=> Voir cet export du contenu source, extrait du champ “Message” après sélection de l’email en question dans le “Journal des emails” : Re: Guillaume AUGAIS (#CMD-VT-2022-00087)

Je viens de faire plusieurs tests :

  • client Thunderbird / compte Gandi sans DKIM : pas de pb de Message-Id (mail-tester donne 9/10 car pas de DKIM)
  • client Thunderbird / compte Gandi avec DKIM : pas de pb de Message-Id (mail-tester donne 10/10)

Ce qui metterait hors de cause Gandi, ou l’activation du DKIM…
J’ai aussi vérifié en modifiant la config SMTP Dokos : passer de 465 (avec SSL) à 587 (avec TLS) n’a rien changé à l’allure du ‘Message-Id’ reçu par mail-tester

Comparaison des en-têtes Dokos / Thunderbird

Avec un envoi de mail Dokos,
le formattage des en-têtes est le suivant :

Content-Type: multipart/mixed; boundary="===============8978091418656974850=="
MIME-Version: 1.0
Message-Id: 165402808017.3389.2808957330285164207.v2NW1ExiIU@www.atelierdusoleiletduvent.org
X-Original-From: Guillaume AUGAIS bonjour@atelierdusoleiletduvent.org
Subject: Re: Guillaume AUGAIS (#CMD-VT-2022-00087)
From: Atelier du Soleil et du Vent bonjour@atelierdusoleiletduvent.org
To: test-6gci2kqob@srv1.mail-tester.com
Date: Tue, 31 May 2022 20:14:43 -0000

Alors que via Thunderbird, j’ai :

Content-Type: multipart/alternative;
boundary="------------WolpAFcc0rwpqED1z0ClrKkw"
Message-ID: 16fe9764-36c5-9a01-0b3d-c14c427cafba@mondomainetest.fr
Date: Tue, 31 May 2022 22:37:27 +0200
MIME-Version: 1.0

Plusieurs remarques :

  • (1) le champs boundary est sur une ligne nouvelle dans Thunderbird
  • (2) l’en-tête ‘MIME-Version’ est intercalée entre ‘Content-Type’ et ‘Message-Id’ après (mais cela ne devrait pas avoir d’incidence j’imagine)

Est-ce que (1) peut avoir une influence ?

En espérant que ces nouveaux éléments aident à mieux comprendre le problème.
Si vous voyez d’autres tests à réaliser, dites-moi.

Bonjour @guillaume.augais,

Après analyse approfondie du problème, nous allons publier ce soir un correctif pour changer la politique d’encodage des emails (merci @corentin). J’ai fait un certain nombre de tests sans constater de problème à la réception.
Ca devrait résoudre le problème d’encodage du sujet.

On ajoutera le header List-Unsubscribe dans la v3, parce qu’il y a quelques problèmes avec la longueur de l’URL qu’il faut régler d’abord.

Par contre je n’ai pas réussit à reproduire le problème du message-id, malgré tous mes tests. Mail-tester donne bien une note de 9/10 à tous les emails de test (le 1/10 étant lié à l’absence de DKIM).

Merci beaucoup pour votre aide !