مرفقات البريد الإلكتروني لا تُرسل عبر عقدة SMTP في n8n 2.3.0 (استضافة ذاتية)

أسئلة
1

وصف المشكلة/الخطأ/السؤال

مرحبا،
أحاول إرسال رسائل بريد إلكترونية مع المرفقات من محفز IMAP إلى عقدة SMTP في إعداد n8n 2.3.0 الذاتي التستضيف.
الإعداد:

  • محفز البريد الإلكتروني (IMAP) مع تفعيل تنسيق “البسيط”
  • N8N_DEFAULT_BINARY_DATA_MODE=default
  • عقدة إرسال البريد الإلكتروني (SMTP) مع خادم بريد Plesk
    المشكلة:
    يتم إرسال رسائل البريد الإلكتروني بنجاح ولكن المرفقات لا تُضمّن. عند التصحيح، أرى أن المرفقات موجودة كبيانات ثنائية، لكنها لا تظهر في البريد الإلكتروني المستلم.
    لقد جربت:
    :white_check_mark: تغيير N8N_DEFAULT_BINARY_DATA_MODE إلى “memory” و"default"
    :white_check_mark: إعادة التشغيل باستخدام docker compose down -v
    :white_check_mark: استخدام عقدة “Extract from File” للتحويل إلى Base64
    :white_check_mark: تعيين Binary Properties إلى “attachment_0,attachment_1,attachment_2”
    لم يعمل أي من هذه. يصل البريد الإلكتروني لكن المرفقات مفقودة دائماً.
    الأسئلة:
  1. هل هذا خطأ معروف مع SMTP + البيانات الثنائية في 2.3.0؟
  2. هل هناك أي حلول بديلة بخلاف استخدام Gmail API؟
  3. هل يجب أن أخفّض إلى n8n 1.x؟
    سيكون أي مساعدة موضع تقدير!

ما هي رسالة الخطأ (إن وجدت)؟

يرجى مشاركة سير العمل الخاص بك

شارك المخرجات التي يعيدها العقدة الأخيرة

معلومات حول إعدادات n8n الخاصة بك

  • إصدار n8n: 2.3.0
  • قاعدة البيانات (الافتراضي: SQLite): postgres
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
  • تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): docker
  • نظام التشغيل: ubuntu
2

هل يمكنك نشر لقطة شاشة لكيفية إعداد جزء المرفقات في عقدة SMTP؟ يجب أن يتطابق حقل Binary Property مع اسم الخاصية بالضبط، مفصولة بفواصل، بدون مسافات. شيء مثل attachment_0,attachment_1 يعمل بشكل جيد، لكن إذا كانت هناك مسافة بعد الفاصلة فقد يتعطل بصمت.

3

إعداد وضع البيانات الثنائية هو ما يلفت انتباهي أكثر من أي شيء آخر. عندما يكون على “الافتراضي”، فإنه يحفظ المرفق على القرص ويستعيده لاحقاً عندما يحين وقت إرسال البريد الإلكتروني. إذا كان إعدادك يتضمن أكثر من حاوية واحدة في أي مكان، فقد لا تتمكن عقدة SMTP من العثور على هذا الملف عندما تذهب لإرفاقه ولن تطرح خطأ، بل ستتخطاه بصمت. وهذا يطابق تماماً ما تراه. أيضاً، أمر docker compose down -v الذي أجريته، الخيار -v يمسح المجلدات. إذا كان تخزين البيانات الثنائية موجوداً في أحد تلك المجلدات، فقد يكون هذا الأمر قد حذفه مباشرة هناك.

4

مرحبا، شكرا على مساعدتك

image
image1005×568 38.6 KB

5

مرحباً @Anthony_P أهلاً وسهلاً!
لا يصل أي شيء ثنائي إلى Send email. formatInfoMail يعيد كائن json عادي بدون مفتاح ثنائي، وMessage a model يستبدل العنصر مرة أخرى بعده، لذلك الخصائص التي يسميها تعبير Attachments لا تعود موجودة على العنصر بحلول وقت تشغيل العقدة.
أعد الثنائي باستخدام عقدة Code بين si humain وSend email:

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

ثم اضبط Attachments على {{ Object.keys($binary).join(',') }}.

التخفيف من الإصدار لن يساعد، توجيه هذا الحقل مباشرة إلى ثنائي عقدة أخرى هي مشكلة مفتوحة آخر إبلاغ عنها في 1.115.3:

6

غيّر الدمج بحيث لا يضيف مسافة

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

شكراً على التوضيح! لكن أحتاج إلى توضيح شيء ما: عندما أضيف هذا التصحيح في نص البريد الإلكتروني: {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} يمكنني رؤية محتوى Base64 الكامل للمرفقات. هذا يثبت أن البيانات الثنائية لا تزال موجودة وقابلة للوصول من عقدة Email Trigger. إذا كانت البيانات الثنائية قد فُقدت فعلاً كما ذكرت، فلن أرى أي شيء في مخرجات التصحيح. لكن أنا أرى بيانات الملف الكاملة (مشفرة بـ Base64). لذا المشكلة ليست أن البيانات الثنائية تختفي - فهي موجودة بوضوح هناك. يبدو أن المشكلة هي أن حقل “Binary Properties” في عقدة Send email لا يمكنه الوصول إليها من عقدة Email Trigger مباشرة.

8

لقد اختبرت هذا عدة مرات بالفعل - سواء باستخدام مسار العقدة الكامل أو بوضع attachment_0,attachment_1 مباشرة - لكن لا شيء يعمل. الغريب هو: عندما أقوم بتصحيح الأخطاء بإضافة {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} في نص البريد الإلكتروني، يمكنني رؤية المحتوى الكامل لكائن ثنائي مع كل بيانات Base64. هذا يثبت أن المرفقات موجودة وقابلة للوصول. لكن عقدة إرسال البريد الإلكتروني لن تقوم بإرفاقها.

image
image2131×327 56.3 KB

9

لقد ألقينا نظرة على هذا ويبدو أنه قد يكون تم إصلاحه في إصدار حديث. يرجى التحديث والتحقق مما إذا كنت لا تزال تواجه نفس المشكلة.

10

مخرجات التصحيح هذه عبارة عن تعبير يقرأ بيانات عقدة IMAP مباشرة، وهو يعمل من أي مكان في سير العمل ولا يضع أي شيء على العنصر. Attachments ليس تعبيرًا يجلب البيانات، بل هو قائمة بأسماء الخصائص التي تبحث عنها العقدة بنفسها في العنصر المدخل الخاص بها، وتعرض لقطة الشاشة الخاصة بك معاينة لها تتحل إلى الأسماء الثلاثة الصحيحة تمامًا. ثم تبحث العقدة عن attachment_0 على العنصر الذي سلمه si humain، ولا تجد شيئًا، وترسل بدونه.
غيّر كلا الاختبارين الخاصين بك تلك السلسلة. لا يمكن لأي قيمة في هذا الحقل أن تعمل حتى يضع شيء ما الملف الثنائي على العنصر، وهو ما تفعله عقدة Code. لن يغير الترقية ذلك أيضًا.

12

شكراً، هذا يعمل. ومع ذلك، لا أزال أواجه صعوبة في فهم السبب وراء الحاجة إلى إعادة بناء الكائن قبل إرسال البريد الإلكتروني.
من المؤكد تقريباً أنه بسبب أنه، بين لحظة استرجاع المرفقات ولحظة إرسال البريد الإلكتروني، هناك كتل وسيطة—وبيانات ثنائية من الكتلة الأولى لا تنتقل تلقائياً من كتلة إلى أخرى. في البرامج التعليمية على الإنترنت التي شاهدتها، يتم تحديد المرفق في الكتلة السابقة.

13

البيانات الثنائية لا ترث، كل عقدة تبني عنصر الإخراج الخاص بها وتقرر ما إذا كانت ستحمله معها. formatInfoMail تعيد كائنًا عاديًا، لذا اختفت البيانات الثنائية بعد عقدة واحدة من المشغل، وMessage a model تبني عنصرًا جديدًا بمفردها. العقدتان IF تمرران العنصر مباشرة، لذا لم يكن عدد العقد بينهما هو المشكلة.ولهذا السبب أيضًا لا تحتاج البرامج التعليمية إلى إعادة بناء، المرفق يجلس على إخراج العقدة مباشرة قبل Send email. العقد التي تعيد تشكيل البيانات وتستطيع الاحتفاظ بها تعرض الخيار في خياراتها، Edit Fields و Split Out كلاهما لهما إعداد لما إذا كانت البيانات الثنائية تنتقل إلى إخراجهما.Edit Fields (Set) | Nodes | n8n Docs