قمنا بإعداد خادم البريد الإلكتروني الخاص بنا، وتساءلت عن كيفية استخدامه بأفضل شكل مع حاوية Docker الخاصة بـ Discourse.
بالطبع يمكنني فقط تكوين تفاصيل و بيانات اعتماد SMTP الخاصة بنا، ولكن يبدو أن هذا عبء إضافي غير ضروري، نظرًا لأن خادم SMTP يعمل على نفس الجهاز.
يعمل sendmail، ولكن Discourse موجود في الحاوية، وبالتالي لا يمكنه الوصول إلى sendmail على المضيف الخاص به.
البحث عن شيء هنا في المنتدى يعطي مثالًا واحدًا حيث تم استخدام DISCOURSE_SMTP_DOMAIN بدون بيانات اعتماد، حيث يعمل القيام بنفس الشيء مع swaks داخل الحاوية: How to get Discourse to work with Postfix - #18 by sonmicrosystems أعتقد أنه في هذه الحالة، لا يزال إرسال SMTP عاديًا على المنفذ الافتراضي، ويقبله Postfix بدون مصادقة، نظرًا لأن الطلب يأتي من localhost؟
لا يمكنني تغيير هذه الإعدادات في واجهة المستخدم الرسومية، أعتقد لأن YAML الحاوية تفرضها عبر DISCOURSE_SMTP_ADDRESS وما إلى ذلك؟ ولكن لا يمكنني العثور على متغير لطريقة التسليم.
ربما يعرف شخص ما طريقة أخرى، وحتى ذلك الحين، سأقوم بإعداد مصادقة منفذ إرسال SMTP عادي. شكرًا لـ DISCOURSE_SMTP_FORCE_TLS بالمناسبة، تم إضافته مؤخرًا، ولكنه ليس جزءًا من أي عينة حتى الآن (يجب أن يكون). لا أنوي السماح بـ STARTTLS، ولكن فقط بـ TLS ضمنيًا/فوريًا.
عبء عمل غير ضروري كيف؟ يجب عليك إرسال البيانات من Discourse إلى خادم SMTP بطريقة ما؟ لا؟
ملاحظة: إذا كان حاوية أخرى، يمكنك من حيث المبدأ استخدام شبكة الجسر واستخدام اسم حاوية smtp بدلاً من اسم المضيف إذا كان هذا ما تبحث عنه، ولكنه لن يمنحك أي مزايا في الأداء.
هناك طريقتان لإرسال رسائل البريد الإلكتروني عبر خادم SMTP محلي:
الاتصال بمنفذ الإرسال والمصادقة عليه، مثل 587 مع STARTTLS أو 465 مع TLS ضمني/فوري => طلب شبكة، يتم تطبيق الفحوصات والقيود عبر smtpd
استخدام sendmail أو ما شابه، والذي يستدعي أمر pickup المحلي (في حالة Postfix)، ولا يقوم بأي اتصال شبكة، ويتجاوز جميع الفحوصات والقيود المكونة لخدمة إرسال smtpd.
الأخير أبسط وأسرع، ومطبق في أنظمة التشغيل والأطر الشائعة، مثل PHP mailer ومكتبة Ruby mail هذه التي يستخدمها Discourse. ويتم تجاوز المصادقة، ولا تحتاج بيانات الاعتماد النصية العادية إلى تخزينها في أي مكان. أو بعبارة أخرى: لا يتم استخدام خادم SMTP على الإطلاق في هذه الحالة، ولكن فقط عميل SMTP.
أعني نعم، لا ينبغي أن يكون لاتصال منفذ الإرسال أي تأثير كبير على حمل الخادم، مقارنة بما يفعله Discourse بخلاف ذلك. يمكن حل النقطة الأخيرة باستخدام، على سبيل المثال، قاعدة smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject عند منفذ الإرسال، للسماح بالإرسالات من عناوين IP المحلية (الافتراضية، إعداد mynetworks) قبل إجراء أي مصادقة. إذا شوهد الطلب من الحاوية بعنوان IP آخر، فيمكن إضافته إلى mynetworks. أعتقد أن هذا هو ما حدث في حالة الموضوع الذي ربطته من قبل.
سنرى في المرة القادمة التي نقوم فيها بتحديث/إعادة بناء Discourse الخاص بنا، عندما يتم تطبيق إعدادات SMTP المتغيرة. سأبلغ عن كيفية عملها.
ولكن لا يزال من المثير للاهتمام معرفة ما إذا كانت هناك طرق أخرى، وماذا يعني هذا الإعداد “Delivery method”.
يعمل Postfix على المضيف، وليس داخل حاوية، ولكن لن يكون هناك فرق كبير، حيث يظل مصادقة قائمة على الشبكة.
نعم، بعد تفكير، من المنطقي فقط أن sendmail وما شابه من المضيف/الحاوية الأخرى لا يمكن أن تعمل داخل حاوية، لأنها تتطلب وصولاً مباشراً إلى أجزاء واسعة من ملفات Postfix التنفيذية والمكتبات والإعدادات، على ما أعتقد. ما لم يكن هناك نوع من المقبس السحري يمكن ربطه بالحاوية أو شيء من هذا القبيل .
لقد مر وقت طويل منذ أن تعمقت في إدارة sendmail الدقيقة. لدي Mailcow stack على جهاز افتراضي واحد و Discourse على جهاز افتراضي آخر. لا أعرف ما إذا كان الأمر يستحق الحفر بهذا العمق بخلاف مجرد الاستمتاع به.
أتمنى لك كل التوفيق في مغامراتك، وأبلغني بما تعلمته.
ربما لا . لكنني مهووس بالكمال في سياقات معينة، وأستمتع بالحفر بعمق وتعلم كل التفاصيل. استغرق الأمر مني عدة أمسيات لإعداد Dovecot و Postfix و rspamd و dkimpy-milter و PostSRSd، … خطوة بخطوة، والتعرف على كل إعداد تقريبًا متاح، ولماذا تكون الإعدادات الافتراضية كذلك، وما إذا كنا قد نرغب في ذلك بشكل مختلف ولماذا. ولكن مهلاً، يبدو الآن أنني أفهم معظم الأشياء بشكل أفضل من معظم مؤلفي أدلة خوادم البريد الإلكتروني العشوائية الموجودة .
أنا أنقل هذا الموضوع إلى Installation > Hosting. لا نوصي بمحاولة استضافة خادم البريد الإلكتروني الخاص بك، كما تعلم إذا قرأت تعليمات التثبيت الرسمية. البريد الإلكتروني صعب!
لست متأكدًا مما علاقة Discourse بما إذا كان النظام يمكنه استضافة خادم بريد إلكتروني إضافي أم لا؟ بخلاف حقيقة أن هذا يفتح نظريًا طريقة أخرى لإرسال رسائل البريد الإلكتروني، بالطبع.
بالنسبة لاستقبال رسائل البريد الإلكتروني (موضوع آخر) ومع ذلك، فإن له تأثيرًا، حيث لا يمكن استضافة حاوية استقبال البريد الإلكتروني بعد ذلك، على الأقل ليس للاستماع على المنفذ 25 مباشرة. ولكن استخدام واجهة برمجة تطبيقات استقبال البريد الإلكتروني الخاصة بـ Discourse مباشرة تبين أنها مجرد 2-3 أسطر في تكوين Postfix: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng
لكنني أتفق، لم تكن إعدادات خادم البريد الإلكتروني بشكل صحيح مهمة سهلة بالضبط، كما ذكرنا أعلاه. ولكنها مثيرة للاهتمام للغاية للتعلم .
نعم! إنه أمر صعب ومثير للاهتمام بالتأكيد. لقد مررت بمغامراتي الخاصة في تثبيت جميع أنواع الخدمات ومحاولة تشغيلها بنفسي، في حياة سابقة!
يسعدني أن تقوم بتحديث هذا الموضوع بتعلمك لصالح المسافرين المغامرين المستقبليين، بما في ذلك أنت. ولكن ضع في اعتبارك أن فئة Support مخصصة للتثبيتات المدعومة، ونواة discourse، والمكونات الإضافية والمكونات الرسمية.
ما الخطأ في Postfix؟ لقد كان جزءًا من دليل إعداد خادم البريد الأول الذي قرأته، وخيارات التصفية الداخلية الخاصة به لتقليل البريد العشوائي والوصول الروبوتي مبكرًا في خط الأنابيب بدت حجة جيدة.
حسنًا، نوعًا ما خارج الموضوع، فيما يتعلق باستخدام sendmail/pickup من Discourse.
أضع علامة على هذا على أنه تم حله/الإجابة عليه. من المنطقي أن حاوية Discourse لا يمكنها الوصول إلى sendmail الخاص بالمضيف، بغض النظر عن الخادم. لذلك تحتاج إلى استخدام إرسال SMTP، والذي يمكن للمرء المصادقة عليه على سبيل المثال عبر نطاق IP لحاوية Docker في Postfix، وتخطي المصادقة passdb/userdb على Dovecot.
.
. لكنني مهووس بالكمال في سياقات معينة، وأستمتع بالحفر بعمق وتعلم كل التفاصيل. استغرق الأمر مني عدة أمسيات لإعداد Dovecot و Postfix و rspamd و dkimpy-milter و PostSRSd، … خطوة بخطوة، والتعرف على كل إعداد تقريبًا متاح، ولماذا تكون الإعدادات الافتراضية كذلك، وما إذا كنا قد نرغب في ذلك بشكل مختلف ولماذا. ولكن مهلاً، يبدو الآن أنني أفهم معظم الأشياء بشكل أفضل من معظم مؤلفي أدلة خوادم البريد الإلكتروني العشوائية الموجودة 
.
.