دليل تشغيلي بالدفعات يصلح لأي مزود
يغيّر العميل مزود الاستضافة، أو تتسلمون محفظة عملاء: يجب أن تنتقل الصناديق دون أن يفقد أحد رسالة أثناء انتشار DNS. لا يفترض هذا الدليل إلا أمرين: وصول IMAP إلى الخادمين، والتحكم في منطقة DNS للنطاق. فلا يعتمد على لوحة تحكم ولا على علامة تجارية.
الصعوبة ليست في نسخ رسالة، بل في ألّا يُنسى شيء حولها: الصندوق الذي لم يدرجه أحد، وإعادة التوجيه الموجودة في اللوحة القديمة فقط، والحصة الضيقة في الوجهة، والبريد الذي يواصل الوصول إلى العنوان القديم لأن موزِّعًا ما يحتفظ بسجل MX القديم في الذاكرة المؤقتة. ومن هنا منهج الدفعات: نجرد، ونُعدّ ملفًا واحدًا، ونزامن مرتين، ونعدّ.
للانتقال من Gmail أو Microsoft 365، ومن AWS WorkMail إلى خادم Mailcow، أدلة مستقلة («الانتقال من Gmail وMicrosoft 365: نقل بريدك المهني» و«إغلاق AWS WorkMail: انتقل إلى Mailcow على VPS»). أما هنا فنعالج الحالة العامة لمحفظة عملاء.
الجرد قبل لمس أي شيء
الهجرة عبر IMAP تنقل الرسائل والمجلدات فقط. وكل ما يعيش بجوارها في اللوحة القديمة يجب إدراجه قبل أول نقل، وإلا اختفى بصمت عند التحويل.
اطلبوا من المزود القديم تصدير الحسابات، أو اقرؤوها من واجهته، ووحّدوها في جدول لكل نطاق. أضيفوا عمود «الاستخدام الفعلي»: صندوق بحصة 40 غيغابايت لا يشغل فعليًا سوى 5 غيغابايت يغيّر زمن النسخ والحصة المطلوبة في الوجهة. وأضيفوا عمود «آخر دخول»: صندوق لم يُفتح منذ سنة هو إما حساب شبحي يُؤرشف، أو عنوان نموذج ما زال يستقبل طلبات. هذا السؤال يوجَّه إلى العميل لا إليكم.
يجب أن يصادق العميل على الجدول قبل المتابعة. فهو الحماية الوحيدة من الصندوق المنسيّ.
ما يجب أن يتضمنه الجرد، صندوقًا صندوقًا
- الصناديق والحصص — العنوان، والحصة المخصصة، والمساحة المستخدمة فعليًا، وعدد المجلدات، لتحديد حجم الوجهة.
- الأسماء البديلة وإعادة التوجيه — كل اسم بديل، وكل تحويل إلى عنوان خارجي، وكل عنوان شامل: لا ينقلها IMAP، ويجب إعادة إنشائها يدويًا.
- الردود الآلية والمرشحات — الردود التلقائية، وقواعد الفرز على الخادم، وقوائم الحظر: تُعاد أو تُصدَّر إذا سمحت اللوحة.
- الأجهزة وبرامج البريد — الهواتف وOutlook وThunderbird والماسحات والطابعات التي ترسل عبر SMTP: يجب أن يشير كل منها إلى الخادم الجديد.
- بيانات الدخول — كلمة مرور لكل صندوق، أو كلمة مرور تطبيق إذا كان التحقق بخطوتين مفعّلًا في المصدر.
- جهات الاتصال والتقويمات — خارج نطاق IMAP: صدّروها على حدة وأخبروا العميل بذلك صراحة.
جدول TTL قبل تحويل MX
يحدد TTL (مدة الحياة) لسجل DNS المدة التي يجوز فيها لموزِّع الأسماء الاحتفاظ به في الذاكرة المؤقتة. إذا كان MX مضبوطًا على 86400 ثانية، فقد يواصل مرسل التسليم إلى الخادم القديم أربعًا وعشرين ساعة بعد تغييركم. وخفض TTL لا ينفع إلا إذا تم مبكرًا بما يكفي: فالقيمة المخفضة نفسها يجب أن تنتهي صلاحيتها في الذواكر المؤقتة قبل التحويل.
القاعدة العملية: اقرؤوا TTL الحالي لسجل MX، ثم اخفضوه إلى 300 ثانية قبل التحويل بمدة لا تقل عن TTL القديم (يومان أو ثلاثة إذا كنتم لا تعرفونه)، ولا تغيّروا شيئًا آخر. في يوم التحويل تعدّلون MX وتشغّلون مرحلة الفروقات ويبقى الخادم القديم فعالًا. ولا يُرفع TTL إلا بعد انتهاء فترة القراءة المزدوجة.
خطّطوا كذلك لسجلات التوثيق: يُنشر SPF ومفتاح DKIM للمزود الجديد قبل التحويل لا بعده. وتعريفها في «SPF وDKIM وDMARC: تجاوز عتبة 5,000 رسالة».
جدول نموذجي للتحويل
مرّر الجدول أفقيًا
| الموعد | الإجراء | السبب |
|---|---|---|
| D-7 | مصادقة العميل على الجرد وإنشاء الصناديق في الوجهة | لا صندوق منسيّ والحصص محددة |
| D-3 | خفض TTL لسجل MX إلى 300 ثانية | يجب أن تنتهي صلاحية القيمة المخفضة في الذواكر قبل D |
| D-2 | أول مرحلة imapsync، وهي معظم البريد | يُنسخ الحجم الكبير دون استعجال |
| D-1 | نشر SPF وDKIM للمزود الجديد | تكون أولى الرسائل الصادرة موثّقة |
| D | تحويل MX ثم مرحلة الفروقات | تلتقط ما وصل منذ المرحلة الأولى |
| D+1 إلى D+3 | مراحل فروقات إضافية وقراءة مزدوجة | موزِّعون متأخرون وبريد في الانتظار |
| D+7 | تحقق نهائي ورفع TTL وإلغاء الخدمة القديمة | لا يُقطع إلا بعد العدّ |
لا تتركوا بيانات الدخول متناثرة
دفعة الصناديق هي قائمة كلمات مرور. والفخ المعتاد لصقها في أمر: فتبقى في سجل الصدفة وفي قائمة العمليات ما دام الأمر يعمل. فضّلوا الخيار --passfile1 في imapsync الذي يقرأ كلمة المرور من السطر الأول في ملف، بدل --password1 الذي تنصح وثائق imapsync نفسها بتجنبه.
اعملوا في مجلد مؤقت أُنشئ بالأمر umask 077، على جهاز تتحكمون فيه، لا على محطة مشتركة لزميل. يُحذف ملف الدفعة في النهاية بالأمر shred -u، وتُغيَّر كلمات مرور الوجهة بعد ذلك إذا نقلها العميل عبر قناة غير سرية. وملف دفعة منسيّ في مجلد متزامن مع سحابة شخصية حادثة لا تفصيل.
إذا كان صندوق المصدر يتطلب كلمة مرور تطبيق، فاطلبوها من العميل صراحة: ستُرفض كلمة المرور المعتادة.
المزامنة على مرحلتين، صندوقًا صندوقًا ثم بالدفعة
تجهيز مجلد العمل
umask 077 && mkdir client-batch && cd client-batchثمmkdir logs. يجب ألا يصل أي شيء من هذا المجلد إلى مستودع Git أو مجلد متزامن.كتابة ملف الدفعة
ملف
mailboxes.csvبسطر لكل صندوق:مستخدم المصدر;كلمة مرور المصدر;مستخدم الوجهة;كلمة مرور الوجهة. تُحدَّد الخوادم في الأمر، كما في مثال وثائق imapsync. كلمة مرور تحتوي فاصلة منقوطة تكسر السطر: اختاروا فاصلًا آخر لهذه الدفعة.تجربة صندوق واحد دون نسخ
imapsync --dry --host1 imap.old-provider.com --user1 [email protected] --passfile1 p1 --host2 imap.new-provider.com --user2 [email protected] --passfile2 p2 --ssl1 --ssl2 --automapلا ينسخ شيئًا ويعرض ما سيحدث. ويربط--automapالمجلدات الشائعة (المرسلة والمسودات والبريد المزعج) التي يختلف اسمها بين الخادمين.تسجيل أحجام المجلدات
أضيفوا
--justfoldersizesإلى الأمر نفسه: يعرض imapsync الأحجام الأولية في الجهتين ويتوقف. احتفظوا بهذا الناتج فهو أساس العدّ النهائي.تشغيل المرحلة الأولى على هذا الصندوق
احذفوا
--dryو--justfoldersizesوأضيفوا--logfile logs/contact.txt. إعادة التشغيل لا تعيد نقل ما هو موجود، ولا يُحذف شيء في الوجهة افتراضيًا: لا تضيفوا--delete2قبل نهاية المشروع.تشغيل الدفعة
while IFS=';' read -r u1 p1 u2 p2; do printf '%s' "$p1" > p1; printf '%s' "$p2" > p2; imapsync --host1 imap.old-provider.com --user1 "$u1" --passfile1 p1 --host2 imap.new-provider.com --user2 "$u2" --passfile2 p2 --ssl1 --ssl2 --automap --logfile "logs/$u1.txt"; echo "$u1;$?" >> results.csv; done < mailboxes.csvقراءة رمز الخروج لكل صندوق
الأمر
grep -v ';0$' results.csvيسرد الصناديق التي ليست عند الصفر. الرموز المفيدة هي 16 و161 و162 (التوثيق) و113 (تجاوز الحصة في الوجهة) و101 أو 102 (تعذر الاتصال بأحد الخادمين).تحويل MX ثم إعادة الدفعة نفسها
بعد تغيير MX أعيدوا تشغيل الحلقة نفسها تمامًا: هذه مرحلة الفروقات. لا تنسخ إلا الرسائل التي وصلت منذ المرحلة الأولى. أعيدوها في D+1 وD+3 ثم
shred -u mailboxes.csv p1 p2.
تحققوا من الوصول بدل افتراضه
مزامنة «منتهية» ليست دليلًا. الذي يُتحقق منه هو العدّ: أعيدوا تشغيل --justfoldersizes على كل صندوق في جهة المصدر وجهة الوجهة، وقارنوا مجلدًا بمجلد عدد الرسائل والحجم. ويجب تفسير كل فرق سطرًا بسطر (سلة محذوفات مستثناة عمدًا، أو مكررات مدمجة، أو مجلد غير مشترَك فيه) لا تقريبه. فلا نقول «دون فقدان»، بل نقول «عدّ متطابق في كل مجلد وفروق مفسَّرة».
ثم اختبار من الطرف إلى الطرف: أرسلوا رسالة من عنوان خارجي إلى كل صندوق منقول وتحققوا من وصولها إلى الخادم الجديد، ثم ردّوا من البريد عبر الويب للوجهة وتحققوا من وصول الرد إلى مستلم خارجي. وفي ترويسة الرسالة المستلمة تأكدوا أن SPF وDKIM وDMARC في حالة pass. وأخيرًا افتحوا فعليًا صندوقًا واحدًا لكل نطاق في برنامج بريد مهيأ حديثًا: فهذا ما يكشف مجلدًا غير مشترَك فيه أو كلمة مرور نُقلت خطأً.
استكشاف الأخطاء: الأخطاء التي تتكرر في الدفعات
AUTHENTICATIONFAILEDورمز الخروج 161 أو 162 — كلمة مرور خاطئة، أو مطلوب كلمة مرور تطبيق، أو IMAP معطّل لهذا الحساب. الرمز 161 يخص المصدر و162 يخص الوجهة: تحققوا أولًا من النصف الصحيح.- الرمز 113 و
OVERQUOTA— صندوق الوجهة أصغر مما يلزم. ارفعوا الحصة في الوجهة اعتمادًا على الجرد قبل إعادة التشغيل، وإلا فشلت مرحلة الفروقات في الموضع نفسه. - الرمز 101 أو 102 — الخادم غير قابل للوصول: جدار ناري، أو منفذ خاطئ، أو حد لدى مزود المصدر على الاتصالات المتزامنة. شغّلوا الدفعة صندوقًا بعد صندوق لا بالتوازي، وباعدوا بين المحاولات.
- مجلدات مكررة أو بأسماء خاطئة — تختلف فواصل التسلسل الهرمي (نقطة في جهة وشرطة مائلة في الأخرى). أعيدوا اختبار
--dry --justfoldersوعدّلوا--automapقبل النسخ. - رسائل موجودة مرتين — يعتمد التعرف على الترويسات. إذا أبلغ عميل عن مكررات فاقرؤوا الخيار
--useheader "Message-Id"في وثائق imapsync قبل إعادة التشغيل.
لا تُغلقوا الخدمة القديمة يوم التحويل
أبقوا صناديق المصدر فعالة أسبوعًا على الأقل بعد تغيير MX واطلبوا من العميل مراجعة الجهتين خلال ذلك. فالمرسل الذي احتفظ موزِّعه بسجل MX القديم، أو الذي يعيد خادمه محاولة تسليم مؤجل، سيواصل إيداع البريد في العنوان القديم؛ وتجلبه مرحلة الفروقات لكن بشرط أن يظل الحساب موجودًا. لا ترفعوا TTL ولا تلغوا الخدمة القديمة إلا حين لا تجد آخر مرحلة فروقات أي رسالة جديدة.
استقبال الصناديق: ما تغطيه الاستضافة وما لا تغطيه
تتضمن استضافة cPanel لدى ServOrbit بريدًا مهنيًا: تنشئون الصناديق في cPanel وتحددون حصتها ويصل العميل إلى بريده عبر الويب؛ ويفصّل دليل «إنشاء عنوان بريد إلكتروني مهني في cPanel» الخطوات. ويتوقف عدد الصناديق على الباقة المختارة، ويُقرأ في صفحة الباقة عند تحديد حجم الدفعة.
لكن يجب الدقة في النطاق. فمساعد ترحيل المحفظة لدى ServOrbit، الموصوف في «انقل محفظتك بالكامل إلى ServOrbit في طلب واحد»، يغطي النطاقات وحسابات استضافة cPanel. ولا ينقل صناديق IMAP لمزود خارجي. أما الترحيل المُساعَد فخيار إضافي: يُطلب ويُؤكَّد قبل وعد العميل بموعد، ولا يُفترض أبدًا أنه مشمول.
بعد وصول الصناديق، يتبع إعداد الأجهزة دليل «إعداد بريدك المهني على الهاتف أو Outlook».
ما تسلّمونه للعميل في النهاية
تُختتم الهجرة بوثيقة لا بعبارة «انتهى الأمر». سلّموا العميل جدول الجرد مع ملاحظاته (الصندوق، الحالة، فروق العدّ المفسَّرة)، وقائمة الأسماء البديلة وإعادات التوجيه والردود الآلية التي أُعيد إنشاؤها، وقائمة الأجهزة المعاد إعدادها، وتاريخ إلغاء الخدمة القديمة. وأرفقوا ناتج العدّ قبل النقل وبعده: فإذا ورد اعتراض بعد ثلاثة أسابيع أمكن الرد بالأرقام.
ودوّنوا كذلك ما لم يكن مشمولًا: جهات الاتصال والتقويمات وقواعد الفرز غير المعاد إنشاؤها. فالروتين الذي يعيد «OK» لا يقول إلا ما ينظر فيه. وحدّدوا فحصًا بعد عشرة أيام: فصندوق قليل الاستخدام لن يُظهر مشكلته إلا حينها.
