أعمل مع مستخدم لاستكشاف مشكلة عدم استلام البريد الإلكتروني، وقد صادفت إجراء “سحب البريد الإلكتروني” المسجّل لحسابه. كيف يمكنني إلغاء أو التراجع عن هذا الإجراء؟
أيضًا: إذا تم سحب البريد الإلكتروني للمستخدم، هل ينعكس ذلك في سجلات “البريد الإلكتروني المرسل” أو “البريد الإلكتروني المتخطّى”؟ أم فقط في إجراء “سحب البريد الإلكتروني”؟
مواصلة النقاش من ما معنى إجراء ‘سحب البريد الإلكتروني’ في السجلات؟:
يتم تفعيل إجراء سحب البريد الإلكتروني عندما تفشل عدة رسائل إلكترونية مرسلة إلى مستخدم في الوصول (أي ترتد). مع كل مرة ترتد فيها رسالة، يتم زيادة “درجة الارتداد” للمستخدم إما بالقيمة المحددة في إعداد “درجة الارتداد الناعم” لموقعك أو بالقيمة المحددة في إعداد “درجة الارتداد الصلب”. بمجرد وصول درجة الارتداد للمستخدم إلى قيمة إعداد “عتبة درجة الارتداد” لموقعك (القيمة الافتراضية هي 4)، يتم تفعيل إجراء سحب البريد الإلكتروني.
يمكنك التراجع عن هذا الإجراء بالانتقال إلى صفحة إدارة المستخدم والضغط على زر “إعادة تعيين” الموجود في صف “درجة الارتداد” بالقرب من أعلى الصفحة.
إذا لم تضغط على زر إعادة التعيين، فسيقوم Discourse تلقائيًا بمسح درجة ارتداد المستخدم بعد مرور الفترة الزمنية المحددة في إعداد “إعادة تعيين درجة الارتداد بعد عدد الأيام”. القيمة الافتراضية لهذا الإعداد هي 30 يومًا. بعد انتهاء هذه الفترة، سيحاول Discourse إرسال رسائل إلكترونية إلى المستخدم مرة أخرى.
إذا لم يتم إرسال بريد إلكتروني إلى مستخدم تجاوز عتبة درجة الارتداد للموقع، فسيتم إضافة إدخال إلى سجلات المتخطى. وسيتم تعيين سبب التجاوز إلى “تجاوز عتبة درجة الارتداد”.
شكرًا لك. إذن، إذا رأيت عبارة “Exceeded bounce_score_threshold” في سجل “Skipped” لرسالة بريد إلكتروني حديثة مرسلة إلى المستخدم X، فهل يمكنني افتراض وجود إجراء “سحب البريد الإلكتروني” لهذا المستخدم سابقًا، والعكس صحيح؟
السياق هو أن أحد مستخدمينا لا يتلقى رسائل بريد إلكتروني من مثيل Discourse الخاص بنا. وهو كفؤ جدًا، لذا أنا أثق في تقاريره بأنه تفقد مجلد الرسائل غير المرغوب فيها وما إلى ذلك. لقد قمت بتصفير درجة الارتداد الخاصة به منذ فترة، لكنني لم أكتشف إجراء “سحب البريد الإلكتروني” في سجله إلا اليوم.
هذا مثير للاهتمام. كنت أفترض أن درجة الارتداد ستُعاد تعيينها لأولئك الذين لم يتم تعطيل بريدهم الإلكتروني بعد (مثل طريقة عمل Mailman). أعتقد أن أقرب حل هو ضبط هذا الإعداد على 10 سنوات تقريبًا!
بقدر ما أستطيع الجزم، فإن Discourse يعيد دائمًا تعيين درجة الارتداد للمستخدم ثم يحاول إعادة إرسال الرسائل الإلكترونية إليه. الفرق الوحيد بين معالجة الارتدادات المؤقتة والدائمة هو أن الارتدادات الدائمة تزيد درجة الارتداد بقيمة افتراضية مقدارها 2 (التي يتم تعيينها عبر إعداد الموقع hard bounce score) بدلاً من القيمة الافتراضية 1 (التي يتم تعيينها عبر إعداد الموقع soft bounce score).
هذا سيحقق المطلوب، لكنه قد يؤدي إلى عواقب غير مقصودة. على سبيل المثال، سيضطر المستخدمون الذين تجاوزوا bounce score threshold بسبب انقطاع Gmail الأخير إلى الانتظار لمدة 10 سنوات حتى تُعاد تعيين درجة الارتداد الخاصة بهم تلقائيًا.
يحتوي Mailman 2 على قيم افتراضية أعلى لإعدادات/عتبات الارتداد، ولكن بمجرد الوصول إليها، يتم إلغاء اشتراكك. يمكنني فهم الحجة في كلا الاتجاهين. تعديل: لا أتذكر التفاصيل بدقة، لكنني أعتقد أنه في مرحلة ما تُمنح فرصة للرد على بريد إلكتروني إداري يعيد تعيين درجة الارتداد الخاصة بك ويحافظ على بقائك في القائمة.
كثير من الأشخاص الذين يستضيفون Discourse بأنفسهم يستخدمون على الأرجح Mailgun، الذي سيحافظ على عنوان البريد الإلكتروني في قائمة الحظر لديه بعد فشل “دائم” واحد، وبالتالي سيتجاهل النهج الأكثر تساهلاً من Discourse.
يبدو أنه من الممكن الحصول على قائمة الحظر تلك باستخدام واجهة برمجة تطبيقات Mailgun، وأظن أنه قد يكون من الممكن أيضًا مزامنتها مع إعدادات Discourse.
تلقيت بريدًا إلكترونيًا من Google اليوم يؤكد بوضوح أن شخصًا ما حصل على كلمة مروري — “أصبحت Google على علم بأن شخصًا آخر يعرف كلمة مرورك” — لذا أتساءل عما إذا كان ذلك مرتبطًا بـ “انقطاع الخدمة”…
لاحظت للتو هذا: Configure VERP to handle bouncing e-mails - #166
يتعلق الأمر بإزالة إعداد bounce_score_threshold_deactivate. أتساءل عما إذا كان ذلك خطأً. إذا كان الإعداد الافتراضي صعب المنال، فإن الحل كان يكمن في خفضه.
قد تكون إحدى العواقب غير المقصودة لإزالة هذا الإعداد في المنتديات الكبيرة هي محاولة إرسال رسائل بريد إلكتروني إلى عدد متزايد من العناوين غير الصالحة بانتظام على مدار سنوات عديدة. إما أن هذا قد يؤدي إلى مشاكل مع خدمة خارجية (مثل Mailgun، التي تقوم بحظر عنوان بعد فشل دائم واحد في الارتداد) أو الإضرار بسمعة عنوان IP.
كما هو الحال الآن، ما لم أكن قد أسأت الفهم، فإن Discourse يعتقد أنه يرسل رسائل بريد إلكتروني يرفض Mailgun إرسالها ببساطة بسبب قائمة الحظر الخاصة به - ولا يمكن مزامنه نهج Discourse مع نهج Mailgun.
لقد نسيت ذلك. لست متأكدًا من أن إعداد bounce_score_threshold_deactivate كان يعمل على منع Discourse من محاولة إرسال رسائل بريد إلكتروني إلى عناوين غير صالحة. المشكلة هي أنه بمجرد وصول المستخدم إلى عتبة درجة الارتداد، سيتوقف Discourse عن إرسال رسائل البريد الإلكتروني إليه حتى يمر الفترة الزمنية المحددة بواسطة إعداد إعادة تعيين درجة الارتداد بعد أيام. في ذلك الوقت، ستتم إعادة تعيين درجة ارتداد المستخدم وستبدأ العملية من جديد.
لست متأكدًا من أفضل حل لهذه المشكلة. إذا كنت أفهم الأمور بشكل صحيح، فإن الأمر يبدو وكأنه مع مرور الوقت، سيحاول موقع Discourse إرسال رسائل بريد إلكتروني إلى عدد متزايد من العناوين غير الصالحة.
هنا جانبان على الأقل في هذه القضية. أحدهما هو ما هي السياسة الجيدة لمنصة Discourse، بافتراض أن مرسل البريد الإلكتروني (مثل localhost) سيتعاون مع ذلك. والآخر هو كيفية مزامنة الأمور مع خدمة إرسال بريد إلكتروني لن تتعاون مع ذلك (مثل Mailgun).
أعتقد أن هناك بالفعل رسالة في Discourse تقول شيئًا من قبيل: “يرجى التحقق من عنوان بريدك الإلكتروني حيث واجهنا مشكلة في الإرسال إليه.” ربما تحتاج Discourse إلى نهج أكثر حزمًا في تعطيل عناوين البريد الإلكتروني المرتدة، مقترنًا بإشعار موقع لا يمكن إغلاقه بشأن عدم إمكانية إرسال البريد الإلكتروني.
ستكون المزامنة مع المرسلين الخارجيين أكثر صعوبة. تقول Mailgun إنه من الممكن الحصول على قائمة الحظر الخاصة بهم من خلال واجهة برمجة التطبيقات الخاصة بهم لكنني لا أعرف بعد ما إذا كان من الممكن أيضًا إزالة العناوين عبر واجهة برمجة التطبيقات. إذا كان من الممكن القيام بكليهما، فإن Discourse يمكنها تعطيل عنوان بريد إلكتروني بمجرد دخوله قائمة الحظر، وإزالته من قائمة الحظر عند اتخاذ خطوة يدوية داخل Discourse من قبل المسؤول أو المستخدم (مثل الرد على بريد إلكتروني للتأكيد). والمشكلة الأخرى المرتبطة بهذا هي أن كل مزود لديه على الأرجح قواعد مختلفة.
تعديل: تمت إضافة النص المشطوب أعلاه لأنه من الممكن إزالة عنوان بريد إلكتروني من قائمة الحظر الخاصة بـ Mailgun باستخدام واجهة برمجة التطبيقات: https://documentation.mailgun.com/en/latest/api-suppressions.html#delete-a-single-bounce