كيف يتم القيام بذلك لإنشاء تعريف حاوية جديد في هذا الدليل؟!
عن طريق تشغيل الأوامر المعروضة مباشرة بعد هذا النص. بالمعنى الدقيق للكلمة، أنت لا تنشئ الملف في هذا الدليل ولكن داخل الدليل الفرعي containers، بنفس طريقة app.yml.
3 إعجابات
شكرًا، في البداية لم يبدُ أن هذه تعمل ولكنها وصلت الآن إلى محرر النصوص باستخدام:
يبدو أن هناك مشكلة في هذا، عند تشغيل
./launcher logs mail-receiver
يُبلغ عن discourse_base_url=https://discourse.example.com، بدلاً من النطاق المحدد في محرر النصوص.
حاولت إعادة بناء/إعادة تشغيل bootstrap لـ mail-receiver ولكنها لم تتغير إلى النطاق الصحيح.
إعجاب واحد (1)
لدي مشكلة بسيطة، هل يمكنني الحصول على بعض النصائح!
root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.
starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver
ثم…
root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 4400 root 13u IPv4 24419 0t0 TCP *:smtp (LISTEN)
master 4400 root 14u IPv6 24420 0t0 TCP *:smtp (LISTEN)
لقد حاولت أيضًا…
root@JEN /var/discourse # netstat -nlp | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 4400/master
tcp6 0 0 :::25 :::* LISTEN 4400/master
و…
root@JEN /var/discourse # ps j 4400
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 4400 4400 4400 ? -1 Ss 0 0:02 /usr/lib/postfix/sbin/master -w
أجد تعليمات عبر الإنترنت لإيقاف الحاوية وقتل العملية (العملية 4400؟)
هل هذا آمن، وهل سيصحح المشكلة؟
هل أحتاج إلى (أو هل يجب علي، أو لا يجب علي) تغيير المنفذ 25 إلى منفذ مختلف في ملف mail-receiver.yml؟
إعجاب واحد (1)
ربما قمت بتثبيت postfix وتحتاج إلى إزالته؟
لا يمكنك تغيير المنفذ. تحتاج إلى إيقاف أي شيء يستخدمه. مجرد إنهاء العملية لن ينجح لأنه عند إعادة التشغيل، ستكون هناك منافسة لمعرفة أي عملية تبدأ أولاً.
3 إعجابات
هذا ما كنت أفكر فيه أيضًا. لا أستطيع أن أتخيل كيف وصل إلى هناك، لكنني سأحاول إزالته. بخلاف ذلك، يمكنني فقط استخدام Gmail الذي يبدو أنه يعمل بشكل جيد.
إعجابَين (2)
لقد قمت للتو بنقل المنتدى الخاص بي إلى بيئة جديدة ونتيجة لذلك أعدت تثبيت مستلم البريد. يبدو أنه إصدار أحدث مما قمت بتثبيته سابقًا. لقد تغير تكوين YML قليلاً مع استبدال DISCOURSE_BASE_URL بـ DISCOURSE_MAIL_ENDPOINT. محتويات ملف YML تعكس التغيير ولكن التعليمات في أعلى هذا الموضوع تحتاج إلى تحديث.
أيضًا عند تلقي بريد إلكتروني تم إرجاعه / رفضه ، أحصل على الأخطاء التالية …
Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
يبدو أن الرسائل الصالحة يتم التعامل معها بشكل صحيح. لم يعط الإصدار السابق من مستلم البريد هذه الأخطاء على حد علمي من سجلات الملفات الأخيرة. لقد أجريت بعض الأبحاث ووجدت - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/
يبدو أن إضافة ما يلي إلى ملف mail-receiver.yml يحل المشكلة بالنسبة لي:
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
4 إعجابات
إسقاط منشور هنا للإشارة إلى أننا أضفنا دعم DMARC إلى مستلم البريد عبر صورة discourse/mail-receiver:with-dmarc. يرجى الرجوع إلى Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver في المنشور الأصلي لمزيد من التفاصيل.
3 إعجابات
تم دمج منشورين في موضوع موجود: Mail-receiver relay access denied
أردت إضافة شيء ما إلى قسم استكشاف الأخطاء وإصلاحها.
كان Mail-Receiver (التسليم المباشر) يعمل لعدة نطاقات ولكنه لم يكن يستقبل رسائل من مستخدمي Gmail. لم أتمكن من معرفة السبب. لم يكن هناك شيء في السجلات سوى اتصال/قطع اتصال من Google. بدا كل شيء جيدًا وأكدت الأدوات عبر الإنترنت أن DNS كان جيدًا.
في النهاية، قمت بإنشاء سجل تقرير SMTP TLS في DNS على سبيل المثال
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
بعد بضع ساعات، أرسلت Google (Gmail) تقريرًا يوضح أنها قامت بتخزين سياسة mta-sts مؤقتًا لم تعكس سجلات MX الحالية. كنت قلقًا من أن Google ستحتفظ بهذه السياسة المخزنة مؤقتًا لمدة أسبوع لأنها بدت وكأنها تجاهلت سجل DNS المحدث الخاص بي _mta-sts الذي كان يجب أن يتسبب في تحديث.
وبعد ذلك بوقت قصير، بدأت كل رسائل Gmail الاحتياطية الخاصة بي تتدفق إلى Discourse دون أن أفعل أي شيء على الإطلاق. ساعدني التقرير في فهم وجهة نظر Google بشأن المشكلة وأنقذني من حك رأسي عندما بدأت الرسائل في التدفق.
يتم إصدار تقارير SMTP TLS بشكل غير متكرر، لذا كن صبورًا.
3 إعجابات
بالنظر إلى أن الدليل لا يذكر شيئًا عن تكوين MTA STS، ألن يؤدي إضافة خطوات تشخيصية له إلى إرباك أكثر من 99.999% من المستخدمين الذين لا يقومون بتكوينه؟
إعجابَين (2)
في حالتي، كان مجرد إضافة سجل DNS واحد كافيًا لتسليط الضوء على مشكلتي. بالنظر إلى أن الدليل يوجه بالفعل لإنشاء سجلات DNS لتثبيت Mail-Receiver، فإن اقتراح إضافة سجل في قسم استكشاف الأخطاء وإصلاحها كحل أخير لا يبدو مبالغًا فيه. ومع ذلك، أرى أن منشورك حصل على إعجابين بينما لم يحصل منشوري على أي إعجاب، لذلك قد يكون هذا هو نهاية الأمر.
إعجاب واحد (1)
هذه أخبار جيدة، يبدو أن هذه معلومات جيدة لإضافتها إلى الدليل خاصة وأن Gmail هو مرسل شائع.
الدليل يوجه إلى إنشاء سجلات DNS لجعل mail-receiver يعمل، وليس لتكوين MTA STS. لذلك، لن يواجه المستخدم الذي يتبع الدليل المشكلة التي واجهتها أبدًا. ومن ثم، لا داعي لتعقيد الدليل بخطوات إضافية غير ضرورية.
إعجاب واحد (1)
بشكل عام، هل يمكن لمستقبل البريد معالجة رسائل Gmail المرسلة إلى مواضيع جديدة؟
يبدو أن هذه مشكلة كبيرة، ولكن ليس إذا كان سبب هذه المشكلة حادثًا معزولًا.
لقد توصلت إلى استنتاج مفاده أن مات على حق. كان تثبيتي بحاجة تحديدًا إلى التعامل مع MTA-STS لأن البريد العادي لنطاقه تتم معالجته بواسطة Mail In a Box https://mailinabox.email/ والذي يصر على سياسة MTA-STS صارمة وتفرض Gmail هذه السياسة. افتراضيًا، يمكن أن تتعارض السياسة مع تكوين Mail-Receiver. معظم النطاقات لن يكون لديها سياسة. إذا كان النطاق يحتوي على سياسة، فستكون مرئية على
https://mydomain.com/.well-known/mta-sts.txt
تبدو سياستي العاملة كالتالي…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
آمل أن أقوم بترقية “mode: none” إلى “mode: enforce” بعد المزيد من العمل.
إعجابَين (2)
هل يمكن لأحد أن يذكرني – عندما نعيد بناء Discourse من سطر الأوامر، هل يعيد بناء حاوية mail-receiver تلقائيًا، أم نحتاج إلى القيام بذلك بشكل منفصل؟ شكرًا.
لا، بل يعيد البناء فقط عندما تخبره بذلك. لا تحتاج إلى إعادة بناء مستقبِل البريد كثيرًا.
إعجابَين (2)
لقد ساعدني بالتأكيد:)
إعجاب واحد (1)