AWS WorkMail EOL — الجدول الزمني وما يعنيه
نشرت AWS إشعار انتهاء الدعم على صفحة الوثائق الرسمية لـWorkMail. تاريخان لا رجعة فيهما: 30 أبريل 2026 — إيقاف التسجيلات للعملاء الجدد؛ 31 مارس 2027 — حذف جميع الحسابات وصناديق البريد والتقاويم وجهات الاتصال، دون إمكانية الاسترداد بعد هذا التاريخ.
عملياً، تصبح موارد WorkMail غير قابلة للوصول في 1 أبريل 2027: تتوقف وحدة تحكم AWS وواجهات برمجة التطبيقات وعملاء IMAP وموصلات Exchange ActiveSync في وقت واحد. لم تُعلن AWS عن أي تمديد أو وضع قراءة فقط بعد التاريخ المحدد. كل ما لا يُصدَّر قبل 31 مارس 2027 يُفقد نهائياً.
تعتمد الإلحاحية على حجم صندوق البريد لديك: قد يستغرق تصدير صندوق بريد بحجم 10 جيجابايت إلى S3 عدة ساعات، كما يستغرق نقل IMAP عبر imapsync وقتاً يتناسب مع عدد الرسائل. بدء الهجرة قبل ثلاثة أشهر من الموعد النهائي حد أدنى معقول. والمثالي أن تُنجز تحويل سجلات DNS قبل نهاية يناير 2027، مما يمنحك وقتاً كافياً لمراقبة قابلية التسليم وتصحيح أي مشكلات قبل الحذف النهائي.
لماذا Mailcow وليس Stalwart أو غيره
تُوصي AWS نفسها بـKopano Cloud وZoho Mail وZoom Mail كبدائل. هذه الحلول تبقى SaaS — تغير المزود دون استعادة السيطرة.
إذا كنت تريد بنية تحتية للبريد الإلكتروني تتحكم فيها بالكامل، فـMailcow هو الخيار الأكثر موثوقية للهجرة من خدمة بريد مستضافة. تجمع حزمة Docker Compose الخاصة به بين Postfix وDovecot وRspamd وSOGo في واجهة إدارة موحدة. نقل IMAP موثق جيداً، والمجتمع نشط، ودعم IMAP الوارد الأصلي يجعل الاستيراد عبر imapsync مباشراً.
Stalwart بديل جاد (انظر المقال المخصص)، لكن معماريته ذات الثنائي الواحد أنسب للتثبيت من الصفر من الهجرة من WorkMail — دعم استيراد صناديق IMAP الموجودة أقل نضجاً في وقت كتابة هذا المقال. للهجرة من WorkMail، Mailcow هو الاختيار العملي.
المتطلبات الأساسية قبل البدء
ثلاثة موارد ضرورية قبل بدء الهجرة:
VPS بذاكرة وصول عشوائي لا تقل عن 6 جيجابايت. تستهلك حزمة Mailcow (Postfix وDovecot وRspamd وMariaDB وRedis وClamAV وSOGo وخادم nginx الوكيل) ما بين 3 إلى 4 جيجابايت في ظل الحمل الطبيعي. مع 6 جيجابايت، يتوفر لديك هامش مريح لتشغيل imapsync وارتفاعات الحمل خلال الهجرة.
وصول مدير إلى وحدة تحكم AWS WorkMail. يمر تصدير صناديق البريد عبر واجهة برمجة تطبيقات AWS — تحتاج إلى صلاحيات IAM كافية لإنشاء دور تصدير والوصول إلى S3 وتشغيل مهام التصدير عبر CLI.
اسم نطاق مع إمكانية الوصول إلى DNS. تحويل DNS (سجلات MX وSPF وDKIM وDMARC) هو الخطوة الأخيرة — بدون الوصول إلى منطقة DNS الخاصة بك، لا يمكنك إعادة توجيه البريد الوارد إلى Mailcow.
قائمة المتطلبات التفصيلية
- VPS لينكس 64 بت (يُنصح بـDebian 12 أو Ubuntu 22.04)، الحد الأدنى 6 جيجابايت RAM / 2 vCPU / 40 جيجابايت تخزين.
- عنوان IP مخصص مع PTR (DNS عكسي) مُهيأ ليطابق اسم مضيف خادم البريد.
- المنفذ 25 الصادر غير محجوب من مزود الاستضافة — تحقق قبل الطلب.
- المنافذ 25 و465 و587 و993 و143 مفتوحة في جدار حماية VPS.
- وصول AWS IAM مع صلاحيات
workmail:StartMailboxExportJobوs3:PutObjectوkms:GenerateDataKey. - دلو S3 خاص في نفس منطقة AWS التي تنتمي إليها مؤسسة WorkMail.
- مفتاح KMS متماثل في نفس المنطقة (مطلوب من واجهة برمجة تطبيقات تصدير WorkMail).
- وصول DNS للنطاق لتعديل MX وSPF وDKIM وDMARC.
- Docker وDocker Compose مثبتان على VPS الهدف.
تصدير بيانات AWS WorkMail
إنشاء دور IAM وسياسات التصدير
يتطلب تصدير WorkMail دوراً مخصصاً لـIAM. أنشئ ملفي JSON محلياً:
mailbox-export-trust-policy.json(سياسة الثقة لـWorkMail):{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": { "Service": "export.workmail.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "YOUR-ACCOUNT-ID" } } }] }أنشئ الدور عبر AWS CLI:
aws iam create-role --role-name WorkmailMailboxExportRole --assume-role-policy-document file://mailbox-export-trust-policy.jsonaws iam put-role-policy --role-name WorkmailMailboxExportRole --policy-name MailboxExport --policy-document file://mailbox-export-policy.jsonاسترداد معرفات المؤسسة والمستخدمين
تتطلب واجهة برمجة التطبيقات معرف مؤسسة WorkMail ومعرف الكيان لكل مستخدم. استردهما من وحدة التحكم أو عبر CLI:
aws workmail list-organizationsaws workmail list-users --organization-id m-XXXXXXXXXXXXسجّل
OrganizationId(بصيغةm-xxxxx) وUserIdلكل صندوق بريد تريد تصديره.تشغيل مهمة التصدير إلى S3
شغّل مهمة تصدير واحدة لكل صندوق بريد:
aws workmail start-mailbox-export-job --organization-id m-XXXXXXXXXXXX --entity-id S-1-1-11-XXXXXXXXXX --kms-key-arn arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID --role-arn arn:aws:iam::ACCOUNT:role/WorkmailMailboxExportRole --s3-bucket-name your-bucket --s3-prefix exports/user1/تدعم الواجهة حتى 10 مهام تصدير متزامنة لكل مؤسسة.
مراقبة حالة مهام التصدير
تحقق من التقدم بـ:
aws workmail list-mailbox-export-jobs --organization-id m-XXXXXXXXXXXXعند انتقال الحالة إلى
COMPLETED، يكون ملف.zipمتاحاً في S3. يُظهر سجل الإخراجtotalMessagesوtotalBytesوsha384Hashللتحقق من السلامة.تنزيل الملفات المُصدَّرة والتحقق منها
نزّل الأرشيفات من S3:
aws s3 sync s3://your-bucket/exports/ ./workmail-exports/تحقق من عدد الرسائل في الأرشيف:
unzip -l workmail-exports/user1/*.zip | tail -1استخراج ملفات .eml لـ imapsync
يعمل imapsync بأسلوب IMAP-to-IMAP — لا يستورد مباشرةً من ملفات
.zipأو.emlعلى القرص. النهج الموصى به هو تشغيل imapsync مباشرةً من خادم IMAP الخاص بـWorkMail قبل قطع الوصول. تُستخدم أرشيفات S3 كنسخة احتياطية للأمان.
تثبيت Mailcow على VPS
تحضير VPS وتهيئة اسم المضيف
حدّد اسم مضيف FQDN يتوافق مع سجل PTR المستقبلي:
hostnamectl set-hostname mail.yourdomain.comتحقق من أن
hostname -fيُرجع FQDN الكامل. هيّئ PTR لعنوان IP الخاص بـVPS من لوحة تحكم مزود الاستضافة.استنساخ Mailcow وتشغيل المثبّت
ارجع إلى مقال استضافة خادم بريد إلكتروني على VPS مع Mailcow للتثبيت الكامل. باختصار:
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow-dockerizedcd /opt/mailcow-dockerized && ./generate_config.shdocker compose pull && docker compose up -dإنشاء النطاقات والحسابات في Mailcow
في واجهة Mailcow (Configuration → Mail Setup)، أضف النطاق وأنشئ حساباً لكل مستخدم WorkMail تريد نقله. يجب أن تكون العناوين مطابقة لتلك في WorkMail حتى يتمكن imapsync من مطابقة صناديق البريد.
لا تعدّل سجلات MX بعد — يمكن لـMailcow قبول اتصالات IMAP دون أن يكون MX نشطاً.
نقل رسائل البريد الإلكتروني عبر imapsync
تثبيت imapsync على VPS
على Debian/Ubuntu:
apt-get install -y imapsyncتحقق من التثبيت:
imapsync --versionنقل صندوق بريد WorkMail إلى Mailcow
خادم IMAP لـAWS WorkMail في us-east-1 هو
imap.mail.us-east-1.awsapps.com(المنفذ 993، SSL). عدّل المنطقة إذا لزم.`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'WorkMailPassword' \
--host2 mail.yourdomain.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MailcowPassword' \
--automap --skipcrossduplicates --useuid`نقل جميع صناديق البريد بالتوازي
للمؤسسات ذات المستخدمين المتعددين، شغّل عمليات النقل بالتوازي عبر سكريبت. حدّد بـ 4 إلى 6 عمليات متزامنة لتجنب تشبع النطاق الترددي. راقب السجلات في
/var/log/imapsync-*.log.تشغيل تمريرة مزامنة نهائية
أعد تشغيل imapsync مرة أخيرة قبل تحويل DNS مباشرةً لمزامنة الرسائل الواردة منذ النقل الأول:
`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'WorkMailPassword' \
--host2 mail.yourdomain.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MailcowPassword' \
--automap --skipcrossduplicates --useuid --delete2duplicates`
DNS cutover — MX وSPF وDKIM وDMARC
بمجرد اكتمال نقل IMAP والتحقق منه، يعيد تحويل DNS توجيه البريد الوارد إلى Mailcow. لا تُجرِ التحويل قبل التحقق من قابلية التسليم (انظر القسم التالي).
الخطوة 1 — سجل MX. استبدل إدخال MX الحالي (الذي يشير إلى WorkMail) بخادم Mailcow:yourdomain.com. MX 10 mail.yourdomain.com.
تحقق من الانتشار: dig MX yourdomain.com +short
الخطوة 2 — SPF. أزل ترخيص WorkMail وأضف VPS:yourdomain.com. TXT "v=spf1 mx a:mail.yourdomain.com -all"
الخطوة 3 — DKIM. يُنشئ Mailcow مفاتيح DKIM من الواجهة (Configuration → ARC/DKIM Keys). انسخ سجل TXT المُنشأ في DNS الخاص بك.
الخطوة 4 — DMARC. حدّث سياسة DMARC:_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
خفّض TTL جميع هذه السجلات إلى 300 ثانية قبل ساعة من التحويل لتسريع الانتشار.
اختبر قابلية التسليم قبل قطع AWS
قبل تعديل MX، أرسل بريداً إلكترونياً من Mailcow وتحقق من الدرجة على mail-tester.com — درجة 9/10 أو أعلى هي الحد المقبول للإنتاج.
تحقق أيضاً باستخدام swaks من VPS نفسه:swaks --to [email protected] --from [email protected] --server mail.yourdomain.com --port 587 --auth LOGIN --auth-user [email protected] --tls
فحص رأس Authentication-Results في الرسالة المستلمة — يجب أن يُظهر spf=pass وdkim=pass وdmarc=pass. إذا كان أحدها غائباً أو فاشلاً، لا تُغيّر MX — أصلح سجل DNS المعطل أولاً.
استكشاف الأخطاء — أخطاء imapsync وMailcow الشائعة
IMAP Command 'LOGIN' failed: 535 5.7.3 Authentication unsuccessful — بيانات اعتماد WorkMail مرفوضة. تحقق من أن كلمة المرور هي كلمة المرور التطبيقية المُنشأة في وحدة تحكم WorkMail.
SSL connect attempt failed error:14090086 — إصدار TLS غير متوافق أو شهادة منتهية الصلاحية. أضف --ssl1 --tls1 لإجبار TLS 1.2. تحقق من شهادة Mailcow بـ: openssl s_client -connect mail.yourdomain.com:993.
Can't login to host2... Connection refused on port 993 — Mailcow لا يستمع بعد على منفذ IMAPS. تحقق من أن جميع الحاويات تعمل بـ: docker compose -f /opt/mailcow-dockerized/docker-compose.yml ps.
Quota exceeded on host2 — صندوق البريد الوجهة بلغ حد الحصة في Mailcow. زد الحصة من واجهة Mailcow قبل إعادة تشغيل imapsync.
نقل بطيء جداً أو انقطاعات عشوائية — أضف --maxbytespersecond 500000 للحد من الإنتاجية وتجنب انتهاء المهلة. شغّل imapsync داخل جلسة screen أو tmux:screen -S migration imapsync ...
الخلاصة — تصرّف قبل 31 مارس 2027
إغلاق AWS WorkMail قرار نهائي. نافذة الهجرة ضيقة: بين انتشار DNS والتحقق من قابلية التسليم ونقل IMAP لصناديق البريد ذات الحجم الكبير، خصص أسبوعاً إلى أسبوعين من العمل لمؤسسة صغيرة إلى متوسطة.
المسار الأكثر أماناً هو المذكور هنا: صدّر أولاً البيانات إلى S3 (نسخة احتياطية لا رجعة فيها قبل أي معالجة)، انقل الرسائل عبر imapsync أثناء استمرار عمل WorkMail، تحقق من قابلية التسليم على Mailcow قبل القطع، ثم حوّل MX وعطّل حسابات WorkMail.
