PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WEBDEV 2025 → Forcer dans les email le Content-Transfer-Encoding à Quoted-Printable
Forcer dans les email le Content-Transfer-Encoding à Quoted-Printable
Débuté par jeff, 01 avr. 2020 10:27 - 3 réponses
Posté le 01 avril 2020 - 10:27
Bonjour,

Lorsque je prépare un message avec le type Email, je l'envoie avec : EmailEnvoieMessage(MaSession,MonMessage,emailOptionEncodeEntête). Dans l'entête on a : Content-Transfer-Encoding:8bit.

Je souhaite avoir un en-tête Content-Transfer-Encoding: Quoted-Printable.

Nos fournisseurs SMTP (Mailjet et Mailgun) nous indique que l'en-tête 8bit n'est pas toujours correctement interprété par les systèmes qui vérifient le DKIM ou DMARC (et effectivement on le voit dans les emails que l'on s'envoie, on a pas mal de false alors que tout est ok). Cela joue donc sur la délivrabilité.

Est-ce qu'il y a une manière de forcer cet en-tête en jouant sur les paramètres de la structure Email ?

Merci.

Jeff.
Posté le 10 avril 2020 - 19:06
Bonjour,

Je fais un petit up du sujet.

La doc d'envoi d'email dit :
emailOptionEncodeEntête : Encode les entêtes du message en Quoted-Printable si nécessaire.

Mais je ne suis jamais arrivé à avoir cet encodage. Peut-être faut-il formater le message d'une certaine manière pour qu'il "décide" de mettre en Quoted-Printable ?

Que cette option soit utilisée ou pas tout les emails partent avec Content-Transfer-Encoding:8bit.

Merci.

Jeff.
Posté le 23 avril 2020 - 11:43
Bonjour,

Après des investigations pour ceux que cela intéresse.

L'envoi via EmailEnvoieMessage (avec l'option emailOptionEncodeEntête), se fait en positionnant le Content-Transfer-Encoding du texte et du texte HML à 8bits (s'il y a des caractères accentués). Le problème avec ce type de transfert, et qu'il faut d'après le protocole utiliser des lignes de 1000 caractères maximum (une ligne se termine par CR). Donc selon les messageries (ce n'est pas toujours le cas), le contenu du message est découpé automatiquement en ligne de 1000 caractères. Je ne sais pas à quel niveau cela se passe, je pense que c'est le serveur d'envoi SMTP (dans mon cas Mailjet et Maigun). Ce découpage automatique a 2 conséquences que j'ai expérimentées :
- Les liens du message peuvent devenir inopérants (essayer une série de liens <ul><li>.... non séparés par des CR et le lien situé au 1000ème caractère est inactif dans ce cas)
- Le test DKIM échoue

La solution consiste a découper MonMessage.message MonMessage.HTML en ligne maximum de 1000 caractères séparées par des CR, avant l'envoi.

La messagerie n'ayant pas besoin de "découper", le message passe tel quel et les 2 pb évoqués ci-dessus disparaissent.

Jeff.
Posté le 11 septembre 2022 - 23:53
Bonjour,

Je rencontre exactement le même probleme.
Une partie des fichiers pdf sont recu corrompu qu'alors à l'expédition ils sont en bon état.

En controlant via un testeur de mail, j'ai l'erreur que vous cité HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different

Par contre je ne comprends pas bien votre réponse.

Pouvez me la détailler ? Idéalement avec un exemple :)