تخصيص تكوين Postfix للتوصيل المباشر

[mpalmer (Matt Palmer)]

If you have a mail receiver container which requires customised Postfix configuration, this is the topic for you. Herein are described the steps required to set Postfix main.cf configuration variables to whatever your heart desires.

Postfix configuration variables can be set via the container environment. Any environment variable starting with POSTCONF_ will set a Postfix configuration variable named for the rest of the environment variable to the value of the environment variable. For example, if you set the environment variable POSTCONF_always_bcc to bob@example.com, then Postfix will be configured with always_bcc = bob@example.com, which will send a copy of all incoming mail to Bob. Poor Bob.

Procedure

1. Figure out what configuration variables you want to set, and what values to set them to. This may be done by reading the fine manual, or through recommendations in other Discourse documentation, or otherwise.

2. Connect to your Discourse server via SSH, grab some root privileges, and head over to where all the discourse-docker configuration lives:

   ssh ubuntu@192.0.2.42
   sudo -i
   cd /var/discourse
   

3. Open up containers/mail-receiver.yml in your text editor of choice, and swing down to the env: section of the file. Somewhere in there, add entries for the variables you want to add, being careful to not modify anything else, and maintaining appropriate indenting. For example, if we were adding our always_bcc setting, the file might look a bit like this:

   env:
     LANG: en_US.UTF-8
     MAIL_DOMAIN: discourse.example.com
     DISCOURSE_BASE_URL: 'https://discourse.example.com'
     DISCOURSE_API_KEY: abcdefghijklmnop
     DISCOURSE_API_USERNAME: system
   
     POSTCONF_always_bcc: 'bob@example.com'
   

   Once you’re happy with what you’ve added, save and exit your editor.

4. To load the configuration, you simply have to restart the mail-receiver container (a rebuild is not required):

   ./launcher restart mail-receiver
   

   After a brief spasm, the container should be running again.

5. Test your changes. Ensure both that what you wanted to have happen has, indeed, happened, and also that nothing you didn’t expect to change hasn’t.

Addendum: adding files to the mail-receiver container

Many Postfix configuration parameters require access to “database files”, which provide key/value information which Postfix uses to make decisions about what do with mail. If you see that a configuration parameter accepts a filename that looks like hash:/some/file, you’ve found a use for database files.

The thing is, Postfix running inside the container needs to be able to get at those files while it’s running, which means you need to either copy those files into the container, or (preferably) put those files into a directory on the host, and then mount that directory as a volume inside the container. These instructions describe the second method.

Once you have completed this procedure, any file you place into /var/discourse/shared/mail-receiver/etc will immediately become visible at /etc/postfix/shared inside the container, and any changes you make to those files will be immediately visible to Postfix.

Here’s how to make it happen.

1. If you’re not still logged in as root to your Discourse server, do so again:

   ssh ubuntu@192.0.2.42
   sudo -i
   cd /var/discourse
   

2. Open up containers/mail-receiver.yml in your text editor of choice, and this time head for the volume: section. Underneath the existing definition for the /var/spool/postfix directory, add another one, so that your volume section looks like this:

   volumes:
     - volume:
         host: /var/discourse/shared/mail-receiver/postfix-spool
         guest: /var/spool/postfix
     - volume:
         host: /var/discourse/shared/mail-receiver/etc
         guest: /etc/postfix/shared
   

   Save/exit your editor.

3. To attach the new volume, you simply have to restart the mail-receiver container (a rebuild is not required):

   ./launcher restart mail-receiver
   

All done!

[satonotdead]

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).

Thanks for all your guides related.

[markcoley]

لقد قمت للتو بإعداد خدمة 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 القيام به.

أي تلميحات مقدرة حول كيفية القيام بذلك!

[pfaffman (Jay Pfaffman)]

@markcoley

الكلمات “(خطأ غير معروف في نقل البريد)” ثم عنوان البريد الإلكتروني الذي كان لدي في إعداد always_bcc.

هممم. نعم، أولاً ستحتاج إلى تكوين مستلم البريد mailgun ليكون لديه بعض الوسائل لتسليم البريد، لأنه لا يعرف بيانات الاعتماد أو آلية النقل في app.yml. أعتقد أنك ستحتاج إلى إضافة تكوين أكثر اكتمالاً كما هو مشار إليه في القسم التالي حول تحميل وحدات التخزين، وتفاصيلها خارج نطاق هذه الوثيقة.

الحل البسيط لـ “كيف أتعامل مع رسائل البريد الإلكتروني الخاصة بـ postmaster و admin” هو إنشاء مجموعة لكل منها وإضافة كل من تريد أن يتلقى هذه الرسائل إلى تلك المجموعة ويمكنهم التعامل معها كرسائل جماعية.

[markcoley]

@pfaffman

أولاً، ستحتاج إلى تكوين mailgun

هل تقصد ‘mail-receiver’ بدلاً من Mailgun؟ كما في تعليم ‘mail-receiver’ كيفية التحدث إلى Mailgun عبر الإنترنت العام وتمرير بيانات الاعتماد بشكل صحيح لطلب منه إجراء عمليات التسليم الفعلية؟

[pfaffman (Jay Pfaffman)]

@markcoley

هل قصدت ‘mail-receiver’ بدلاً من Mailgun؟

نعم. آسف لذلك.

@markcoley

كما في تعليم ‘mail-receiver’ كيفية التحدث إلى Mailgun عبر الإنترنت العام وتمرير بيانات الاعتماد بشكل صحيح لجعله يقوم بالتسليم الفعلي؟

حسنًا نعم، ذلك، أو بطريقة أخرى، قم بتكوين mail-receiver (أي Postfix) لتسليم البريد بطريقة ما. أنا في الغالب على رأي أنه إذا كنت تعرف كيفية القيام بذلك، فقد تفضل القيام بذلك بدلاً من استخدام mail-receiver.

حل آخر سيكون وجود عملية \u003cmail thing\u003e تعالج البريد لـ domain وترسل الباقي إلى mail-receiver، ربما تحت MX آخر.

[markcoley]

بعد قضاء هذه الليلة في تجربة العديد من التركيبات، تمكنت من تثبيت postfix خارج الحاويات التي تعمل فيها Discourse ويمكنني إرسال البريد الإلكتروني عبر Mailgun بهذه الطريقة من سطر الأوامر، لذلك قمت بتكوين postfix لاستخدام Mailgun بنجاح. ما زلت أواجه صعوبة في محاولة إدخال الإعدادات في حاوية mail-receiver التي ستجعل إعادة التوجيه تعمل عبر Mailgun. أنا متأكد من أن هناك طريقة (بسيطة!). لا يبدو أنني أجد أي سجلات لمعرفة سبب تعليق الرسائل في قائمة انتظار البريد. لم تكن الحاويات موجودة في المرة الأخيرة التي استخدمت فيها لينكس (قبل عدة سنوات). هل هناك طريقة لتشغيل التسجيل حتى أتمكن من رؤية الاتصال الذي يحاول postfix إجراؤه حتى أتمكن من معرفة المشكلة؟ من الناحية المفاهيمية، أود أن يذهب admin@mydomain، بمجرد وصوله، مباشرة إلى حساب Gmail الشخصي الخاص بي عبر Mailgun مع category1@mydomain و category2@mydomain وما إلى ذلك ليتم دفعها محليًا إلى Discourse لاستخدامها لإنشاء مشاركات.

[f1r4s (Eddie)]

هل يمكننا استخدام “مستقبل البريد” خارج حاويات Discourse في خادم افتراضي خاص (VPS) آخر أو مركز بيانات آخر؟
الفكرة هي تغيير عنوان IP الخاص بـ Discourse لمزيد من الخصوصية واستخدام “مستقبل البريد” الخارجي الذي يعمل/المصادقة مع منتدى Discourse.

[pfaffman (Jay Pfaffman)]

نعم. أنا أفعل ذلك بالضبط. لديّ مستلم البريد يعمل في DigitalOcean و Discourse على أجهزة في مركز بيانات آخر.

[f1r4s (Eddie)]

هل يمكن لأحد أن يشرح لي كيف أفعل ذلك؟ هذا الرجل يطلب المال حتى للرد علي.

[pfaffman (Jay Pfaffman)]

ما هو سؤالك؟

لا يلزم أي شيء خاص لتكوين مستلم البريد على أي خادم، طالما أنه يحتوي على دوكر والوصول إلى المنافذ اللازمة.

[f1r4s (Eddie)]

لقد قمت بإعداد مستلم البريد لأنه سريع وبسيط.. ولكن عندما أذهب للتحقق من رسائل البريد الإلكتروني المعالجة، فإنه يعطيني 404؛
موقعي هو نطاق فرعي مثل؛ forum.site.com
وفي تطبيق مستلم البريد لدي هذا لنقطة النهاية؛

DISCOURSE_MAIL_ENDPOINT: ‘http://forum.site.com/admin/email/handle_mail’

هل يجب علي إعادة بناء ديسكورس أيضًا؟

[pfaffman (Jay Pfaffman)]

إذا كنت تحصل على 404 فمن المحتمل أن يكون مفتاح واجهة برمجة التطبيقات (API) خاطئًا.

[f1r4s (Eddie)]

إنها واجهة برمجة تطبيقات افتراضية ولا تزال تعطيني 404 .. أرسلت لك في Google Talk، يرجى التحقق.

[hellekin]

تكوين لافتة SMTP؟

أداة SuperTool من MXtoobox تبلغ عن مشكلة في فحص لافتة SMTP.

عادةً، يجب أن تتطابق لافتة 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.

root@host-mail-receiver:/etc/postfix# postconf | grep myhostname
lmtp_lhlo_name = $myhostname
local_transport = local:$myhostname
milter_macro_daemon_name = $myhostname
myhostname = host-mail-receiver.localdomain
myorigin = $myhostname
smtp_helo_name = $myhostname
smtpd_proxy_ehlo = $myhostname
root@host-mail-receiver:/etc/postfix# cat /etc/hostname
host-mail-receiver

[pfaffman (Jay Pfaffman)]

هناك إعداد يطلبه Discourse-setup. لا أتذكر اسمه ومن الصعب العثور عليه على هاتفي. يمكنك النظر إلى المصدر أو تشغيله.

[mpalmer (Matt Palmer)]

يقوم إعداد Postfix smtp_helo_name بتغيير الاسم المحدد في أمر HELO (أو EHLO)، ولكن هذا إعداد تسليم خارجي، بينما يتم إرسال لافتة SMTP عند استقبال البريد. يتم أخذ اسم المضيف الافتراضي المحدد في ذلك من myhostname، ولكن يمكنك تعديل اللافتة لعرض شيء مختلف باستخدام إعداد smtpd_banner.

[jimkleiber]

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

لذلك شكراً لمساعدتي في إدراك أن الأمر كان متعلقًا بمفتاح واجهة برمجة التطبيقات

[ToddZ]

@mpalmer

لتحميل الإعدادات، ما عليك سوى إعادة تشغيل حاوية mail-receiver (لا يلزم إعادة بنائها)

هل تغير شيء ربما منذ كتابة هذا؟ لقد وجدت للتو أن إضافة قيمة POSTCONF_smtpd_banner تحت env: لم يتم التقاطها على الإطلاق بواسطة عمليات إعادة تشغيل متعددة. اضطررت إلى إعادة البناء (./launcher rebuild mail-receiver) لجعلها سارية المفعول.