إذا كان لديك حاوية استلام بريد تتطلب تكوينًا مخصصًا لـ Postfix، فهذا الموضوع مخصص لك. سنشرح هنا الخطوات اللازمة لتعيين متغيرات تكوين main.cf في Postfix حسب رغبتك.
يمكن تعيين متغيرات تكوين Postfix عبر بيئة الحاوية. فأي متغير بيئة يبدأ بـ POSTCONF_ سيعين متغير تكوين Postfix الذي يحمل الاسم المتبقي من متغير البيئة إلى قيمة متغير البيئة. على سبيل المثال، إذا عيّنت متغير البيئة POSTCONF_always_bcc إلى bob@example.com، فسيتم تكوين Postfix بـ always_bcc = bob@example.com، مما يؤدي إلى إرسال نسخة من جميع الرسائل الواردة إلى بوب. poor Bob.
الإجراء
حدد متغيرات التكوين التي ترغب في تعيينها والقيم المراد تعيينها. يمكن القيام بذلك عن طريق قراءة الدليل الممتاز، أو من خلال التوصيات في وثائق Discourse الأخرى، أو بأي طريقة أخرى.
اتصل بخادم Discourse الخاص بك عبر SSH، واحصل على صلاحيات root، ثم انتقل إلى المكان الذي توجد فيه جميع إعدادات discourse-docker:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
افتح ملف containers/mail-receiver.yml في محرر النصوص المفضل لديك، وانتقل إلى قسم env: في الملف. أضف في مكان ما من هذا القسم مدخلات للمتغيرات التي ترغب في إضافتها، مع الحرص على عدم تعديل أي شيء آخر والحفاظ على المسافات البادئة المناسبة. على سبيل المثال، إذا كنا نضيف إعداد always_bcc، فقد يبدو الملف كالتالي:
بمجرد أن تكون راضيًا عن ما أضفت، احفظ الملف واخرج من المحرر.
لتحميل التكوين، كل ما عليك فعله هو إعادة تشغيل حاوية mail-receiver (لا يلزم إجراء rebuild):
./launcher restart mail-receiver
بعد لحظة من الاضطراب، يجب أن تعمل الحاوية مرة أخرى.
اختبر التغييرات. تأكد من أن ما أردت حدوثه قد حدث بالفعل، وأن أي شيء لم تتوقع تغييره لم يتغير.
إضافة: إضافة ملفات إلى حاوية mail-receiver
تتطلب العديد من معاملات تكوين Postfix الوصول إلى “ملفات قاعدة البيانات”، التي توفر معلومات بالمفتاح/القيمة التي يستخدمها Postfix لاتخاذ قرارات بشأن كيفية معالجة البريد. إذا رأيت أن معامل التكوين يقبل اسم ملف يبدو مثل hash:/some/file، فقد وجدت استخدامًا لملفات قاعدة البيانات.
المشكلة هي أن Postfix الذي يعمل داخل الحاوية يحتاج إلى القدرة على الوصول إلى هذه الملفات أثناء تشغيله، مما يعني أنه يجب عليك إما نسخ هذه الملفات إلى الحاوية، أو (الأفضل) وضع هذه الملفات في دليل على المضيف، ثم تركيب هذا الدليل كحجم داخل الحاوية. تصفح هذه التعليمات الطريقة الثانية.
بمجرد إكمال هذا الإجراء، ستصبح أي ملف تضعه في /var/discourse/shared/mail-receiver/etc مرئيًا فورًا في /etc/postfix/shared داخل الحاوية، وأي تغييرات تجريها على هذه الملفات ستصبح مرئية فورًا لـ Postfix.
إليك كيفية تحقيق ذلك.
إذا لم تكن قد سجلت الدخول بعد كمسؤول (root) إلى خادم Discourse الخاص بك، فافعل ذلك مرة أخرى:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
افتح ملف containers/mail-receiver.yml في محرر النصوص المفضل لديك، وهذه المرة انتقل إلى قسم volume:. تحت التعريف الحالي لدليل /var/spool/postfix، أضف تعريفًا آخر، بحيث يبدو قسم volume كالتالي:
Matt, do you think that could be possible to enable accounts like admin@domain or info@domain from this Postfix configuration?
I only need to have a couple of addresses for incoming e-mail and I have it working with Discourse but I can’t set accounts (their seem to be blocked by default even though messages are processed).
لقد قمت للتو بإعداد خدمة Discourse تجريبية باستخدام Digital Ocean و Mailgun للبريد الإلكتروني الصادر. لدي نطاق مسجل بسجل MX مناسب يشير إلى عنوان IP الخاص بـ Digital Ocean. يعمل البريد الإلكتروني الصادر والوارد بشكل صحيح مع Discourse. تؤدي الردود على المواضيع إلى إنشاء رسائل بريد إلكتروني صادرة إلى أولئك الذين لديهم إشعارات مضبوطة ويمكن للمستخدمين التجريبيين الرد على هذه الرسائل وتظهر المشاركات في Discourse. كل شيء على ما يرام حتى الآن.
حاولت إضافة خيار POSTCONF_always_bcc: كما هو مذكور أعلاه ولكنه لا يبدو أنه يعمل - أشك في أن جزء ‘mail-receiver’ من Discourse غير قادر على إرسال البريد الإلكتروني بشكل صحيح عبر Mailgun، على الرغم من أن جزء ‘app’ يعرف كيفية القيام بذلك - يحتوي app.yml على اسم المستخدم وكلمة المرور لخادم Mailgun ولكني لم أر أي أمثلة لكيفية وضع هذه المعلومات في ملف إعدادات mail-receiver.
أعلم أن خيار always_bcc تتم قراءته والتصرف فيه، حيث إذا كتبت:
./launcher enter mail-receiver
ثم قمت بتشغيل
mailq
يمكنني رؤية رسالة اختبار أرسلتها وهي في قائمة الانتظار تحاول التسليم. في عمود “-Sender/Recipient-------” يوجد العنوان الذي جاءت منه رسالة الاختبار الخاصة بي، والكلمات “(unknown mail transport error)” ثم عنوان البريد الإلكتروني الذي كان في إعداد always_bcc.
كنت آمل في تصفية الرسائل الواردة بطريقة ما بحيث إذا تم إرسال رسالة إلى postmaster@mydomain أو admin@mydomain، فسيتم إعادة إرسالها عبر الإنترنت العام، عبر Mailgun، إلى عنوان Gmail الخاص بي وعدم إرسالها إلى Discourse للمعالجة. قد يكون هذا ما كان يحاول المستخدم @satonotdead القيام به.
هممم. نعم، أولاً ستحتاج إلى تكوين مستلم البريد mailgun ليكون لديه بعض الوسائل لتسليم البريد، لأنه لا يعرف بيانات الاعتماد أو آلية النقل في app.yml. أعتقد أنك ستحتاج إلى إضافة تكوين أكثر اكتمالاً كما هو مشار إليه في القسم التالي حول تحميل وحدات التخزين، وتفاصيلها خارج نطاق هذه الوثيقة.
الحل البسيط لـ “كيف أتعامل مع رسائل البريد الإلكتروني الخاصة بـ postmaster و admin” هو إنشاء مجموعة لكل منها وإضافة كل من تريد أن يتلقى هذه الرسائل إلى تلك المجموعة ويمكنهم التعامل معها كرسائل جماعية.
هل تقصد ‘mail-receiver’ بدلاً من Mailgun؟ كما في تعليم ‘mail-receiver’ كيفية التحدث إلى Mailgun عبر الإنترنت العام وتمرير بيانات الاعتماد بشكل صحيح لطلب منه إجراء عمليات التسليم الفعلية؟
حسنًا نعم، ذلك، أو بطريقة أخرى، قم بتكوين mail-receiver (أي Postfix) لتسليم البريد بطريقة ما. أنا في الغالب على رأي أنه إذا كنت تعرف كيفية القيام بذلك، فقد تفضل القيام بذلك بدلاً من استخدام mail-receiver.
حل آخر سيكون وجود عملية \u003cmail thing\u003e تعالج البريد لـ domain وترسل الباقي إلى mail-receiver، ربما تحت MX آخر.
بعد قضاء هذه الليلة في تجربة العديد من التركيبات، تمكنت من تثبيت postfix خارج الحاويات التي تعمل فيها Discourse ويمكنني إرسال البريد الإلكتروني عبر Mailgun بهذه الطريقة من سطر الأوامر، لذلك قمت بتكوين postfix لاستخدام Mailgun بنجاح. ما زلت أواجه صعوبة في محاولة إدخال الإعدادات في حاوية mail-receiver التي ستجعل إعادة التوجيه تعمل عبر Mailgun. أنا متأكد من أن هناك طريقة (بسيطة!). لا يبدو أنني أجد أي سجلات لمعرفة سبب تعليق الرسائل في قائمة انتظار البريد. لم تكن الحاويات موجودة في المرة الأخيرة التي استخدمت فيها لينكس (قبل عدة سنوات). هل هناك طريقة لتشغيل التسجيل حتى أتمكن من رؤية الاتصال الذي يحاول postfix إجراؤه حتى أتمكن من معرفة المشكلة؟ من الناحية المفاهيمية، أود أن يذهب admin@mydomain، بمجرد وصوله، مباشرة إلى حساب Gmail الشخصي الخاص بي عبر Mailgun مع category1@mydomain و category2@mydomain وما إلى ذلك ليتم دفعها محليًا إلى Discourse لاستخدامها لإنشاء مشاركات.
هل يمكننا استخدام “مستقبل البريد” خارج حاويات Discourse في خادم افتراضي خاص (VPS) آخر أو مركز بيانات آخر؟
الفكرة هي تغيير عنوان IP الخاص بـ Discourse لمزيد من الخصوصية واستخدام “مستقبل البريد” الخارجي الذي يعمل/المصادقة مع منتدى Discourse.
لقد قمت بإعداد مستلم البريد لأنه سريع وبسيط.. ولكن عندما أذهب للتحقق من رسائل البريد الإلكتروني المعالجة، فإنه يعطيني 404؛
موقعي هو نطاق فرعي مثل؛ forum.site.com
وفي تطبيق مستلم البريد لدي هذا لنقطة النهاية؛
عادةً، يجب أن تتطابق لافتة EHLO مع MAIL_DOMAIN والتي بدورها يفترض أن تتطابق مع مؤشر DNS العكسي (سجل PTR). لذا إذا كان mail-receiver الخاص بي يعمل على discourse.example، فيجب أن يكون POSTCONF_myhostname هو discourse.example.
ما هي الطريقة الصحيحة لتكوين لافتة EHLO؟
كان حدسي الأول هو محاولة تعيين HOSTNAME في mail-receiver.yml حتى يتم استبدال host-mail-receiver.localdomain الأصلي في /etc/postfix/mail-receiver-environment.json. لكن هذا لا يغير /etc/hostname ولا يغير myhostname في تكوين Postfix.
أنا متردد في استخدام POSTCONF_myhostname ولكني أخشى أن يكون له آثار جانبية غير مرغوب فيها نظرًا لاستخدام $myhostname في عدة أماكن ولن يتطابق بعد ذلك مع /etc/hostname.
يقوم إعداد Postfix smtp_helo_name بتغيير الاسم المحدد في أمر HELO (أو EHLO)، ولكن هذا إعداد تسليم خارجي، بينما يتم إرسال لافتة SMTP عند استقبال البريد. يتم أخذ اسم المضيف الافتراضي المحدد في ذلك من myhostname، ولكن يمكنك تعديل اللافتة لعرض شيء مختلف باستخدام إعداد smtpd_banner.
لست متأكدًا مما إذا كان هذا سيساعد الآخرين، كنت أواجه مشكلة مماثلة وساعدني هذا في إدراك أنني قمت بإلغاء مفتاح واجهة برمجة التطبيقات لسبب ما. بمجرد أن ألغيت الإلغاء، عادت رسائل البريد الإلكتروني الواردة للعمل مرة أخرى.
لذلك شكراً لمساعدتي في إدراك أن الأمر كان متعلقًا بمفتاح واجهة برمجة التطبيقات
هل تغير شيء ربما منذ كتابة هذا؟ لقد وجدت للتو أن إضافة قيمة POSTCONF_smtpd_banner تحت env: لم يتم التقاطها على الإطلاق بواسطة عمليات إعادة تشغيل متعددة. اضطررت إلى إعادة البناء (./launcher rebuild mail-receiver) لجعلها سارية المفعول.
على حد علمي، يقوم التكوين الافتراضي للحاوية بتثبيت كل من النطاق الوارد ومسار شهادات LetsEncrypt بشكل ثابت. هل من الممكن السماح بنطاقين، إما في التكوين، أو عبر هذه الخيارات المتقدمة؟
