أحاول معرفة كيفية قيام discourse بتنظيف قوائم البريد الإلكتروني، وتحديداً رسائل البريد الإلكتروني المرتدة. يستخدم الموقع خادم smtp خاصًا لإرسال رسائل البريد الإلكتروني ولكن الاستجابة تم تعيينها للعودة إلى عنوان بريد إلكتروني في gmail للوصول عبر POP بواسطة discourse.
لذلك أرى رسائل البريد الإلكتروني المرتدة في لوحة تحكم رسائل البريد الإلكتروني المستلمة.
يستخدم Discourse reply_key لربط الارتدادات بالرسائل المرسلة. عندما يرسل Discourse بريدًا، فإنه يستخدم قيمة reply_by_email_address كمرسل مظروف SMTP.
تحتاج إلى التأكد من أن reply_by_email_address الخاص بك يتضمن {reply_key} حتى يتمكن مثيلك من ربط الارتدادات بالبريد المرسل الصحيح.
على سبيل المثال، هنا في meta تم تعيينه على incoming+%{reply_key}@meta.discoursemail.com ويتم تسليم أي شيء تم تعيينه إلى هذا العنوان إلى هذا المثيل.
شكراً على الرد. للأسف اضطررت إلى إيقاف تشغيل reply_key من الرد على البريد الإلكتروني لأن خادم البريد المرحل لدينا لا يتعرف على العنوان +. هل هناك أي خيار آخر؟
لا ينبغي أن يكون خادم ترحيل البريد الإلكتروني الخاص بك مهمًا، فقط الخادم النهائي حيث يوجد صندوق البريد. أجزاء محلية من البريد الإلكتروني غير شفافة لأي خوادم وسيطة.
أليس هو Gmail وفقًا لـ:
لست متأكدًا مما إذا كان لدينا آلية أخرى للكشف الموثوق عن الارتدادات.
حسنًا للتوضيح، خادم نطاق SMTP الوجهة الذي يستقبل البريد المرتد لا يتعرف على + في العنوان، لذلك يقوم فقط بإعادة توجيه رسائل البريد الإلكتروني بناءً على حقل To إلى عنوان Gmail الذي تلتقطه Discourse عبر POP. هذا يعني إذا كان حقل To يتضمن reply_key فلن يقوم بإعادة توجيه هذا البريد الإلكتروني إلى حساب Gmail الذي تستخدمه Discourse.
إذن لا يمكنني وضع reply_key في عنوان البريد الإلكتروني، هل يمكن وضعه في مكان آخر؟ في حقل الموضوع أو نص الرسالة أو في مكان ما يمكن لـ Discourse تحليله؟
البريد الإلكتروني المرسل بواسطة Discourse يأتي من discourse@xxx.com عبر خادم SMTP مخصص تم إعداده لـ Discourse (باستخدام عنوان نطاق Discourse).
أي ردود أو عند ارتداد البريد الإلكتروني، يقوم خادم SMTP الخاص بالنطاق بإعادة توجيه البريد الإلكتروني إلى discourse.xxxx@gmail.com. لا يمكن لخادم SMTP الخاص بالنطاق هذا التعرف على معالجة +، لذلك إذا قمت بتضمين reply_key في عنوان البريد الإلكتروني للرد، فسيتم إسقاطه بواسطة خادم SMTP الخاص بالنطاق. يمكنني فقط تعيين قواعد لإعادة توجيه عناوين البريد الإلكتروني الواردة المنفصلة/الفريدة.
يواصل منتدى Discourse بعد ذلك استخدام POP عبر GMail للوصول إلى تلك الردود المعاد توجيهها/رسائل الارتداد وتحليلها.
أنا أفهم ما تقوله. للأسف، بسبب قيد في قواعد خادم SMTP، لا يمكنني إعداد إعادة التوجيه للنطاقات الفرعية، يمكنني فقط تكوينه لإعادة توجيه معرفات البريد الإلكتروني الفريدة في حقل إلى.
ومع ذلك، لدي توضيح هنا - أشبه بتناقض في كيفية عمل Discourse:
عندما يرد مستخدم على منشور بريد إلكتروني، فإنه يصل بشكل صحيح - تبدو الردود تعمل بشكل مثالي حتى بدون أي {reply_key} تم تكوينه صراحة في أي مكان (انظر لقطات الشاشة أعلاه).
ومع ذلك، عندما يرتد بريد إلكتروني، يصنفه Discourse تحت تم الاستلام بدلاً من تم الارتداد.
تظهر سجلات الأخطاء أن شيئًا ما في Discourse يتعرف على أنه بريد إلكتروني مرتد (انظر سجل خطأ مشاركتي الأولى). لذا، إذا كان شيء ما في Discourse يتعرف على أنه بريد إلكتروني مرتد، فلماذا لا يظهر تحت تم الارتداد بدلاً من تم الاستلام؟
إذًا، لماذا عندما يرد مستخدم على منشور تتم معالجته بشكل صحيح بواسطة Discourse ولكن ليس البريد الإلكتروني المرتد (ويبدو أيضًا أن هناك انفصالًا بين سجلات الأخطاء ولوحة المعلومات للبريد الإلكتروني المرتد). هل فاتني شيء في التكوين؟
لقد حاولت أيضًا تعيين إعدادات عنوان البريد الإلكتروني للرد في discourse إلى discourse.xxx+%{reply_to}@gmail.com ولكن عندما يتم تسليم البريد الإلكتروني، يبدو أن Gmail يعتقد أن النطاق yyy.com (نطاق SMTP الخاص بـ discourse) يحاول انتحال نطاق Gmail وينتهي به الأمر بتمييزه كرسائل غير مرغوب فيها. يبدو أن تعيين نطاق رد مختلف عن نطاق المرسل يؤدي إلى فشل DMARC و SPF.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
لقد قمت بتعطيل find related posts with key (آمل أن تكون قد قرأت التحذير) وبالتالي يستخدم Discourse رأس البريد الإلكتروني in-reply-to لتحديد الموضوع/المنشور الذي يجب أن يشير إليه الرد.
لا يمكنه فعل ذلك للبريد المرتد - يحتاج Discourse إلى معرفة الرسالة المحددة التي ارتدت وهذه المعلومات مضمونة فقط في مكان واحد - العنوان To: (الذي يأتي من عنوان envelope-from للرسالة الأصلية).
لكي يعمل هذا، عندما يرسل Discourse رسالة، يحتاج إلى تلقي الرد من العنوان الذي جاء منه. يبحث Discourse في رأس To: عن هذا (وليس envelope-to).
نعم، تم تكوينه، والبريد الإلكتروني “المرسل” بواسطة Discourse عبر خادم SMTP الخاص بـ yyy.com يمر عبر SPF و DKIM و DMARC دون مشاكل (على الأقل من صفحة “إرسال بريد إلكتروني تجريبي” في لوحة تحكم المسؤول).
تحدث هذه المشكلة إذا قمت بتعيين عنوان Gmail كـ reply_by_email_address إلى عنوان gmail.com بدلاً من عنوان yyy.com. هل هناك شيء يمكنني فعله لهذا الإعداد بحيث لا يفشل DMARC عند تعيينه كـ reply_by_email_address إلى عنوان Gmail مع الاحتفاظ بالخادم الصادر كـ yyy.com؟
ألا يمكنه تحليل بقية المحتوى/المرفقات في البريد الإلكتروني المرتد لاستخراج تلك المعلومات إذا لم يتمكن من العثور على ما يحتاجه في المكان “الواضح” (أو على الأقل توفير خيار في الإعدادات للقيام بذلك مع التحذيرات اللازمة حول انتحال الشخصية)؟
إذا كنت أفهم هذا بشكل صحيح، فيجب تعيين reply_by_email_address في حقل reply-to الخاص بالبريد المرسل بواسطة Discourse (من yyy.com). لذلك عندما يرد المستخدم، فإنه يرد على البريد الإلكتروني reply-to (gmail.com) بدلاً من العنوان الأصلي (yyy.com). لذلك في البريد الإلكتروني للرد، يجب أن يكون عنوان from هو عنوان البريد الإلكتروني للمستخدم و to هو عنوان gmail.com.
لماذا يتم استخدام reply_by_email_address كعنوان from؟
إذًا، بشكل أساسي، يتم استخدام reply_by_email_address في رأس المرسل (from header) بحيث يعود إلى عنوان البريد الإلكتروني هذا إذا تم الارتداد. ويتم تعيين نفس عنوان البريد الإلكتروني أيضًا في رأس الرد (reply-to header) إذا تم تمكين الردود عبر البريد الإلكتروني.
لذلك، إذا كان فهمي أعلاه صحيحًا، فعندئذٍ إذا كان بإمكان discourse الحصول على إعداد منفصل (reply_to_email) لرأس الرد (reply-to)، فسيؤدي ذلك إلى حل مشكلة فشل DMARC. عند استخدام النطاق yyy.com (المأخوذ من reply_by_email_address) للمرسل (from) أثناء الإرسال و gmail.com للرد (reply-to) (المأخوذ من إعداد reply_to_email جديد). إذا تم ارتداد البريد الإلكتروني، فسيظل يعود إلى reply_by_email_address ولكن إذا رد المستخدم، فسوف يذهب إلى reply_to_email.
لجتياز DMARC، يجب أن يكون إما SPF (الذي يتحقق من صحة envelope-from بالاقتران مع عنوان IP المرسل) أو DKIM (الذي يتحقق من صحة حقول From والمجموع الاختباري للرسالة) متوافقًا.
يبدو أن الهدف الأساسي من هذه العملية هو الحصول على عنوان “جميل” للرد (reply-to)، والذي يرد عليه المستخدمون؟
هل تريد شيئًا كهذا؟
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
يجب أن يكون لديك envelope-from بهذا الشكل، وإلا فلن تعمل عمليات الرفض.
نعم، هذا صحيح. الفكرة هي أن يكون envelope-from مختلفًا عن reply-to.
نظرًا لأن نطاق envelope-from وعنوان IP المرسل يتطابقان، يجب أن ينجح SPF ولكن في نفس الوقت يمكن أن يذهب الرد إلى GMail للمعالجة، وإذا ارتد البريد الإلكتروني، فسيعود إلى خادم النطاق الأصلي الذي يمكنه بعد ذلك إعادة توجيه الارتداد مرة أخرى إلى صندوق الوارد الخاص بـ GMail أيضًا.
سيبدو الأمر في الواقع كالتالي:
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
في إعداداتي، لن يحتوي البريد الصادر على VERP لأن خادم SMTP الوارد الخاص بي لا يدعم VERP (أي أن الارتداد لن يحتوي على عنوان VERP)، وهذا هو سبب إرسال reply-to إلى GMail لأنه يدعم VERP. لا ينبغي أن يتسبب هذا في فشل DMARC كما يحدث الآن.
