نقل البريد إلى مستضيف آخر: التكرار والمجلدات

نقل البريد من مستضيف إلى آخر يبدو بسيطا، إلى أن يتكرر محتوى صندوق بريد وتختفي سجلات الرسائل المرسلة من الواجهة. هذا جانب تهمله أدلة كثيرة حين تعامل البريد كملفات مستقلة، مع أن بنية الصندوق وحالته جزء من العملية.

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

تقل هذه المخاطر بإجراء مرحلي، وربط واضح للمجلدات، وتحقق دقيق بعد التحويل. للتخطيط الأوسع المتعلق بالمزودين والأسعار وملكية الحسابات، اقرأ دليل البريد للأعمال أولا. نركز هنا على النقل نفسه.

عند الانتقال إلى TrekMail، ابدأ بوثائق نظرة عامة على نقل IMAP الحالية، ثم دليل Gmail أو cPanel حسب المصدر. يصف العرض نقل IMAP على الخادم ضمن الخطط المدفوعة التي تبدأ من $3.50/mo، وخطة Nano مجانية دون بطاقة، وتجربة مجانية لمدة 14 يوما للخطط المدفوعة. تحقق من الأسعار والميزات والشروط الحالية.

ماذا يحدث فعليا عند نقل البريد إلى مستضيف آخر؟

باختصار: تدخل أداة IMAP إلى الصندوق القديم، وتقرأ المجلدات والرسائل ثم تنسخها إلى الصندوق الجديد. توحيد الأسماء ومعالجة تكرار المصدر ومخاطر توقيت DNS يحتاج إعدادا وإجراءات تدعم هذه المهام، وليس نتيجة تلقائية للنسخ.

النقل عبر IMAP عملية نسخ بين نظامين للبريد. في وضع النسخ يبقى المصدر سليما، ويحصل الهدف على نسخ الرسائل والمجلدات والعلامات التي يبلغ عنها المزود ويدعمها النقل، مثل مقروءة وغير مقروءة. لا ينقل ذلك جهات الاتصال أو التقويمات أو قواعد الخادم. طريقة تعريف الرسائل في كل نظام مهمة.

وفق RFC 3501، يرتبط UID بكل مجلد بريد وقيمة UIDVALIDITY الخاصة به، ولا يعد هوية عامة عبر المجلدات أو الخوادم. تساعد هذه الحالة الأدوات التي تستخدمها على تتبع ما سبق نسخه؛ وقد يؤدي تغيرها إلى فقدان الربط السابق.

لذلك قد تنجح الجولة الأولى ظاهريا ثم تظهر المشكلة عند إعادتها. لا تعلن اكتمال النقل اعتمادا على كلمة «مكتمل» في اللوحة وحدها، دون فحص البيانات الفعلية.

لماذا تظهر الرسائل المكررة أثناء النقل؟

باختصار: قد يتكرر النسخ عندما لا تستطيع الأداة ربط الرسالة بنسختها السابقة بثقة. تغير UIDVALIDITY أو إعادة إنشاء مجلد الهدف أو نسخ تسميات Gmail كمجلدات مستقلة أسباب محتملة. تتوقف النتيجة على طريقة المطابقة المستخدمة.

فخ UIDVALIDITY

قد تحفظ الأدوات ربط UID داخل كل مجلد أو تستخدم خصائص أخرى للرسالة؛ ليست جميعها متشابهة. إعادة الفهرسة لا تغير UID بالضرورة، لكن حذف مجلد وإعادة إنشائه أو فقدان حالة الأداة قد يبطل الربط المحفوظ.

ينص RFC 3501 على استقرار UID ضمن سياق صلاحيته وإمكان اكتشاف بطلان القيم السابقة عبر UIDVALIDITY. عند تغيرها يجب إعادة تقييم حالة المزامنة. دون معالجة مناسبة قد تعيد الجولة التالية نسخ آلاف الرسائل.

مثال: تنسخ الجولة الأولى 38,000 رسالة من Inbox. يعيد المسؤول التشغيل بعد انتهاء المهلة، لكن مجلد المصدر أو الهدف أعيد إنشاؤه أثناء الليل. إذا لم يعد ربط UID صالحا ولم توجد مطابقة بديلة مناسبة، فقد يحصل Inbox على 38,000 رسالة إضافية.

مشكلة تسميات Gmail

يستخدم Gmail تسميات لا مجرد مجلدات تقليدية. يمكن للرسالة حمل عدة تسميات، وتظل الرسائل المؤرشفة في All Mail. توضح مساعدة Gmail أن الأرشفة تزيل الرسالة من Inbox مع إبقائها متاحة في All Mail.

استيراد [Gmail]/All Mail ومجلدات التسميات دون خطة قد يحفظ الرسالة في أكثر من موضع بالهدف ويزيد التخزين. ليست نسخ التسميات خللا دائما؛ قد تكون التمثيل المطلوب للمجلدات. حدد كيف ستحافظ على التسميات والرسائل الفريدة قبل النقل.

استعن بدليل الاستيراد من Gmail للتحقق من تسجيل الدخول. يستخدم مستورد TrekMail الموصوف بيانات دخول IMAP المباشرة. قد تحتاج كلمة مرور تطبيق حسب التحقق بخطوتين وسياسة الحساب، وقد لا تكون متاحة. عندئذ يمكن اختيار أداة أخرى تدعم OAuth أو طريقة يدعمها المزود، وليس افتراض دعم OAuth في هذا المستورد.

عند استخدام أدوات سطر الأوامر، راجع خيارات هذا المثال قبل التنفيذ:

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

التشغيل التجريبي لا ينسخ الرسائل ولا يختبر نقل المحتوى كاملا. قد يغيب Message-ID أو يتكرر، فلا يكفي وحده دائما لتعريف الرسالة. تحقق من تشفير الاتصال والشهادات، ولا تعرض كلمات المرور الحقيقية في سجل الأوامر أو وسائط العمليات. استبعاد All Mail قد يسقط رسائل مؤرشفة لا تحمل تسمية أخرى مستوردة؛ خطط لتغطية الأرشيف الفريد. يتناول دليل imapsync الجوانب التشغيلية بتفصيل أكبر.

لماذا تبدو المجلدات مفقودة بعد النقل؟

باختصار: قد تكون المجلدات في مستوى مختلف أو مرتبطة بمجلد نظام خاطئ أو تحمل بادئة يعرضها التطبيق بطريقة غير متوقعة. افحص ذلك قبل الحكم على فقد البيانات، مع إبقاء احتمال النقص الحقيقي ضمن التحقيق.

اختلاف نطاقات الأسماء وفواصل المجلدات

تختلف نطاقات أسماء IMAP وفواصل التسلسل بين الخوادم. قد يستخدم خادم النقاط مثل INBOX.Sent، وآخر الشرطات المائلة مثل Inbox/Sent Items، وآخر بادئة INBOX..

إذا لم تضبط الربط، فقد يتحول Project.Alpha إلى مجلد فرعي تحت Project، أو يظهر مجلد النظام كمجلد عادي. وقد يشترك تطبيق الهاتف في المجلد الخطأ ويخفي المطلوب.

اختلاف Sent وSent Items

يلاحظ المستخدمون سجل الإرسال بسرعة. قد يحفظ المصدر في Sent، بينما يتوقع الهدف Sent Items أو يعرض Sent Messages.

إذا نسخت المجلد القديم كمجلد عادي دون ربطه بمجلد النظام، فقد يبقى مجلد الإرسال الافتراضي فارغا. تبدو سنوات من الرسائل مفقودة للمستخدم، رغم وجودها في مكان آخر.

تحقق من أمثلة الجدول وفق نطاق الأسماء والمجلدات ذات الاستخدام الخاص وإعداد العميل الفعلي. في الاستضافة المشتركة يشرح دليل النقل من cPanel أو مستضيفين آخرين أنماط الدخول الشائعة، لكنه لا يغني عن فحص الوصول والمجلدات.

خطة نقل من 3 مراحل لتقليل المخاطر

باختصار: تفصل المزامنة الثلاثية النسخ الكبير عن التحويل النهائي. انسخ التاريخ أولا، ثم التغييرات قرب التحويل، وغير MX مع جولة أخيرة ومتابعة. يمكن أن يقلل ذلك الانقطاع والتكرار، لكنه يحتاج استمرار استقبال المصدر ونافذة رجوع مناسبة.

1. مزامنة الرسائل القديمة. انسخ الرسائل الأقدم، مثلا ما تجاوز 30 يوما، بينما يواصل المستخدمون العمل في النظام القديم. اختر الفترة حسب احتياجاتك.
2. مزامنة التغييرات. انسخ الرسائل الجديدة والتغييرات، ومنها الرسائل المتأخرة ذات التاريخ القديم ونقل الرسائل بين المجلدات. المطابقة مهمة لأن بعض البيانات نسخ سابقا.
3. التحويل والجولة الأخيرة. غير MX، مع استمرار استقبال الرسائل المتأخرة في المصدر بسبب ذاكرة DNS وإعادة محاولات SMTP. كرر مزامنة التغييرات حسب الحاجة؛ انقضاء TTL وحده لا يثبت تحول جميع المرسلين.

خطأ DNS قد يوجه الرسائل إلى المستضيف القديم أو يؤدي إلى رفضها. راجع وثائق سجلات DNS المطلوبة الحالية والقيم المعروضة لحسابك قبل التحويل.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

هذه سجلات توضيحية وليست قالبا للنشر دون مراجعة. حافظ على تفويض خدمات الإرسال الفعلية في SPF، وتحقق من DKIM ومطابقة DMARC؛ لا تطبق الحجر لمجرد النقل دون جرد واختبار. أغلق وصول المستخدمين وكتابتهم في المصدر بعد التحقق وتحديث العملاء، مع إبقاء استقبال SMTP ومزامنة الإدارة والرجوع متاحا عند الحاجة. استمرار الإرسال من المصدر يقسم البيانات بين النظامين. لا توقف المستضيف القديم فور تغيير MX.

تساعد الإجراءات الموحدة أيضا الوكالات وMSP. مع علامات تجارية ونطاقات كثيرة تصبح إدارة التعقيد مهمة إلى جانب النسخ، وقد يفيد عندئذ نظام استضافة البريد لعدة نطاقات.

قائمة التحقق بعد نقل البريد

باختصار: قارن أعداد الرسائل وأقدمها وأحدثها وبنية المجلدات، إضافة إلى المحتوى والمرفقات والعلامات والتواريخ والربط. لا تثبت السعة أو الأعداد وحدها سلامة النقل؛ قد يغير الضغط والفهرسة الحجم المعلن، وقد يغير تمثيل تسميات Gmail عدد النسخ.

1. قارن عدد العناصر لا حجم الصندوق وحده

إذا احتوى Inbox على 4,502 عنصرا قبل التحويل، فتوقع 4,502 بعده عند مقارنة النطاق نفسه والاستبعادات المعتمدة. راع التسميات والرسائل الجديدة، وحقق في الفرق. تساوي العدد ليس إثباتا لتطابق المحتوى.

2. تحقق من أقدم الرسائل وأحدثها

رتب بالتاريخ وقارن أقدم الرسائل وأحدثها في Inbox وSent. قد يشير غياب الأقدم إلى نقص نسخ الرسائل القديمة، وغياب الأحدث إلى المزامنة أو التحويل. تحقق أيضا من فلاتر الاختيار والتواريخ وربط المجلدات.

3. افحص المجلدات غير المرتبطة

ابحث عن INBOX.Sent في الجذر أو مجلدات [Gmail] المتبقية أو مجلدات إرسال مكررة. قد تدل على ربط خاطئ، لكن تأكد أنها ليست بنية احتفظت بها عمدا.

4. اختبر الاستقبال والإرسال الفعليين

أرسل من صندوق خارجي ثم رد من الحساب الجديد. تحقق من الوصول إلى المجلد المقصود وحفظ الرد في مجلد الإرسال الصحيح. حقق في التصفية بصورة منفصلة إن وجدت.

5. تحقق من إعدادات العملاء الجديدة

قد تكون النسخة سليمة ويبدو البريد ناقصا لأن العميل ما زال متصلا بالخادم القديم. حدث إعدادات IMAP وSMTP وفق وثائق TrekMail الحالية. إذا كانت الرسائل في المنصة ولا تظهر، فافحص الاتصال والمزامنة والاشتراك في المجلدات.

لهذا ينبغي التخطيط للنقل وتغيير المزود معا. يناقش مقال بديل Titan Email الأمر من زاوية اختيار المستضيف؛ نسخ الصندوق جزء فقط من الانتقال.

مقارنة أساليب النقل القديمة والجديدة

باختصار: قد تتطلب الإجراءات اليدوية تكرارا ومعالجة استثناءات كثيرة. يمكن أن يقلل النقل على الخادم، مع مطابقة مناسبة وإدارة مركزية، هذا العمل. تحقق من توفر التخزين المشترك وإدارة DNS وفحوص التحويل ضمن الخدمة والخطة الحالية.

قد يقل العمل الإداري للفريق الصغير وتحسن قلة التكرار هامش الوكالة. قد يفيد موقع إدارة موحد بدلا من خمسة أماكن، بحسب الميزات الفعلية. راجع أسعار TrekMail الحالية. يصف العرض Nano المجانية وتجربة مجانية من 14 يوما للخطط المدفوعة؛ تحقق من شروط اليوم.

الخلاصة

إذا أردت نقل البريد من مستضيف إلى آخر مع تقليل مخاطر التكرار ونقص المجلدات والانقطاع، فتعامل معه كتحويل IMAP مضبوط لا كنقل ملفات جماعي. اربط المجلدات مسبقا، وخطط لتسميات Gmail وتغطية الأرشيف، وزامن على مراحل، وافحص العدد والمحتوى. ثم أغلق وصول المستخدمين القديم ضمن خطة إنهاء مدروسة.

إذا اخترت TrekMail للاستضافة الجديدة، فابدأ من trekmail.net. استضافة عدة نطاقات والتخزين المشترك ونقل IMAP والتسعير بحسب الخطة بدلا من المستخدم ميزات موصوفة تحتاج مراجعة توفرها الحالي وحدود المستخدمين والعقد قبل الانتقال.