إصلاح تواريخ ترحيل imapsync في Gmail

لماذا يفسد ترحيل imapsync تواريخ البريد في Gmail

يعد imapsync الأداة المفضلة لترحيل صناديق البريد من IMAP إلى IMAP ولسبب وجيه - يتعامل مع ربط المجلدات والحفاظ على العلامات والمزامنة التزايدية بشكل أفضل من معظم البدائل. لكن عندما تكون الوجهة Gmail يصبح الحفاظ على التواريخ غير موثوق بطرق تفاجئ حتى مسؤولي الأنظمة المتمرسين.

يفترض أن يحل علم --syncinternaldates هذا الأمر. يخبر imapsync بتمرير INTERNALDATE للرسالة المصدر إلى الخادم الوجهة أثناء APPEND. على خادم IMAP قياسي يعمل هذا. على Gmail؟ ليس دائما. يشغل تطبيق IMAP في Gmail الرسائل الواردة عبر نظام معالجة داخلي خاص به - تصفية البريد المزعج وفحص الأمان وفهرسة المحتوى. أثناء هذه المعالجة قد يتجاوز Gmail INTERNALDATE المطلوب ويختم الرسالة بالطابع الزمني للرفع بدلا من ذلك. يضيف أيضا رأس Received (يحتوي عادة على "gmailapi.google.com" أو معرف بوابة IMAP) مؤرخا بلحظة الرفع.

الجزء المحبط: هذا لا يحدث لكل رسالة. بعض الرسائل في صندوق البريد المرحل تحصل على INTERNALDATE الصحيح. وأخرى تحصل على تاريخ الرفع. لا يوجد نمط واضح - رسالة من 2018 قد تكون سليمة بينما الرسالة المجاورة لها من نفس اليوم مختومة بتاريخ الترحيل. ينتهي بك الأمر بصندوق بريد فيه 30-70% من الرسائل بتواريخ خاطئة، متناثرة عشوائيا عبر المجلدات والفترات الزمنية.

هل جربت أن تشرح لمسؤول امتثال لماذا 4,200 من أصل 11,000 رسالة مرحلة تعرض تاريخ الاستقبال الخاطئ بينما الـ 6,800 الأخرى سليمة؟ حظا سعيدا في إيجاد نمط في ذلك.

كيف يؤثر ذلك على Gmail والعملاء المتصلين

واجهة Gmail على الويب تخفي المشكلة فعلا. تعرض واجهة Gmail قيمة رأس Date وليس INTERNALDATE فتبدو معظم الرسائل المتأثرة سليمة في المتصفح. ينشئ هذا شعورا خطيرا بالأمان الزائف - يتحقق مسؤول الترحيل من Gmail على الويب ويرى تواريخ صحيحة ويغلق البلاغ.

ثم يبدأ المستخدمون بتوصيل Outlook وApple Mail وThunderbird بحساباتهم الجديدة في Gmail. تقرأ هذه العملاء IMAP INTERNALDATE لأعمدة التاريخ. فجأة تعرض رسائل عشوائية تاريخ الترحيل بينما تعرض أخرى التاريخ الصحيح. يولد التناقض بين Gmail على الويب وعملاء الكمبيوتر بلاغات دعم محيرة. تشير أوامر بحث IMAP من جانب الخادم (SEARCH SINCE وSEARCH BEFORE) إلى INTERNALDATE معيدة نتائج غير مكتملة أو غير دقيقة. تلتقط أدوات النسخ الاحتياطي من جهات خارجية التي تؤرشف عبر IMAP التواريخ التالفة بشكل دائم. قد تشير أدوات Google Vault وامتثال Workspace إلى INTERNALDATE لعمليات الحجز المبنية على التاريخ مما قد يؤثر على الاكتشاف القانوني. تحدد مطابقة أنماط Redate.io عبر بصمات أدوات الترحيل رؤوس Received المحددة في Gmail التي تشير إلى تلف التواريخ ثم تطبق تصحيحا مستهدفا للبيانات الوصفية على كل رسالة متأثرة مع الحفاظ على جميع التصنيفات والنجوم وحالة القراءة/عدم القراءة.

الأسئلة الشائعة

لماذا لا يعمل --syncinternaldates بشكل موثوق مع Gmail؟

يعالج تطبيق IMAP في Gmail الرسائل الواردة عبر مرشحات أمان وبريد مزعج داخلية. أثناء هذه المعالجة قد يتجاوز Gmail INTERNALDATE المطلوب بالطابع الزمني للرفع. هذا سلوك خاص بـ Gmail وليس خطأ في imapsync. يؤثر على نسبة متغيرة من الرسائل بلا نمط قابل للتوقع.

كيف يمكنني معرفة أي الرسائل لها تواريخ خاطئة بعد ترحيل imapsync؟

يشغل Redate.io فحصا يقارن INTERNALDATE لكل رسالة مع رأس Date الأصلي. يظهر تقرير الفحص بدقة عدد الرسائل المتأثرة وفي أي مجلدات حتى يتمكن المسؤولون من تقييم النطاق قبل الالتزام بالإصلاح.

هل يحافظ Redate.io على تصنيفات Gmail عند إصلاح التواريخ؟

نعم. يحافظ Redate.io على جميع تصنيفات Gmail والنجوم وحالة القراءة/عدم القراءة وعلامات الأهمية والفئات. تظهر الرسالة المصححة في نفس الموقع بالضبط مع بيانات وصفية متطابقة - يتغير التاريخ فقط.

هل يمكن لـ Redate.io إصلاح التواريخ عبر نطاق Google Workspace بأكمله؟

نعم. يدعم Redate.io المعالجة على مستوى النطاق في Google Workspace. يمكن للمسؤولين توصيل النطاق ومعالجة صناديق بريد المستخدمين الفردية أو وضع حسابات متعددة في قائمة انتظار للتصحيح الجماعي من خلال لوحة التحكم.

أدلة الإصلاح ذات الصلة

فحص مجاني