فتح طلب ميزة جديد هنا، حاليًا يسمح Discourse بعنوان بريد إلكتروني واحد فقط يُستخدم لكل من envelope-from و reply-to. إذا أراد موقع ما استخدام خادم SMTP الخاص به لإرسال رسائل البريد الإلكتروني ولكن يريد إرسال ردود البريد الإلكتروني إلى نطاق مختلف (على سبيل المثال، Gmail)، فستفشل رسائل البريد الإلكتروني المرسلة في DMARC. من خلال فصل هذين حقلي الرأس، سيتم تجنب فشل DMARC ولن يتم فقدان القدرة على معالجة رسائل البريد الإلكتروني المرتدة.
مزيد من التفاصيل حول هذا الموضوع
لا أرى كيف سيتم التعامل مع الارتدادات في هذا السيناريو. تذهب الارتدادات إلى الظرف المرسل إليه، وليس إلى العنوان الموجود في “الرد على”. لذلك، إذا لم يكن الظرف المرسل إليه لديك قادرًا على التعامل مع البريد الإلكتروني الذي تم وضع علامة VERP عليه، فستظل في مشكلة.
في الموضوع الذي تشير إليه، لا تشرح لماذا لا يعمل توقيع DKIM مقابل النطاق الموجود في رأس From:. يجب أن يوفر هذا محاذاة DMARC، حتى لو فشل SPF. هذا هو النهج الذي سأتخذه، إذا كنت في موقفك (إما ذلك، أو اللجوء إلى مسؤولي خادم SMTP الوارد لـ yyy.com بمذراة؛ ما نوع MTA الذي لا يدعم أي نوع من العنونة التفصيلية؟!).
سيعمل لأن خادم نقل البريد (MTA) يدعم “التقاط الكل”. بينما لا يدعم VERP، يمكن تكوينه لإعادة توجيه جميع رسائل البريد الإلكتروني غير المحددة إلى بريد إلكتروني معين، لذلك لن تضيع ردود الارتداد.
أيضًا، إذا فصلنا envelope-from و reply-to، فلن يحتاج envelope-from إلى احتواء عنوان VERP. يمكن أن يكون عنوانًا بسيطًا مثل discourse@yyy.com. لذلك عندما يرتد مرة أخرى يعود إلى discourse@yyy.com الذي لن يفشل SPF.
يمكن أن يحتوي reply-to على بريد إلكتروني مختلف يدعم VERP مثل discourse-yyy+sdfkj33@gmail.com لذلك إذا تم تسليمه بنجاح عندما يرد المستخدم، فإنه يأتي إلى خادم gmail الذي يدعم VERP ولن يفشل DMARC نظرًا لأن from لا يزال yyy.com.
أتفق، لكننا لا نصنعها. نظرًا لأنها تحتوي على عنونة “التقاط الكل”، فلن تدعم VERP. للأسف هذا هو الوضع، آمل أنه من خلال تعديل بسيط ستتمكن Discourse من دعم نظام بيئي أكثر تنوعًا. سيكون العديد من المواقع الصغيرة التي تستخدم gmail للتعامل مع الردود في هذا الموقف.
إذا كان MTA الخاص بك يدعم التقاط الكل، فلماذا لا يمكنك إعادة توجيه الردود بنفس الميزة، والتخلي عن Gmail تمامًا؟
عنوان المرسل الظرفي هو العنوان الذي يجب أن يدعم VERP، لأن الطريقة الوحيدة لتحديد سبب الارتداد بشكل موثوق هي عبر المعلومات الموجودة في عنوان المرسل الظرفي للبريد الإلكتروني الأصلي، كما أوضح مايكل سابقًا Michael previously explained.
لدي شكوك حول هذا التأكيد. استخدام عنوان Gmail للردود هو أمر غير احترافي، وكان دائمًا غير احترافي؛ فإن mail-receiver هو طريقة أكثر مباشرة وموثوقية وأقل تعقيدًا للتعامل مع الردود (والارتدادات).
حتى بالنسبة لتلك المواقع الصغيرة التي تستخدم Gmail، فإن المواقع الصغيرة جدًا ربما تتجاهل شروط الخدمة وتستخدم Gmail لإعادة التوجيه الصادر أيضًا، والغالبية العظمى من الباقين ربما لا يخضعون لـ MTA الذي لا يدعم عنونة التفاصيل.
لأنها “الكل” (catch all) للنطاق، ويتم استخدام بريد إلكتروني واحد فقط لـ discourse.
ليس بالضرورة، أنا أستخدمه حاليًا بدون VERP وهو يعمل. مشكلتي هي أنني لا أستطيع جعل المستخدم يرد مباشرة على Gmail دون فشل SPF / DMARC بسبب الطريقة التي يحدد بها discourse عناوين envelope-from و reply-to. بدلاً من ذلك، يجب أن أقوم بإعادة توجيه البريد من خادم البريد إلى Gmail. إذا كان بإمكاني جعله يرد مباشرة على Gmail (دون فشل DMARC/SPF) فيمكنني استخدام VERP لتأمين الردود ولكن نعم سيتم تجاهل VERP للبريد المرتد. لا يزال أكثر أمانًا من التنفيذ الحالي.
هذا ليس خيارًا كما شرحت هنا. من العملي فقط استخدام Gmail للبريد الوارد. إعداد خادم MX خاص بك للبريد الوارد عندما يكون لديك بالفعل خادم MX من مزود الاستضافة الخاص بك يمكن أن يكون صعبًا لغير المتمرسين. الردود المباشرة من Gmail أسهل بكثير وأقل عرضة للخطأ.
ربما فاتني شيء في طريقة تفكيرك. لا أرى سوى إيجابيات في فصل عناوين envelope-from و reply-to، فهي تدعم أنظمة بيئية أكثر تنوعًا وهي أكثر أمانًا مع المساعدة في تجنب فشل SPF/MARC.
خطي في التفكير هو أن الإجابة الصحيحة لمشكلتك، كما تم التعبير عنها حتى الآن، هي إعداد DKIM. إن جعل تكوين البريد الإلكتروني أكثر تعقيدًا وعرضة للخطأ لا يبرره استخدامك، في رأيي.
تم إعداد DKIM بالفعل، المشكلة هي فشل SPF.
ستوفر إضافة حقل إضافي لفصل عناوين envelope-from و reply-to قدرًا كبيرًا من المرونة وتمكين SPF من النجاح أيضًا (والذي لن ينجح إذا كان لديك خادم SMTP يقوم بإعادة توجيه رسائل البريد الإلكتروني أو لا يدعم VERP). يمكن إخفاء الحقل في واجهة المستخدم أو حتى تعيينه لمطابقة عناوين envelope-from و reply-to ما لم يقرر المسؤولون تجاوزها بشكل خاص. يمكن أن تشير الوصف إلى هذه الصفحة. ومع ذلك، لا أرى كيف سيجعل الأمر أسوأ، بل يمكن أن يتحسن فقط - إما أنهما متماثلان (وفي هذه الحالة سيفشل SPF في أي سيناريوهات موصوفة هنا) أو أنه سيحسن قابلية التسليم.