Les pièces jointes email ne s'envoient pas via le nœud SMTP dans n8n 2.3.0 (auto-hébergé)

Décris le problème/l’erreur/la question

Salut,
J’essaie d’envoyer des e-mails avec des pièces jointes depuis un déclencheur IMAP vers un nœud SMTP dans ma configuration n8n 2.3.0 auto-hébergée.
Configuration :

  • Déclencheur d’e-mail (IMAP) avec le format « Simple » activé
  • N8N_DEFAULT_BINARY_DATA_MODE=default
  • Nœud Envoyer un e-mail (SMTP) avec serveur de messagerie Plesk
    Le problème :
    Les e-mails s’envoient avec succès mais les pièces jointes ne sont PAS incluses. Quand je fais du débogage, je vois que les pièces jointes existent en tant que données binaires, mais elles n’apparaissent pas dans l’e-mail reçu.
    J’ai essayé :
    :white_check_mark: Changé N8N_DEFAULT_BINARY_DATA_MODE en « memory » et « default »
    :white_check_mark: Redémarré avec docker compose down -v
    :white_check_mark: Utilisé le nœud « Extract from File » pour convertir en Base64
    :white_check_mark: Défini les propriétés binaires sur « attachment_0,attachment_1,attachment_2 »
    Rien n’a fonctionné. L’e-mail arrive mais les pièces jointes manquent toujours.
    Questions :
  1. Est-ce un bug connu avec SMTP + données binaires dans la version 2.3.0 ?
  2. Y a-t-il des solutions alternatives en dehors de l’utilisation de l’API Gmail ?
  3. Dois-je rétrograder vers n8n 1.x ?
    Toute aide serait appréciée !

Quel est le message d’erreur (le cas échéant) ?

Partage ton flux de travail

Partage la sortie renvoyée par le dernier nœud

Informations sur ta configuration n8n

  • version n8n : 2.3.0
  • Base de données (par défaut : SQLite) : postgres
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : docker
  • Système d’exploitation : ubuntu

Pouvez-vous publier une capture d’écran de la façon dont la partie Pièces jointes du nœud SMTP est configurée ? Le champ Propriété binaire doit correspondre exactement au nom de la propriété, séparé par des virgules, sans espaces. Quelque chose comme attachment_0,attachment_1 fonctionne bien, mais s’il y a un espace après la virgule, cela peut s’arrêter silencieusement.

C’est ce paramètre de mode de données binaires qui me frappe le plus. Quand il est sur « default », il enregistre la pièce jointe sur le disque et la récupère plus tard au moment d’envoyer l’e-mail. Si votre configuration implique plusieurs conteneurs n’importe où, le nœud SMTP pourrait ne pas être en mesure de trouver ce fichier quand il faut le joindre et il ne lancera pas d’erreur, il le passera simplement en silence. Ce qui correspond exactement à ce que vous voyez. De plus, le docker compose down -v que vous avez exécuté, le -v efface les volumes. Si votre stockage binaire se trouvait dans l’un de ceux-ci, cette commande l’a peut-être supprimé à ce moment-là.

Bonjour, merci pour votre aide

Salut @Anthony_P Bienvenue !
Aucun binaire n’arrive à Send email. formatInfoMail retourne un objet json brut sans clé binaire, et Message a model remplace l’élément à nouveau après, donc les propriétés que votre expression Attachments nomme n’existent plus sur l’élément au moment où le nœud s’exécute.
Remettez le binaire en place avec un nœud Code entre si humain et Send email :

return [{
  json: $input.first().json,
  binary: $('Email Trigger (IMAP)').first().binary,
}];

Puis définissez Attachments sur {{ Object.keys($binary).join(',') }}.

La rétrogradation ne vous aidera pas, pointer ce champ directement vers le binaire d’un autre nœud est un problème ouvert signalé pour la dernière fois sur 1.115.3 :

changez la jointure pour ne pas ajouter d’espace

{{ Object.keys($('Email Trigger (IMAP)').item.binary).join(',') }}

Merci pour l’explication ! Mais je dois clarifier quelque chose : Quand j’ajoute ce debug dans le corps de l’e-mail : {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} je peux voir le contenu Base64 complet des pièces jointes. Cela prouve que les données binaires existent toujours et sont accessibles à partir du nœud Email Trigger. Si les fichiers binaires avaient vraiment disparu comme vous l’avez mentionné, je ne verrais rien dans la sortie de debug. Mais je vois les données complètes du fichier (encodées en Base64). Le problème n’est donc PAS que les fichiers binaires disparaissent - ils sont clairement là. Le problème semble être que le champ « Binary Properties » du nœud Send email ne peut pas y accéder directement à partir du nœud Email Trigger.

J’ai déjà testé cela de nombreuses fois — à la fois avec l’expression complète du chemin de nœud et en mettant directement attachment_0,attachment_1 — mais rien ne fonctionne. Ce qui est étrange, c’est : quand je débogue en ajoutant {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} dans le corps de l’e-mail, je peux voir tout le contenu de l’objet binary avec toutes les données Base64. Cela prouve que les pièces jointes existent et sont accessibles. Mais le nœud Send email ne les attache pas.

Nous avons examiné cela et il semble que cela pourrait être corrigé dans une version récente. Veuillez mettre à jour et vérifier si vous rencontrez toujours le même problème.

Cette sortie de débogage est une expression qui lit les données du nœud IMAP directement, ce qui fonctionne de n’importe où dans le flux de travail et ne place rien sur l’élément. Attachments n’est pas une expression qui récupère des données, c’est une liste de noms de propriétés que le nœud recherche dans son élément d’entrée, et votre capture d’écran l’aperçoit en se résolvant exactement aux trois bons noms. Le nœud recherche ensuite attachment_0 sur l’élément transmis par si humain, ne trouve rien et envoie sans lui.
Vos deux tests ont modifié cette chaîne. Aucune valeur dans ce champ ne peut fonctionner tant que quelque chose ne place pas le binaire sur l’élément, ce que fait le nœud Code. Une mise à niveau ne changera rien non plus.

Merci, ça fonctionne. Cependant, j’ai toujours du mal à comprendre pourquoi je dois reconstruire l’objet avant d’envoyer l’e-mail.
C’est presque certainement parce qu’entre le moment où je récupère les pièces jointes et le moment où l’e-mail est envoyé, il y a des blocs intermédiaires — et les données binaires du premier bloc ne passent pas automatiquement d’un bloc à l’autre. Dans les tutoriels en ligne que j’ai vus, la pièce jointe est définie dans le bloc précédent.

Le binaire n’est pas hérité, chaque nœud construit son propre élément de sortie et décide s’il le transmet. formatInfoMail renvoie un objet brut, donc le binaire a disparu un nœud après le déclencheur, et Message a model construit un élément nouveau de son côté. Les deux nœuds IF passent l’élément directement, donc le nombre de nœuds entre les deux n’a jamais eu d’importance.
C’est également pour cela que les tutoriels n’ont pas besoin d’être reconstruits, la pièce jointe se trouve sur la sortie du nœud immédiatement avant Envoyer un email. Les nœuds qui restructurent les données et peuvent les conserver exposent le choix dans leurs options, Éditer les champs et Diviser la sortie ont tous deux un paramètre pour déterminer si le binaire est transféré à leur sortie.