E-Mail-Anhänge werden nicht über SMTP-Node in n8n 2.3.0 (selbst gehostet) versendet

Beschreiben Sie das Problem/den Fehler/die Frage

Hi,
Ich versuche, E-Mails mit Anhängen von IMAP-Trigger zu SMTP-Knoten in meinem selbst gehosteten n8n 2.3.0-Setup zu senden.
Setup:

  • E-Mail-Trigger (IMAP) mit aktiviertem „Simple"-Format
  • N8N_DEFAULT_BINARY_DATA_MODE=default
  • E-Mail senden Knoten (SMTP) mit Plesk-Mailserver
    Das Problem:
    E-Mails werden erfolgreich versendet, aber Anhänge sind NICHT enthalten. Wenn ich debugge, sehe ich, dass die Anhänge als Binärdaten vorhanden sind, aber sie werden in der empfangenen E-Mail nicht angezeigt.
    Ich habe versucht:
    :white_check_mark: N8N_DEFAULT_BINARY_DATA_MODE auf „memory

Kannst du einen Screenshot posten, wie der Attachments-Teil des SMTP-Knotens eingerichtet ist? Das Binary Property-Feld muss exakt dem Eigenschaftsnamen entsprechen, durch Kommas getrennt, keine Leerzeichen. Etwas wie attachment_0,attachment_1 funktioniert prima, aber wenn nach dem Komma ein Leerzeichen vorhanden ist, kann es stumm fehlschlagen.

Diese Einstellung für den Binärdatenmodus ist das, was mir am meisten auffällt. Wenn sie auf „default

[quote=“sergeys, post:2, topic:309749, full:true”]
Kannst du einen Screenshot zeigen, wie der Attachments-Teil des SMTP-Knotens konfiguriert ist? Das Feld „Binary Property

Hallo @Anthony_P Willkommen!
Keine Binärdaten erreichen Send email. formatInfoMail gibt ein einfaches JSON-Objekt ohne Binary-Schlüssel zurück, und Message a model ersetzt das Element danach erneut, sodass die Eigenschaften, die dein Attachments-Ausdruck benennt, zum Zeitpunkt der Knotenausführung nicht mehr auf dem Element existieren.
Füge die Binärdaten mit einem Code-Knoten zwischen si humain und Send email wieder ein:

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

Stelle dann Attachments auf {{ Object.keys($binary).join(',') }} ein.

Downgraden wird nicht helfen, das direkte Verweisen auf die Binärdaten eines anderen Knotens ist ein bekanntes Problem, das zuletzt in Version 1.115.3 gemeldet wurde:

Ändern Sie die Join-Funktion so, dass kein Leerzeichen hinzugefügt wird

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

Danke für die Erklärung! Aber ich muss etwas klarstellen: Wenn ich dieses Debug im E-Mail-Text hinzufüge: {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} kann ich den vollständigen Base64-Inhalt der Anhänge sehen. Das beweist, dass die Binärdaten immer noch vorhanden sind und vom E-Mail-Trigger-Knoten aus zugänglich sind. Wenn die Binärdaten wirklich wie von dir erwähnt verloren gingen, würde ich in der Debug-Ausgabe nichts sehen. Aber ich sehe die vollständigen Dateidaten (Base64-codiert). Das Problem ist also NICHT, dass die Binärdaten verschwinden – sie sind eindeutig vorhanden. Das Problem scheint eher zu sein, dass das Feld „Binary Properties

Ich habe das bereits viele Male getestet – sowohl mit dem vollständigen Node-Pfadausdruck als auch mit direktem Eintrag von attachment_0,attachment_1 – aber nichts funktioniert. Das Seltsame ist: Wenn ich zum Debuggen {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} im E-Mail-Body hinzufüge, kann ich den vollständigen Inhalt des Binary-Objekts mit allen Base64-Daten sehen. Das beweist, dass die Anhänge existieren und zugänglich sind. Aber der Send-E-Mail-Knoten fügt sie nicht an.

Wir haben uns das angesehen und es sieht so aus, als könnte es in einer neueren Version behoben sein. Bitte aktualisieren Sie und schauen Sie, ob das Problem weiterhin auftritt.

Diese Debug-Ausgabe ist ein Ausdruck, der direkt auf die Daten des IMAP-Knotens zugreift, was von überall im Workflow funktioniert und nichts auf das Element legt. Attachments ist kein Ausdruck, der Daten abruft, sondern eine Liste von Eigenschaftsnamen, die der Knoten selbst auf seinem Eingabeelement nachschlägt, und dein Screenshot zeigt die Vorschau, dass es sich genau auf die richtigen drei Namen auflöst. Der Knoten sucht dann nach attachment_0 auf dem Element, das von si humain übergeben wird, findet nichts und sendet ohne es.
Bei beiden deinen Tests hast du diesen String geändert. Kein Wert in diesem Feld kann funktionieren, bis etwas das Binärdatum auf das Element legt, was der Code-Knoten tut. Ein Upgrade wird das auch nicht ändern.

Danke, das funktioniert. Allerdings habe ich immer noch Schwierigkeiten zu verstehen, warum ich das Objekt vor dem Versenden der E-Mail neu erstellen muss.
Es liegt fast sicher daran, dass zwischen dem Moment, in dem ich die Anhänge abrufe, und dem Moment, in dem die E-Mail versendet wird, Zwischenblöcke vorhanden sind – und die Binärdaten aus dem ersten Block werden nicht automatisch von einem Block zum nächsten übergeben. In den Online-Tutorials, die ich gesehen habe, ist der Anhang im vorherigen Block definiert.

Binary wird nicht vererbt, jeder Node erstellt sein eigenes Ausgabeelement und entscheidet, ob er es weitergeben soll. formatInfoMail gibt ein einfaches Objekt zurück, daher war das Binary einen Node nach dem Trigger weg, und Message a model erstellt ein eigenes frisches Element. Die beiden IF-Nodes geben das Element direkt weiter, daher war die Anzahl der Nodes dazwischen nie das Problem.
Darum brauchen die Tutorials auch keinen Rebuild, der Anhang befindet sich auf der Ausgabe des Nodes direkt vor Send email. Nodes, die Daten umformen und behalten können, zeigen die Wahl in ihren Optionen an. Sowohl Edit Fields als auch Split Out haben eine Einstellung dafür, ob Binary in ihre Ausgabe weitergegeben wird.