يبدو أن هناك العديد من الحالات الغريبة التي يُرفض فيها البريد الإلكتروني بشكل غير صحيح، رغم أنه لا ينبغي رفضه. وهذا يعني أن بعض رسائل الدعم التي يرسلها المستخدمون لا تصل إلينا أبدًا.
على سبيل المثال، غالبًا ما تُرفض الرسائل المرسلة إلى عنوان دعمنا من عناوين mac.com بسبب عدم وجود محتوى (Email::Receiver::NoBodyDetectedError). وفي الواقع، تحتوي هذه الرسائل غالبًا على نص، مما يشير إلى احتمال وجود مشكلة في التحليل.
إلا أنه، بغض النظر عن إصلاح السبب الكامن وراء هذه الرفضات الخاطئة، سأكون سعيدًا إذا تم تنبيهنا عند حدوث رفضات جديدة، حتى نتمكن من مراجعتها وتحديد ما إذا كان الرفض مناسبًا.
يمكن أن يتم ذلك عبر خيار لإرسال تنبيهات للموظفين عند كل رفض، أو عبر خيار لنسخ جميع رسائل الرفض على الموظفين تلقائيًا.
وإلا، فإننا لن نستبعد فقدان أي رسالة دعم واردة إلا إذا قمنا بفحص قائمة البريد المرفوض في خلفية نظام Discourse بشكل متكرر. وهذا أمر مرهق وغير ضروري.
أعتقد أنه من الأفضل التركيز على المثال المحدد. لقد قلت “غالبًا” يتم الرفض، هل تلاحظ أي أنماط هنا في محتوى البريد الإلكتروني؟ إذا كانت المشكلة مستمرة، لكانت جميع الرسائل من mac.com قد فشلت.
حسناً… ‘في كثير من الأحيان’ بمعنى ‘كثيراً بما يكفي لأن يكون مزعجاً بعض الشيء’. قلقنا الرئيسي هو أننا لا نريد أن يغضب الناس بسبب ما يُنظر إليه على أنه نقص في استجابة فريق الدعم لدينا.
لقد بحثت عن أنماط في الحالات التي لاحظتها. في البداية، ظننت أن هناك مشكلة في كيفية تعامل mac.com مع البريد الإلكتروني، لكنني استنتجت لاحقاً أن لدينا حوالي 30 مستخدماً بعناوين mac.com لا تظهر أي مشاكل.
كما اعتقدت أنه إذا كان لدى mac.com عميل ويب للبريد الإلكتروني، فقد يكون يعالج رسائل البريد الإلكتروني بتنسيق HTML بطريقة غير قياسية. لكنني لست متأكداً حتى من وجود عميل ويب للبريد الإلكتروني على mac.com.
ظننت أنني فهمت الأمر عندما أدركت أن أحدث حادثة تضمنت بريداً إلكترونياً يحتوي فقط على أسطر مقتبسة في جسم الرسالة، لكن الاختبارات اللاحقة أظهرت أن Discourse يعالج مثل هذه الرسائل الإلكترونية بشكل صحيح.
سأراجع السجلات لأرى كم مرة حدث هذا النوع من الأمور، وبطبيعة الحال سأبحث عن أنماط. كنت أفكر فقط أنه طالما توجد إمكانية أن يرتكب Discourse أخطاءً كهذه بين الحين والآخر، فإن رسالة تنبيه بالبريد الإلكتروني تبدو إجراءً وقائياً بسيطاً بما يكفي.
لا يوجد نمط حقيقي. هناك 21 حالة يكون فيها سبب الرفض غير واضح تمامًا، أو يبدو خاطئًا.
1 حالة: “لا يمكن معالجة البريد الإلكتروني: النص مشابه جدًا لما نشرته مؤخرًا”
8 حالات: “لا يمكن معالجة البريد الإلكتروني: Email::Receiver::BadDestinationAddress” - هذه الحالات غامضة بعض الشيء؛ لماذا تعتبر العناوين غير صالحة؟
3 حالات: “لا يمكن معالجة البريد الإلكتروني: Email::Receiver::NoBodyDetectedError” - حالتان تبدوان وكأنهما تحتويان على نص جسم عادي؛ بينما تشير الحالة الثالثة فقط إلى “لا يوجد جسم”
1 حالة: “لا يمكن معالجة البريد الإلكتروني: Email::Receiver::TooShortPost”
6 حالات: “لا يمكن معالجة البريد الإلكتروني”
1 حالة: “لا يمكن معالجة البريد الإلكتروني: عذرًا، لا يمكن للمستخدمين الجدد إضافة سوى صورة واحدة في المنشور.”
1 حالة: “خطأ غير مُلتقط: خطأ في الصيغة، تعبير غير معترف به: #xxxxxx-email:product at company dot com”
تتضمن عدة من هذه الحالات محاولات شرعية للتواصل من قبل العملاء. لا يزال من غير الواضح ما إذا كانت رسالة الرفض المرسلة بواسطة Discourse قد وصلت إلى مجلد الرسائل غير المرغوب فيها لدى المرسل أو تم تجاهلها ببساطة.
لقد أرسلوا إلى عنوان لا تتعامل معه، مثل دعم العملاء.
في رأيي، يبدو أن عدم وجود أي شخص حيث تقول إن هناك شخصًا هو الشيء الوحيد الذي قد يكون خطأً. ومن الاحتمالات أن يكون ذلك بسبب استخدامهم لعميل بريد قديم ومعطّل.
لقد راجعت بعض هذه الحالات (Email::Receiver::BadDestinationAddress)، ويبدو أن الكثير منها ردود شرعية من العملاء، حيث يكون المستلم بالصيغة التالية: replies+longidentifier@discourse.site.com. تشير رسالة التنبيه التي يرسلها Discourse إلى المرسل إلى أن البريد الإلكتروني تم إرساله من عنوان غير مرتبط بالموضوع المشار إليه، وهو على الأرجح التفسير، لكن في حالة مثل هذه، أود أن يتم تنبيه الموظفين على أي حال.
يبدو ذلك كخطأ، ولكن بينما أود أن يتم إصلاح ذلك، أشعر أنه ستكون هناك دائمًا حالات مثل هذه، لذا فإن إرسال رسالة تنبيه إلى الموظفين، بالإضافة إلى متابعة أخطاء تحليل البريد الإلكتروني المحتملة، سيسمح لنا بتقديم دعم في الوقت المناسب في هذه الأثناء.
هذا ما كنت أفكر فيه. في المرة القادمة التي أرى فيها هذا، سأطلب من العميل معرفة عميل البريد الذي يستخدمه.
النقطة التي أحاول إيصالها هي أنه عندما تُرفض رسائل البريد الإلكتروني، فإن ذلك يحدث أحيانًا لأن أشخاصًا يحاولون الحصول على دعم، وليس لأن هناك نوايا خبيثة.
بالطبع، في بعض الأحيان، تكون رسائل البريد الإلكتروني التي يرفضها Discourse بحاجة فعلية إلى الرفض، لكننا لا نريد المخاطرة بفوت أي رسالة دعم، لذا فإننا مضطرون لاستقصاء قائمة الرفض باستمرار.
في الوقت نفسه، يُجبر المرسلون المربكون على إيجاد وسائل أخرى للتواصل معنا، مثل نموذج الاتصال الموجود على موقعنا الإلكتروني.
بالنسبة للمواقع الكبيرة، قد تكون تنبيهات رفض البريد الإلكتروني كثيرة جدًا بحيث يصعب التعامل معها، لكن بالنسبة لنا، سيكون التعامل معها أسهل بكثير من التعامل مع عملاء غاضبين.
أيضًا، بينما يقوم Discourse بإرسال رسائل بريد إلكتروني بالرفض إلى المرسل مع معلومات قد تكون مفيدة، أعتقد أن هذه الرسائل تنتهي أحيانًا في مجلدات البريد غير المرغوب فيه، مما يزيد من حيرة العملاء المتضررين.
إذا كان المستخدم يرد من عنوان بريد إلكتروني مختلف عن العنوان الذي أُرسلت إليه الرسالة، فإن ذلك أمر متوقع.
إذا سمحنا بردود على هذه الرسائل من عنوان بريد إلكتروني آخر، فإننا نعرض الحسابات لخطر الاستغلال عبر البريد الإلكتروني، حيث قد يتظاهر آخرون بأنهم مستخدم آخرون. نواجه هذه المشكلة أحيانًا في رسائل الدعم الخاصة بنا هنا على منصة meta.
إذا كانت نماذج الاتصال بالبريد الإلكتروني قيد الاستخدام، فإنها عادةً ما ترسل من عنوان بريد إلكتروني وتُعدّ رأس الرسالة “Reply-To”، مما يعني أننا نواجه نفس المشكلة المذكورة أعلاه.
أنا لست متأكدًا من وجود حل مثالي هنا شخصيًا — ربما يكون لدى شخص آخر في الفريق فكرة.
نعم، كما ذكرت، من المنطقي رفض هذه الردود. لكنني أود أن أظل مُنبهًا عند حدوث ذلك.
لم أذكر نماذج التواصل إلا لأن العملاء، عندما لا يتمكنون من الوصول إلينا عبر عنوان البريد الإلكتروني للدعم (الذي تعالجه Discourse)، يُضطرون للبحث عن بدائل، وهو أمر غير مثالي.
أنا أيضًا لست متأكدًا، وهذا هو السبب في أنني نشرت هذا كطلب ميزة.
نعم، مفهوم. لكن الانتقال إلى تلك الصفحة والضغط على تحديث كل بضع دقائق يبدو غير فعال إلى حد كبير.
الإضافة ستكون مقبولة، لكنني لست متأكدًا من سبب عدم إمكانية إضافة هذه الميزة ببساطة إلى Discourse. بالنسبة لي، يبدو الأمر بديهيًا. فـ Discourse يرسل بالفعل تنبيهات مختلفة إلى مسؤولي الموقع والموظفين. اجعل الإعداد (تنبيه عند رفض البريد الإلكتروني) معطلًا افتراضيًا، وهو ما قد يناسب العديد من المواقع على ما أظن.
مثال آخر: أرسل عميل بريدًا إلكترونيًا إلى عنوان الدعم للإبلاغ عن مشكلة يواجهونها في شرائهم. رفض نظام Discourse بريدهم الإلكتروني: [Email::Receiver::InactiveUserError].
أفهم أن رفض نظام Discourse للبريد الإلكتروني من المستخدمين غير النشطين أمر منطقي تمامًا، ولكن إذا تم تنبيه موظفي الدعم لدينا في الوقت نفسه، لكان بإمكانهم التواصل فورًا مع العميل لشرح ما حدث وما يمكن فعله حيال ذلك.
بدلاً من ذلك، ما لم نقوم بالاستعلام عن قائمة الرفض بشكل متكرر، فإن العميل الآن يواجه مشكلتين، وكلاهما ناتج عن أنظمة مؤتمتة، وسيبقى موظفو الدعم لدينا غير مدركين لهما. يُعد التدخل البشري في هذه المرحلة أمرًا مهمًا، لكن قد تتأخر أوقات الاستجابة، لأننا نعتمد مرة أخرى على الفحص اليدوي لقائمة الرفض.
هل هناك سبب تقني يمنع إخطار المدراء برفض رسائل البريد الإلكتروني؟
