لنأخذ رسالة واحدة. متجر وهمي اسمه Bright Parcel سجّل فيه زائر للتو بالعنوان quietfox42@veylax.com، فضغط نظامه ما يعادل زر الإرسال على رسالة تأكيد. بعد قليل تظهر الرسالة على شاشة الزائر، وبعد يوم من ذلك لا يبقى لها وجود في أي مكان على خدمة الصندوق. يتتبع هذا المقال رحلتها كلها.
فكيف يعمل البريد المؤقت إذن؟ يستخدم الآلية العادية لبريد الإنترنت مع لمسة واحدة مختلفة: طرف الاستقبال يقبل البريد لأي اسم مستخدم على نطاقاته ولا يحتفظ به إلا فترة قصيرة. يبحث خادم المرسِل عن سجل MX للنطاق في DNS، ويتصل بالمضيف المذكور عبر SMTP على المنفذ 25، ويسلّم الرسالة. ثم يحللها نظام البريد المؤقت، ويعرضها في صندوق، ويحذفها وفق جدول محدد. وفي VookMail تشير سجلات MX للنطاقات إلى مزوّد لتوصيل البريد، يستقبل جلسة SMTP ويحوّل كل رسالة إلى VookMail عبر HTTPS.
المرحلة 1: مغادرة المرسِل
يبني تطبيق Bright Parcel الرسالة. والرسالة نص منظم وفق صيغة رسائل الإنترنت (RFC 5322): ترويسات مثل From وTo وSubject، ثم سطر فارغ، ثم المتن. ولا يوصلها التطبيق بنفسه في العادة، بل يسلّمها إلى خدمة بريد صادر، إما عبر اتصال SMTP موثّق على المنفذ 587 (أو 465 مع TLS من البداية) وإما عبر واجهة API لدى شركة الإرسال.
وقد يقع أول تأخير هنا بالذات. فتطبيقات كثيرة تضع البريد الصادر في طابور مهام وتعالجه على دفعات، وخاصة منصات التسويق. لذلك قد تسبق عبارة «تحقق من بريدك» على الموقع لحظة خروج الرسالة بوقت غير قليل. ولنفترض في مثالنا أن الطابور يستغرق عشرين ثانية. لم يصل شيء بعد إلى جهة المستلم، ولا تستطيع أي خدمة بريد مؤقت أن تراه أو تسرّعه.
المرحلة 2: معرفة أين يستقبل veylax.com بريده
يقرأ الخادم الصادر الجزء الذي بعد @، وهو هنا veylax.com، ويسأل DNS عن سجلات MX لهذا النطاق. وسجل MX (مبادل البريد) يسمّي خادمًا يقبل بريد النطاق. وهذا مثال بصيغة ملف المنطقة لما قد تبدو عليه سجلات نطاق ما، والأسماء مختلقة للتوضيح:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
الرقم 3600 هو TTL (مدة الصلاحية)، أي عدد الثواني التي يجوز للمحلّل أن يحتفظ فيها بهذا الجواب. أما 10 و20 فهما الأولويتان: يبدأ المرسلون بالرقم الأقل، وينتقلون إلى الأعلى إذا تعذر الوصول إليه. ويجب أن يكون لاسم المضيف سجل A (IPv4) أو AAAA (IPv6) خاص به. وينبغي أن يشير سجل MX إلى اسم مضيف، لا إلى عنوان IP مباشرة ولا إلى اسم بديل CNAME.
يمكنك إجراء هذا البحث بنفسك لأي نطاق:
| النظام | الأمر |
|---|---|
| موجّه الأوامر في Windows | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS وLinux | dig MX example.com +short |
وتستخدم أنظمة مكافحة الإساءة هذا البحث نفسه لكشف النطاقات التي توجّه بريدها إلى بنى معروفة للبريد القابل للتخلص منه. وهذا أحد أسباب تعرّف بعض المواقع على نطاقات البريد المؤقت حتى حين يكون النطاق جديدًا.
حالتان خاصتان في DNS
النطاق الذي لا يملك سجل MX ليس بالضرورة غير قابل للوصول. فمعيار SMTP في RFC 5321 يحدد بديلًا: يجوز للمرسِل أن يعدّ سجل A أو AAAA للنطاق نفسه مضيف بريد ضمنيًا. أما النطاق الذي لا يريد أي بريد إطلاقًا فيمكنه التصريح بذلك عبر null MX (RFC 7505)، وهو سجل MX بأولوية 0 ونقطة واحدة في موضع المضيف. وتنشر نطاقات البريد المؤقت سجلات MX عادية بالطبع، فالاستقبال هو غرضها كله.
وقد يعترض التخزين المؤقت الطريق أيضًا حين تضيف الخدمة نطاقًا. فالمحلّلات التي تلقت قبل قليل جواب «لا يوجد سجل كهذا» قد تحتفظ به حتى تنتهي مدة التخزين السلبي، التي يتحكم فيها سجل SOA للنطاق (RFC 2308). لذلك قد يستغرق النطاق الجديد تمامًا بعض الوقت حتى يستقبل البريد بثبات من جميع المرسلين.
المرحلة 3: الحوار بين الخادمين
يفتح الخادم الصادر لدى Bright Parcel الآن اتصال TCP بمضيف MX المفضل على المنفذ 25. وSMTP بروتوكول نصي: يرسل العميل أوامر ويجيب الخادم بردود مرقمة. وهذه جلسة مبسطة لرسالتنا، فيها S: هو المستقبِل وC: هو المرسِل. والمضيفان ورقم الحجم تخص هذا المثال المختلق.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(مصافحة TLS، ثم EHLO مرة أخرى)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (الترويسات، ثم سطر فارغ، ثم المتن، ثم سطر فيه نقطة واحدة)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| الأمر | الغرض | ما يعنيه للبريد المؤقت |
|---|---|---|
EHLO | يعرّف بالمرسِل ويسأل عما يدعمه الخادم | يسرد الرد الامتدادات مثل STARTTLS والحد الأقصى SIZE |
STARTTLS | يرقّي الاتصال إلى TLS (RFC 3207) | يحمي هذه المرحلة وحدها. وليس تشفيرًا من طرف إلى طرف |
MAIL FROM | يحدد مرسِل الظرف، حيث تعود الرسائل المرتدة | كثيرًا ما يختلف عن سطر From الظاهر، خاصة عند المرسلين بكميات كبيرة |
RCPT TO | يسمّي مستلمًا | يجيب المستقبِل الشامل بالرمز 250 لأي اسم مستخدم على نطاقاته |
DATA | يبدأ محتوى الرسالة | ينتهي بنقطة واحدة في سطر مستقل |
QUIT | يغلق الجلسة | حُسم التوصيل بالفعل بالرمز 250 بعد DATA |
لحظة انتقال المسؤولية
هذا الرمز 250 الأخير هو أهم سطر في الجلسة. قبله كانت الرسالة تخص خادم Bright Parcel، وإذا انقطع الاتصال أعاد المحاولة. وبعده يكون المستقبِل قد تحمّل المسؤولية. وستعرض لوحة المرسِل عادةً كلمة «تم التوصيل»، وهذا يعني فقط أن هذه المرحلة نجحت، ولا يعني أن إنسانًا رأى شيئًا.
وتفسر رموز الرد قدرًا كبيرًا مما يراه الناس:
- 2xx نجاح، و
250تعني القبول. - 3xx خطوة وسيطة، و
354تطلب من المرسِل نقل الرسالة. - 4xx فشل مؤقت، مثل
421أو451. يبقي المرسِل الرسالة في طابوره ويعيد المحاولة. - 5xx فشل دائم، مثل
550(الصندوق غير متاح أو مرفوض) أو552(الحجم كبير جدًا). يتوقف المرسِل عن المحاولة، ويُنشئ عادةً رسالة ارتداد.
الفرق بين 4xx و5xx يفسر معظم حالات البريد «البطيء». فلو أجاب المستقبِل هنا بالرمز 451، ربما بسبب القائمة الرمادية (RFC 6647)، لبقيت رسالتنا في طابور Bright Parcel، لا ضائعة ولا موصلة. وينصح RFC 5321 بفاصل إعادة محاولة لا يقل في العموم عن 30 دقيقة، ومهلة استسلام لا تقل عن أربعة إلى خمسة أيام، مع أن الأنظمة الفعلية تضع جداولها الخاصة، وكثير منها يعيد المحاولة أسرع. لهذا قد يظهر تأكيد بعد بضع ثوانٍ ويظهر التالي بعد عشرين دقيقة، دون أي خلل في الحالتين.
مجموعتان من العناوين
في SMTP طبقتان من العنونة. الظرف، أي MAIL FROM وRCPT TO، هو ما تستخدمه الخوادم للتوجيه. أما الترويسات، أي From: وTo: وSubject:، فهي جزء من محتوى الرسالة وهي ما تراه على الشاشة. وقد تختلفان. فقد تعرض نشرة بريدية To: subscribers مع أن مستلم الظرف كان عنوانك المؤقت. لذلك يصنّف نظام الاستقبال الرسائل حسب مستلم الظرف، فهو القيمة الموثوقة. ولهذا أيضًا تسجّل ترويسة Return-Path، التي تضاف عند التوصيل النهائي، مرسِل الظرف لا عنوان From الظاهر.
المرحلة 4: لماذا لم يكن quietfox42 بحاجة إلى أن يوجد
عند RCPT TO يتحقق خادم البريد العادي من وجود الصندوق ويجيب بالرمز 550 إذا لم يكن موجودًا. أما نطاق البريد المؤقت فيعمل بالعكس. فهو يعمل مستقبِلًا شاملًا (catch-all): كل جزء محلي (ما قبل @) مقبول.
هذا الخيار الوحيد هو ما يجعل العناوين الفورية ممكنة. فحين يعرض لك VookMail عنوانًا عشوائيًا، لم يلزم إنشاء أي شيء على أي خادم بريد. وحين تضغط «جديد»، وتكتب اسم المستخدم، وتختار نطاقًا، وتضغط السهم، يكون ذلك الاسم «موجودًا» سلفًا، لأن النطاق يقبل كل الأسماء. وكل ما على التطبيق أن يعرض لك الرسائل التي يطابق مستلمها العنوان الظاهر على شاشتك.
وتسري على هذه الأسماء قاعدتان صغيرتان. يقول المعيار إن الجزء المحلي قد يكون حساسًا لحالة الأحرف، لكن معظم الأنظمة الفعلية تعامل Test@ وtest@ صندوقًا واحدًا، لذلك يوحّد نظام البريد المؤقت حالة الأحرف عن حكمة، حتى لا تقسم طريقة كتابة المرسِل الصندوق إلى اثنين. ويحدد RFC 5321 الجزء المحلي بـ 64 ثُمانية، مع حد عملي يبلغ 254 حرفًا للعنوان كله، فينبغي أن تبقى الأسماء المولّدة دون ذلك بكثير.
المرحلة 5: من بروتوكول البريد إلى طلب ويب
قبلت رسالتنا الآن آلة تتحدث SMTP. أما الموقع الذي يعرض الصندوق فهو تطبيق ويب. ولا بد من شيء يصل بينهما.
تشغيل خادم بريد مفتوح على الإنترنت كله عمل حقيقي: TLS، وفيضانات الاتصالات، والطوابير، والبرامج الضارة، والحفاظ على سمعة جيدة. لذلك تسلّم تطبيقات حديثة كثيرة جانب SMTP إلى مزوّد متخصص في البريد الوارد، وتستقبل الرسائل على هيئة طلبات ويب، وهو نمط يسمى غالبًا webhook للتحليل الوارد. ويستخدم VookMail هذا النموذج. وهو يعمل هكذا:
- تقبل مضيفات MX لدى المزوّد الرسالة من خادم المرسِل، كما في الجلسة السابقة.
- يحزمها المزوّد، إما مصدر MIME الخام وإما حقولًا محللة مسبقًا مثل المرسِل والمستلمين والموضوع والنص وHTML والمرفقات.
- يرسل هذه الحزمة في طلب HTTPS POST إلى نقطة نهاية يديرها تطبيق البريد المؤقت، فيُشفَّر المحتوى بين هاتين النقطتين.
- يجيب التطبيق بحالة نجاح. وإذا تعذر الوصول إليه أو أعاد خطأ، أعاد المزوّد الجيد المحاولة وفق سياسته.
- يتحقق التطبيق من الطلب، ويطابق المستلم بعنوان، ويخزن الرسالة مؤقتًا.
| الجانب | مستقبِل SMTP مستضاف ذاتيًا | مزوّد وارد مع HTTPS |
|---|---|---|
| التعرض | المنفذ 25 مفتوح لكل مضيف على الإنترنت | يتولى المزوّد حركة SMTP، ولا يرى التطبيق سوى طلبات HTTPS |
| ذروات الحركة | على المشغّل أن يوفر السعة | تتعامل بنية المزوّد مع الدفعات |
| تحليل MIME | يكتب المشغّل محللًا أو يصونه | يتولاه المزوّد غالبًا، مع إمكان استخدام المصدر الخام |
| الملاءمة لتطبيق ويب | يحتاج إلى جسر من مخزن البريد إلى التطبيق | تصل الرسالة كأي طلب API |
| الاعتماد على الغير | أطراف خارجية أقل | يعتمد على توفر المزوّد وإعداداته |
الصف الأخير تكلفة حقيقية. فإذا تعرض المزوّد الوارد لانقطاع أو مشكلة في الإعدادات، فقد يتوقف التوصيل إلى كل النطاقات التي وراءه حتى تُحل، حتى لو كان موقع البريد المؤقت يعمل بصورة طبيعية. والرسائل التي رُفضت بخطأ مؤقت في تلك الفترة قد تصل حين يعيد المرسلون الأصليون المحاولة، بحسب المدة التي تحتفظ بها طوابيرهم.
حماية نقطة النهاية
نقطة نهاية webhook عنوان URL عام، فيمكن لأي شخص أن يحاول إرسال رسالة مزورة إليها. وعادةً ما تجمع التطبيقات الحريصة بين عدة وسائل دفاع:
- التحقق من التوقيع، إذ يوقّع المزوّد كل طلب ويرفض التطبيق ما لا يطابق.
- مسار سري أو رمز لا يعرفه إلا المزوّد والتطبيق.
- قصر الطلبات على نطاقات العناوين التي ينشرها المزوّد، حيث توجد.
- حدود الحجم، وهي ترفض الحمولات الضخمة مبكرًا لحماية الذاكرة والتخزين.
- عدم التكرار. فالمزوّدون يعيدون المحاولة، فقد تصل الرسالة نفسها مرتين، ويمنع Message-ID أو معرّف الحدث لدى المزوّد التكرار.
المرحلة 6: تفكيك الرسالة
ما يصل ليس بعد شيئًا يقرؤه الإنسان براحة. فصيغة MIME (امتدادات بريد الإنترنت متعددة الأغراض، RFC 2045 وما بعده) تتيح لرسالة واحدة أن تحمل عدة أجزاء بصيغ مختلفة. وقد تكون رسالة التأكيد مرتبة على هذا النحو، مع فاتورة مضافة مثالًا:
| الجزء | ما يحويه |
|---|---|
multipart/mixed | الحاوية الخارجية حين توجد مرفقات |
multipart/alternative | المحتوى نفسه مرتين، بصيغتي text/plain وtext/html. يعرض القارئ أغنى صيغة يدعمها |
multipart/related | HTML مع الصور المضمّنة، ويشار إليها بمعرّفات cid: |
| جزء المرفق | ترويسة Content-Disposition: attachment واسم ملف، ثم بيانات الملف المرمّزة |
وفوق ذلك تأتي الترويسات، ومنها Message-ID وDate وأسطر التتبع Received، التي تسجل كل خادم مرت به الرسالة. وإذا أردت يومًا أن تعرف أين وقع تأخير، فالطوابع الزمنية في أسطر Received هي المكان الذي تبحث فيه.
وعلى المحلل أيضًا أن يعكس عدة ترميزات. يحمل Base64 المرفقات الثنائية ويزيد حجمها بنحو الثلث، فيصبح الملف ذو 10 MB رسالة حجمها نحو 13 إلى 14 MB. ويعالج Quoted-printable النصوص التي أغلبها ASCII بكتابة الأحرف الخاصة في صورة =XX. وتبيّن قيمة charset= طريقة ترميز النص، وهي UTF-8 في الغالب، وهذا مهم جدًا لخدمة تُستخدم بلغات كثيرة. أما أسطر الموضوع التي فيها أحرف خارج ASCII فتستخدم صيغة =?UTF-8?B?...?= أو =?UTF-8?Q?...?= من RFC 2047.
جعل HTML آمنًا للعرض
HTML في البريد يكتبه غرباء، فلا يجوز لأداة العرض أن تتيح له تشغيل شيفرة في سياق الموقع. وتزيل التطبيقات الحريصة عادةً السكربتات وسمات معالجة الأحداث ومخططات URL الخطرة، وتعرض الرسالة في إطار معزول حتى لا تؤثر أنماطها ومحتواها في الصفحة المحيطة.
وتحتاج الصور الخارجية إلى تفكير أيضًا. فتحميل إحداها يخبر مرسلها بأن الرسالة فُتحت، وهكذا تعمل أدوات التتبع المخفية. يزيل VookMail هذه الأدوات ويبقي الصور معطلة حتى تسمح بها.
ويمكن لأداة العرض أيضًا أن تفعل شيئًا مفيدًا بالنص المحلل. ففي رسالة التأكيد، يعرض VookMail كود التحقق أو رابط التأكيد فوق الرسالة، فلا يضطر أحد إلى التمرير في قالب طويل للعثور عليه.
المرفقات
تُفك المرفقات وتخزَّن مؤقتًا حتى يمكن تنزيلها. وفي VookMail تُرفض ملفات البرامج الشائعة مثل .exe و.bat و.apk، وتعرض الملفات المضغوطة مثل .zip تحذيرًا، وتسري حدود قصوى للحجم. وتُحذف المرفقات مع الرسائل. وتذكر أن أمان الملف لا علاقة له بمكان تخزينه: فالمستند الذي يحوي وحدات ماكرو خطر بالقدر نفسه حين يُنزَّل من صندوق مؤقت.
المرحلة 7: الوصول إلى الشاشة
رسالتنا مخزنة الآن، لكن المتصفح الذي يعرض quietfox42@veylax.com لا يعرف ذلك بعد. ولتطبيقات الويب عدة طرق لمعرفة ذلك:
| التقنية | طريقة عملها | المزايا والعيوب |
|---|---|---|
| الاستعلام القصير | تسأل الصفحة الخادم كل بضع ثوانٍ | بسيط وموثوق، لكنه يكرر الطلبات |
| الاستعلام الطويل | يبقى الطلب مفتوحًا حتى يأتي جديد أو تنتهي المهلة | أجوبة فارغة أقل، واتصالات مفتوحة أكثر |
| Server-Sent Events | تدفق واحد طويل الأمد من الخادم إلى المتصفح | فعّال في اتجاه واحد، ويعيد الاتصال بنفسه |
| WebSockets | اتصال دائم في الاتجاهين | تفاعلي بالكامل، ويحتاج إلى بنية مخصصة |
يتحقق صندوق VookMail من الرسائل كل بضع ثوانٍ، ويتحقق زر «تحديث» يدويًا، مثلًا بعد أن يكون جهازك في وضع السكون أو بعد انقطاع الشبكة. وتلك الثواني القليلة هي عادةً أقصر جزء في الرحلة. فإذا بدا البريد بطيئًا، فالوقت قد ضاع في الأغلب في مكان سابق، في طابور المرسِل أو في إعادة محاولة.
ويمر إنشاء العنوان أيضًا عبر حماية صغيرة من الروبوتات: عملية حسابية قصيرة في متصفح الزائر تُعرف بإثبات العمل. لا تكلف الزائر العادي شيئًا تقريبًا، وتجعل إنشاء العناوين بكميات كبيرة أكثر كلفة.
ويمكن فتح العنوان في مكان آخر كذلك. فلأن العنوان نفسه يحدد الصندوق، لا يتطلب نقله إلى جهاز آخر سوى تمرير العنوان. يعرضه زر QR في VookMail في رمز يمكن للهاتف مسحه، فيُفتح الصندوق نفسه هناك، وتعرض تطبيقات Android وHuawei الرسائل بالطريقة نفسها. هذا مريح، ويبيّن أيضًا لماذا خصوصية هذه الصناديق ضعيفة: فأي شخص يعرف العنوان أو يخمّنه يستطيع فتح ذلك الصندوق. والعنوان العشوائي هو الخيار الأكثر أمانًا، لأن تخمينه أصعب بكثير من اسم قصير.
المرحلة 8: الحذف
بعد يوم تقريبًا من وصول رسالة التأكيد، تختفي. ويُنفَّذ الحفظ في أنظمة البريد المؤقت عادةً بطابع زمني على كل رسالة مخزنة ومهمة مجدولة تحذف كل ما تجاوز الحد. والمرفقات المحفوظة ملفات منفصلة تذهب في الوقت نفسه. وتستخدم تصاميم أخرى انتهاء الصلاحية على مستوى التخزين، إذ تحذف قاعدة البيانات نفسها السجلات القديمة عبر إعداد مدة صلاحية. والمهام الدفعية أحد أسباب وصف الخدمات للانتهاء بأنه «يوم تقريبًا»، فاللحظة الدقيقة تتوقف على وقت تشغيل المهمة. وفي VookMail تُحذف الرسائل والمرفقات والعناوين خلال نحو 24 ساعة، ويتيح لك زر «حذف» إزالتها قبل ذلك.
ويخدم الحفظ القصير غرضين معًا. فهو يحمي الخصوصية، وهو ضرورة للسعة أيضًا: فالصناديق القابلة للتخلص منها تستقبل كثيرًا من الرسائل التسويقية، وحفظها طويلًا لا يفيد أحدًا. وتتناول سياسة الخصوصية وصفحة المنهجية التعامل مع البيانات بتفصيل أكبر.
ولاحظ ما لا يمسه الحذف. فلا يزال Bright Parcel يحتفظ بالعنوان في جدول عملائه، ولا تزال سجلاته تقول إنه «تم التوصيل». كل ما ذهب هو النسخة التي في جهة الصندوق.
المسار كله في جدول واحد
| المرحلة | المكوّن | البروتوكول أو الآلية | المنفذ أو الصيغة المعتادة |
|---|---|---|---|
| الكتابة | تطبيق أو برنامج بريد | رسالة RFC 5322 وMIME | نص بترويسات وأجزاء |
| التسليم | خدمة بريد المرسِل | تسليم SMTP أو واجهة إرسال API | 587 أو 465 |
| البحث عن المسار | محلّل DNS | استعلام MX ثم A أو AAAA | DNS، المنفذ 53 |
| النقل | من خادم المرسِل إلى MX المستلم | SMTP مع STARTTLS عند الإمكان | 25 |
| الاستقبال الوارد | مزوّد توصيل البريد | قبول شامل للنطاقات | الردود 250 و4xx و5xx |
| التحويل | من المزوّد إلى VookMail | طلب HTTPS | 443 |
| المعالجة | تطبيق البريد المؤقت | تحليل MIME والتنقية والتخزين | قاعدة بيانات وتخزين ملفات |
| العرض | متصفح أو تطبيق هاتف | تحقق كل بضع ثوانٍ، مع «تحديث» يدوي | HTTPS |
| الانتهاء | تنظيف مجدول | قاعدة الحفظ | يوم تقريبًا في VookMail |
أين يأتي دور SPF وDKIM وDMARC
تُذكر هذه الثلاثة في كل نقاش عن البريد تقريبًا، فيحسن أن نحدد موضعها على هذا المسار بدقة. كلها تتعلق بإثبات من أرسل الرسالة. ولا يقرر أي منها هل يستطيع العنوان المؤقت استقبالها.
SPF (RFC 7208) سجل TXT في DNS يسرد الخوادم المسموح لها بالإرسال باستخدام نطاق في مرسِل الظرف، ويقارن المستقبلون عنوان IP المتصل به. وDKIM (RFC 6376) توقيع مشفّر يضيفه النطاق المرسِل إلى ترويسات مختارة وإلى المتن، ويُتحقق منه بمفتاح عام في DNS. وDMARC (RFC 7489) سياسة تخبر المستقبلين بما يفعلونه حين تفشل الرسالة في مواءمة SPF وDKIM مع نطاق From الظاهر، وإلى أين ترسل التقارير.
في رسالتنا تجري هذه الفحوص حول المرحلة 3. فقد قوبل خادم Bright Parcel بسجل SPF الخاص به، ويمكن التحقق من توقيع DKIM بمفتاحه المنشور. ويستطيع المزوّد المستقبِل استخدام هذه النتائج لكشف الانتحال. والتحويل يعقّد الأمور قليلًا: فتوقيع DKIM يبقى صالحًا ما لم تُعدَّل الرسالة، أما نتيجة SPF فتتعلق بآخر خادم متصل فقط. وحين يُنقل البريد، يمكن لـ ARC (سلسلة الاستلام الموثقة، RFC 8617) أن يسجل النتائج السابقة. لكن في النهاية، فإن سجل MX وقبول المستقبِل هما ما يوصلان الرسالة.
حين لا تصل الرسالة أبدًا
كل مرحلة مما سبق موضع قد تتوقف فيه الرسالة. والبدء من جهة المرسِل يكشف المشكلة عادةً بأسرع ما يمكن.
| المرحلة | ما الخطأ | ما تراه أو تفعله |
|---|---|---|
| قبل الإرسال | خطأ إملائي في العنوان | ذهبت الرسالة إلى مكان آخر أو ارتدت. استخدم زر «نسخ» |
| مغادرة المرسِل | الرسالة في طابور، أو الدفعات بطيئة | دقيقة أو دقيقتان أمر طبيعي في بعض الخدمات. انتظر |
| مغادرة المرسِل | الموقع يتخطى النطاقات القابلة للتخلص منها دون إعلان | لا يصل شيء. احترم ذلك واستخدم هناك عنوانًا دائمًا أو اسمًا مستعارًا |
| SMTP | رد 4xx ثم إعادة محاولة لاحقة | تصل الرسالة بعد تأخير قد يبلغ دقائق أو أكثر |
| SMTP | الرسالة تتجاوز حد الحجم | رفض 552 ورسالة ارتداد إلى المرسِل |
| المزوّد الوارد | انقطاع أو مشكلة في DNS | قد يتوقف التوصيل إلى كل النطاقات حتى تُحل |
| الصندوق | انقضت الفترة، أو حُذف العنوان | تصل الرسالة متأخرة جدًا فلا تُرى |
قراءة الفشل حين تملك جهة الإرسال
إذا كنت تختبر تطبيقك أنت، فبإمكانك أن ترى أكثر بكثير مما يراه المستخدم، ويتوسع دليلنا عن البريد المؤقت للمطورين في تصميم الاختبارات. وهذا ترتيب معقول للفحوص:
- افتح سجلات البريد في تطبيقك أو لوحة مزوّد الإرسال. هل قُبلت الرسالة، وما حالتها النهائية؟
- ابحث عن رسائل ارتداد أو أحداث webhook تبلغ عن 5xx من جهة المستلم. كثيرًا ما يذكر النص الذي بعد الرمز السبب.
- استعلم عن سجلات MX لنطاق المستلم من شبكة خادمك، بالأوامر السابقة. فقد لا تظهر مشكلة المحلّل هناك في أي مكان آخر.
- تأكد من إعداد SPF وDKIM وDMARC لنطاق الإرسال، لأن بعض المستقبلين يتعاملون بريبة مع البريد غير الموثق.
- أرسل رسالة نصية صغيرة لتستبعد تصفية الحجم أو المحتوى.
- استخدم اسم مستخدم مختلفًا لكل اختبار حتى تعرف أي تشغيل أنتج أي رسالة.
وإذا وصلت رسالة إلى الصندوق متأخرة، فاقرأ ترويسات Received من الأسفل إلى الأعلى. فالفجوة الطويلة بين طابعين زمنيين تبيّن أي مرحلة احتجزتها، مع مراعاة أي فرق بين ساعات تلك الخوادم.
لماذا تشغيل نطاقات كثيرة؟
يتيح لك VookMail الاختيار من أكثر من 30 نطاقًا. ولهذا أسباب عملية. يستطيع المختبرون فصل المشاريع أو مجموعات الاختبار حسب النطاق. وإذا واجه نطاق مشكلة في DNS أو التوصيل، فقد تظل النطاقات الأخرى تعمل. ويقل الاعتماد على اسم واحد، وهذا يفيد حين تحكم أنظمة الإرسال على نطاقات المستلمين كما تحكم على المرسلين.
وتعدد النطاقات ليس أداة للالتفاف على المواقع التي ترفض العناوين القابلة للتخلص منها عن قصد. فإذا رفضت خدمة نطاق بريد مؤقت، فهي تشير إلى أنها تريد وسيلة اتصال دائمة، والخيار الصحيح هو عنوانك الحقيقي أو اسم مستعار دائم لتلك الخدمة. وقد يأتي الرفض عند النموذج، عبر قائمة نطاقات أو بحث MX مثل الذي في المرحلة 2، أو لاحقًا حين يمتنع المرسِل عن الإرسال.
ما يخبرك به المسار عن الأمان
بعد أن تتبعت الرسالة، يمكنك أن ترى بدقة إلى أي حد تصل كل حماية.
يُطبَّق التشفير مرحلة بعد مرحلة. يحمي STARTTLS كل جزء بين خادمين حين يدعمه الطرفان، وكثيرًا ما يكون اختياريًا عند الإمكان، فقد يعود الاتصال إلى نص عادي ما لم تفرض سياسة مثل MTA-STS (RFC 8461) غير ذلك. ويحمي HTTPS جزأي التحويل والعرض. ولا شيء من هذا تشفير من طرف إلى طرف: فكل نظام يتعامل مع الرسالة يستطيع قراءتها.
والوصول هو النصف الآخر. فمن دون كلمة مرور، معرفة العنوان هي ما يتيح الدخول، فلا تدع أي شيء سري يُرسل إليه أبدًا. ويحد الحفظ القصير من ضرر أي انكشاف، لكنه يعني أيضًا أن الصندوق لا يصلح سجلًا. ولأن المحتوى غير موثوق، فقد يصل التصيد والبرامج الضارة إلى هذا الصندوق كما إلى غيره. والصندوق المؤقت يحمي عنوانك الحقيقي، لكنه لا يفعل الكثير لجهازك إذا فتحت ملفًا سيئًا. والاستخدامات المناسبة هي الخصوصية ومكافحة الرسائل المزعجة والاختبار، كما توضح الشروط والأحكام، أما الحسابات المهمة فمكانها في موضع آخر.
كيف يبدو هذا في VookMail
كل هذه الآلية جاهزة قبل وصولك. فحين تفتح VookMail يكون العنوان جاهزًا. يمكنك أن تضغط «جديد» لتكتب اسم مستخدم وتختار نطاقًا، أو تستخدم زر «عشوائي» الأصفر الموصوف في دليلنا عن استخدام VookMail. ولا شيء لتسجله، لأن النطاق يقبل كل اسم أصلًا. وحين يوصل مرسِل رسالة، يستقبلها المزوّد الذي وراء سجلات MX عبر SMTP ويحوّلها عبر HTTPS، فتظهر في صندوقك مع أي مرفقات في المرة التالية التي تتحقق فيها الصفحة. وبعد يوم تقريبًا تختفي.
وتتوفر الخدمة أيضًا في تطبيق على Google Play وHuawei AppGallery.
بضعة أسئلة تقنية أخرى
أي منفذ يستخدمه البريد الوارد؟
يستخدم التوصيل بين خوادم البريد SMTP على منفذ TCP رقم 25. أما المنفذان 587 و465 فهما لتسليم البريد الصادر إلى مزوّدك، فيظهران في المرحلة 1 لا في المرحلة 3. ولهذا أيضًا يظل بإمكان الاتصال المنزلي الذي يحجب المنفذ 25 أن يرسل عادةً عبر مزوّده.
هل تستطيع خدمة البريد المؤقت رؤية رسائلي؟
تقنيًا، نعم. تصل الرسالة إلى الخدمة في صورة مقروءة، فبهذا تستطيع عرضها لك، وكذلك مزوّد التوصيل الذي يتعامل معها في الطريق. وهذا صحيح أيضًا في البريد المستضاف العادي، ما لم يكن المحتوى مشفرًا من طرف إلى طرف. وهو سبب إضافي لإبعاد أي شيء حساس عن الصندوق المؤقت.
لماذا يظن المرسِل أن الرسالة وصلت بينما لا أرى شيئًا؟
لأن عبارة «تم التوصيل» في لوحة المرسِل تشير إلى الرد 250 من الخادم المستقبِل. أما ما يحدث بعد ذلك، مثل خطوة التحويل أو الوصول المتأخر بعد تفريغ الصندوق، فلا يراه المرسِل.
هل يستطيع المرسِل معرفة أن عنواني استقبال شامل؟
كثيرًا ما يستطيع. يمكن لأداة تحقق أن تختبر اسم مستخدم مختلقًا على النطاق، فإذا قبله الخادم فالأرجح أن النطاق شامل. وهذا وحده لا يثبت أن النطاق قابل للتخلص منه، فكثير من نطاقات الشركات العادية معدّة بالطريقة نفسها، لذلك تجمع هذه الأدوات عادةً بينه وبين إشارات أخرى.
هل يعمل الرد على الرسالة؟
الرد من جهتك ليس الغرض من التصميم، فالصندوق يستقبل في الغالب. وإذا احتجت إلى مراسلة في الاتجاهين، فالصندوق العادي أو خدمة أسماء مستعارة تدعم الرد هو الخيار الأنسب.
لمعرفة المزيد عن المنتج نفسه، راجع الأسئلة الشائعة. وVookMail جزء من شبكة PAYATE للأدوات المجانية.