نقوم الآن بتشغيل خادم البريد الإلكتروني الخاص بنا، وهو يعمل بشكل جيد للبريد الصادر مع Discourse. لذا الآن أبحث في استقبال رسائل البريد الإلكتروني للرد على المنشورات.
هناك استطلاع POP3 هذا، ولكن تم تعطيل POP3 في Dovecot الخاص بنا، باستخدام IMAP فقط. توجد إعدادات لفترات استطلاع IMAP، ولكن لا توجد إعدادات لتمكين استطلاع IMAP، وتحديد المضيف والمنفذ وبيانات الاعتماد وما إلى ذلك، كما هو الحال مع استطلاع POP3. هل يشارك استطلاع IMAP إعدادات استطلاع POP3، وهل من الممكن بعد ذلك تعطيل استطلاع POP3 بشكل فعال عن طريق تعيين فترته إلى 0 دقيقة أو شيء من هذا القبيل؟
قد أتمكن من تنفيذ هذا كبرنامج نصي للصدفة ليتم توجيهه إليه بشكل شرطي (عنوان البريد الإلكتروني للمستلم)، ولكن الحفاظ على تحديثه وعمله قد لا يكون عمليًا/معقولًا.
لذا سيكون استطلاع IMAP فقط هو الحل المفضل لدي، وآمل أن يكون هذا ممكنًا.
تحرير: أو نقوم بتثبيت بيئة تشغيل Ruby ونسخ مكتبة وملفات قابلة للتنفيذ لمستقبل البريد ورفض سريع في مكانه على المضيف، كما يفعل Dockerfile، واستدعائه من Postfix الخاص بنا عبر transport_maps بنفس الطريقة: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub
هل جرب أحد هذا؟
حسنًا، ذكر عضو آخر في الفريق أن استقصاء IMAP لم يعمل بشكل صحيح أبدًا، وتمت إزالته إلى حد ما، ويبدو أن هذه الإعدادات القليلة هي بقايا من الوقت الذي كان من المفترض تنفيذه فيه. تحرير: وجدت بعض التصريحات حول هذا الموضوع: IMAP support for group inboxes - #39 by martin
يبدو أنها خطوة إلى الوراء، حيث أن POP3 بالنسبة لي مهمل وغير عملي في الوقت الحاضر، حيث يستخدم الأشخاص عادةً عملاء بريد متعددين (الهاتف + الكمبيوتر كحد أدنى). لذلك لا أرى أي فائدة لتمكين مستمعي POP3 في مثيل Dovecot على الإطلاق.
ومع ذلك، تمكنت من تنفيذ واجهة برمجة تطبيقات مستلم البريد المباشر لـ Discourse في Postfix الحالي لدينا دون حاوية مستلم البريد وحتى بدون نصوص Ruby الخاصة بها، ولكن باتباع تكامل Postfix المستخدم في حاوية مستلم البريد لـ Discourse إلى حد كبير: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub
/etc/postfix/main.cf:
# بالنسبة لعنوان البريد الإلكتروني للرد في Discourse، فإننا نتجاوز النقل الافتراضي عبر تعيين النقل
transport_maps=hash:/etc/postfix/transport
/etc/postfix/transport
# يتم استخدام خدمة تسمى "discourse" كنقطة نهاية نقل للبريد الإلكتروني إلى عنوان الرد المحدد في Discourse
forum.reply@dietpi.com discourse:
/etc/postfix/master.cf
# نحدد خدمة النقل "discourse" كعملية أنبوبية إلى curl تستمع على مقبس UNIX (خاص)
# لا يمكن أن يكون غير مميز أو محصور في chroot لكي يعمل الأنبوب إلى curl
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=< -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
لذا فإن تعيين النقل يمرر رسائل البريد الإلكتروني إلى عنوان الرد إلى خدمتنا المخصصة “discourse”.
أفضل أداء يجب أن يكون مقبس UNIX، ويمكن أن يكون خاصًا (الأول “-”)، حيث لا يجب على أي شيء آخر استخدامه على أي حال. “خاص” يعني أن المقبس موجود في /var/spool/postfix/private/discourse، في دليل يمكن للمستخدم postfix فقط الوصول إليه، داخل دليل chroot الخاص بـ Postfix /var/spool/postfix.
ولكن لا يمكن أن يكون غير مميز أو محصور في chroot لكي يعمل pipe إلى curl (n n).
ثم نقلل الأذونات باستخدام المستخدم:المجموعة nobody:nogroup.
باتباع واجهة برمجة تطبيقات المستلم، يجب إرفاق البريد الإلكتروني بحقل نموذج email، والذي يمكن القيام به عبر استدعاء stdin الخاص بـ curl <. يجب إضافة رؤوس Api-Username و Api-Key، حيث يكون الأول عادةً system، ويمكن إنشاء الثاني في Discourse، كمفتاح API دقيق مع أذونات receive_emails فقط. ثم استخدام نقطة النهاية HTTP المعنية.
نتجاوز عمدًا فحوصات سياسة الرفض السريع التي تجريها حاوية المستلم:
يتحقق من وجود رؤوس From و To، وما إذا كان المرسل عنوانًا كاملاً مع نطاق، وما إذا كان على قائمة سوداء يمكن تعريفها اختياريًا عبر متغير الحاوية BLACKLISTED_SENDER_DOMAINS. ويرسل عناوين المرسل والمستلم إلى نقطة نهاية واجهة برمجة تطبيقات HTTP أخرى لـ Discourse تتحقق مما إذا كان المستلم يتطابق مع قالب عنوان البريد الإلكتروني للرد المحدد، وما إذا كان عنوان المرسل ينتمي إلى مستخدم مسجل، ما لم يتم تكوين المنتدى لإنشاء مستخدمين جدد غير نشطين عند رسائل البريد الإلكتروني الواردة، وهو ما تم تمكينه بشكل غريب افتراضيًا في حالتنا؟
معظم هذا، وأكثر، يتم فحصه بواسطة خدمة مستلم SMTP العامة الخاصة بنا في Postfix على أي حال، وكل شيء يمر عبر rspamd مما يعني فحوصات DKIM و SPF و DMARC.
ولكن الأهم من ذلك، أن نفس الفحوصات يتم إجراؤها بواسطة الواجهة الخلفية لمستلم البريد النهائي لـ Discourse على أي حال. العيب الوحيد إلى حد ما: لا يتلقى المرسلون بريدًا إلكترونيًا لرفض/ارتداد من خادم البريد، ولكن الأخطاء في حالة المرسل/المستلم غير الصحيح يتم تسجيلها بدلاً من ذلك/فقط في Discourse الخاص بنا. ولكن إذا كان المرسل والمستلم صحيحين، فإن محتوى البريد فقط ليس كما هو متوقع (خاصةً رأس Message-ID مفقود)، يتلقى المرسلون بريدًا إلكترونيًا مناسبًا من Discourse. رسائل الرفض/الارتداد SMTP المفقودة لا بأس بها تمامًا في رأيي، نظرًا لأن التنفيذ بخلاف ذلك بأقل عبء إضافي، ولديه طلب شبكة واحد ومعالجة خلفية أقل لكل بريد إلكتروني، إلخ.
بشكل عام: كن حذرًا مع المسافات في وسائط أوامر master.cf. الاقتباس للاحتفاظ بالمسافات حرفيًا لا يعمل. بدلاً من ذلك، يجب تغليف وسيطة كهذه في أقواس معقوفة: {some arg with spaces}. ولكن في هذه الحالة، لا تحتوي أي وسيطة على مسافات، وتلك الموجودة بين مفتاح الرأس والقيمة اختيارية.
يعمل بشكل رائع حتى الآن، ويتكامل بسلاسة مع إعدادنا الحالي مع النقل الافتراضي الافتراضي إلى Dovecot، ويستخدم تعيين النقل أيضًا لإعادة توجيه بعض رسائل البريد الإلكتروني إلى عناوين خارجية، حيث لا يرغب / يتطلب الجميع من الفريق صندوق بريد إضافي على خادمنا. إذا تم تعريف عنوان التقاط شامل في تعيين الاسم المستعار الافتراضي، فيجب إضافة عنوان الرد الخاص بـ Discourse إلى هذا الجدول، مع تعيينه لنفسه (مثل المستخدمين/العناوين الافتراضية المحلية الأخرى).