مصطلح · بروتوكول بريد SMTP

ما هو بروتوكول بريد SMTP، وكيف يؤثر في بريد التطبيقات؟

SMTP، أي Simple Mail Transfer Protocol، هو البروتوكول القياسي الذي تستخدمه أنظمة البريد لتقديم البريد الصادر وترحيله وتسليمه إلى الجهة التالية. يسلّم التطبيق عادةً رسالة مكتملة إلى خدمة تقديم موثَّقة؛ ثم تستخدم خوادم البريد أوامر SMTP وتوجيه DNS لنقلها نحو كل مستلِم. وتكشف ردود SMTP هل قبلت محطة بعينها مستلِمًا معيّنًا أم رفضته، لكن القبول ليس هو الوصول إلى صندوق الوارد. ولا يزال التطبيق بحاجة إلى طوابير دائمة وإعادات محاولة آمنة ومعرّفات رسائل ومصادقة ومعالجة ارتدادات.

ينقل SMTP البريد بين أنظمة مسؤولة

SMTP بروتوكول نقل بمبدأ التخزين وإعادة التوجيه. يفتح العميل جلسة مع خادم ويعرّف بنفسه ويقدّم عنوان المُرسِل في الظرف ويقترح مستلِمًا واحدًا أو أكثر في الظرف، ثم يرسل محتوى الرسالة بعد أن يوافق الخادم على استقباله. ويستطيع الخادم قبول بعض المستلِمين ورفض غيرهم، لذا تخص الحالة المستلِم والمعاملة لا الرسالة ككل فقط. وبمجرد أن يقبل الخادم المسؤولية، قد يسلّم الرسالة محليًا أو يرحّلها نحو نظام آخر يُحدَّد عبر سجلات Mail Exchanger في DNS. ويفسّر هذا التصميم القائم على المحطات سبب عدم جواز اختزال حالة البريد في قيمة منطقية واحدة «أُرسلت». فالتطبيق وخدمة التقديم والمرحِّل والخادم المستقبِل ونظام تصفية صندوق البريد يعرف كل منها جزءًا مختلفًا من النتيجة. ينقل SMTP الرسالة بين الأنظمة، بينما تجعل سجلات مستوى المنتج وأحداث المزوّد هذه الحركة مفهومة للمستخدمين والمشغّلين.

التقديم والترحيل دوران مختلفان في البروتوكول

يفصل RFC 6409 بين تقديم الرسائل وترحيلها. التقديم هو التسليم الأول من مستخدم أو تطبيق مخوَّل إلى وكيل تقديم الرسائل (MSA)، وعادةً عبر المنفذ 587. والترحيل هو النقل بين وكلاء نقل الرسائل (MTA) ويستخدم عادةً المنفذ 25. تستطيع خدمات التقديم اشتراط المصادقة والتحقق من حقول الرسالة أو استكمالها وفرض سياسة المُرسِل، لأنها تعرف من يُدخل البريد الجديد. أما خوادم الترحيل العامة فيجب أن تتوافق مع نطاقات أخرى وتتبع قواعد ثقة مختلفة. لذا ينبغي أن تتصل شيفرة التطبيق بنقطة تقديم موثّقة لدى المزوّد أو أن تستخدم HTTP API الخاصة به، لا أن تفتح اتصالات عشوائية على المنفذ 25 مع خوادم الوجهة. ويوضّح هذا التقسيم أيضًا بيانات الاعتماد: فاسم مستخدم SMTP أو رمزه يخوّل التقديم إلى خدمة معينة؛ ولا يمنح سلطة على نطاق الوجهة. أبقِ بيانات اعتماد التقديم على جهة الخادم، وقيّدها بحِمل الإرسال حيثما يدعم المزوّد ذلك، ودوّرها دون تضمينها في محتوى الرسائل أو برمجيات العميل.

يختلف ظرف SMTP عن ترويسات الرسالة الظاهرة

تحمل معاملة SMTP ظرفًا يتضمن `MAIL FROM` وأمر `RCPT TO` واحدًا أو أكثر. ويتبع المحتوى المنقول على حدة صيغة رسالة الإنترنت التي يعرّفها RFC 5322، بحقول مثل From وTo وDate وSubject وMessage-ID إضافة إلى المتن. وتوسّع معايير MIME هذا المحتوى ليشمل HTML والأجزاء البديلة والمرفقات والبيانات غير ASCII. عنوان المُرسِل في الظرف هو العنوان المستخدم لإخفاقات النقل، وقد يختلف عن مؤلف From الظاهر. وقد يختلف مستلِمو الظرف كذلك عن حقلي To وCc الظاهرين، كما في Bcc. ولا تبنِ هذه البنى بضم سلاسل غير موثوقة. استخدم مكتبة رسائل مُصانة، وتحقق من العناوين، وامنع حقن الأسطر الجديدة في حقول الترويسة، واحتفظ بـ Message-ID ثابت. وعند التشخيص افحص الطبقتين: فحقل From الظاهر الصحيح لا يصلح هوية ظرف غير مخوَّلة، والظرف الصالح لا يجعل MIME مشوّهًا يظهر بشكل صحيح.

اقرأ المعاملة بوصفها آلة حالات

تبدأ جلسة SMTP الموسّعة الأساسية بتحية من الخادم، ثم `EHLO` ليعلن الخادم عن الامتدادات. وقد يتفاوض العميل على TLS والمصادقة للتقديم. ثم تستخدم معاملة البريد `MAIL FROM` وأمر `RCPT TO` واحدًا لكل وجهة و`DATA` والرسالة الكاملة منتهية وفق تأطير SMTP ثم `QUIT`. ولا تعدّ هذا المثال سببًا لتنفيذ البروتوكول يدويًا؛ فمكتبات SMTP الناضجة تتعامل مع نهايات الأسطر وشفافية النقطة والتفاوض على القدرات والمصادقة وحالة TLS بأمان أكبر. زوّد المكتبة بأدوات قياس على مستوى فئة الأمر ورمز الاستجابة دون تسجيل بيانات الاعتماد أو متون الرسائل الكاملة. وسجّل أي مستلِم فشل في أي مرحلة، وهل كان الخادم قد قبل المسؤولية بعد بيانات الرسالة. فهذا الحد يحدد هل إعادة المحاولة مناسبة، وهل التكرار ممكن، وهل سيحمل الإخفاق إشعار حالة تسليم لاحق بدلًا من استجابة فورية.

صنّف رموز الرد قبل قرار إعادة المحاولة

تنقل فئات رد SMTP الإجراء المطلوب. تدل استجابة 2xx على إكمال ناجح لذلك الأمر. واستجابة 4xx إكمال سلبي عابر، فيجوز للمُرسِل ذي الطابور إعادة المحاولة بعد تأخير. واستجابة 5xx إكمال سلبي دائم للأمر المجرَّب وتتطلب عادةً تصحيحًا أو منعًا أو تحقيقًا بشريًا بدلًا من إعادات المحاولة المتكررة. وتضيف رموز الحالة المحسّنة تشخيصًا منظّمًا بصيغة `X.Y.Z` لحالات العنوان وصندوق البريد والنظام والتوجيه والبروتوكول والمحتوى والأمان والسياسة. احتفظ بالرمز الرقمي ونص الخادم معًا لأن كلًا منهما قد يضيف قيمة تشخيصية، لكن لا تكشف الردود الخام التي تحوي بيانات المستلِم على نطاق واسع. طبّق تراجعًا أُسّيًا مع عشوائية (jitter) وأقصى عمر للطابور على الإخفاقات العابرة. ولا تعِد المحاولة بعدوانية تجعل مشكلة مؤقتة في الوجهة تتحول إلى حركة مسيئة. وعند الإخفاق الدائم للعنوان، أوقف الإرسال التلقائي إلى تلك الوجهة وحدّث حالة المنع. وعند إخفاق السياسة أو المصادقة، أصلح الهوية أو DNS أو بيانات الاعتماد أو المحتوى قبل أي محاولة أخرى.

استخدم تقديمًا مشفّرًا وموثَّقًا

نشأ SMTP بوصفه بروتوكول نقل عبر شبكات ذات افتراضات ثقة مختلفة، لذا يعتمد التقديم الآمن على الامتدادات وسياسة النشر. يرقّي STARTTLS اتصال SMTP إلى TLS، وبعدها يجب على العميل تجاهل القدرات التي علمها قبل المصافحة وإصدار `EHLO` مجددًا. ويحدّث RFC 8314 إرشادات التقديم باعتبار الوصول والتقديم بنص صريح متقادمين ووصف TLS الضمني للتقديم. أما SMTP AUTH، المُوحَّد في RFC 4954، فيتيح لخادم التقديم مصادقة العميل عبر آليات معلَنة. استخدم اسم المضيف والمنفذ ووضع TLS وتعليمات المصادقة الحالية لدى المزوّد بدلًا من تخمين تركيبة. وتحقق من شهادة الخادم ولا تتراجع بصمت إلى النص الصريح حين يتطلب الحِمل تقديمًا محميًا. وأبقِ كلمات المرور أو الرموز في مدير أسرار، واستخدم بيانات اعتماد منفصلة لكل بيئة، وعطّل آليات المصادقة المتقادمة. يحمي TLS محطة اتصال واحدة؛ لكنه لا يصادق على مؤلف الرسالة أمام كل مستقبِل لاحق ولا يحل محل محاذاة هوية SPF وDKIM وDMARC.

شخّص إخفاق بريد التطبيق محطةً بمحطة

ابدأ بسجل الإرسال الدائم في التطبيق: هل كان حدث المنتج مخوَّلًا، وهل استحوذت عليه مهمة واحدة فقط في الطابور؟ ثم افحص التقديم: تحليل DNS واتصال TCP والتفاوض على TLS والتحقق من الشهادة والمصادقة وتخويل عنوان المُرسِل في الظرف والردود لكل مستلِم واستجابة DATA النهائية. وإذا قبلت خدمة التقديم الرسالة، فتوقف عن إعادة إرسال الطلب دون تمييز وتتبّع معرّف رسالتها وتدفق أحداثها. ميّز بين حالة معالجة المزوّد وقبول الخادم المستقبِل. فقد يبلّغ ارتداد لاحق عن إخفاق دائم بعد القبول الأول. وإذا قبل الخادم المستقبِل الرسالة، فافحص نتائج المصادقة والسمعة وسياسة المستلِم والمحتوى وتصنيف صندوق البريد بدلًا من وصفه بإخفاق في نقل SMTP. وافحص هويتي الظرف والترويسة معًا، واحتفظ بالطوابع الزمنية ورموز الاستجابة وعدد محاولات الطابور ومعرّفات المزوّد. واستخدم مستلِمين خاضعين للتحكم في الاختبارات. ولا تلصق أبدًا بيانات اعتماد SMTP الإنتاجية أو رسائل العملاء الكاملة في التذاكر أو المطالبات (prompts) أو سجل الطرفية أو أدوات التشخيص العامة.

افصل القبول عن التسليم وعن الوصول إلى صندوق الوارد

الدقة في البروتوكول مهمة في واجهات المنتج. قبول التطبيق يعني أن النظام المحلي سجّل طلبًا. وقبول التقديم يعني أن أول خدمة بريد قبلت مسؤولية معالجته. وتسليم الخادم المستقبِل يعني أن خادم SMTP الوجهة أعاد نجاحًا لعملية التسليم. أما الوصول إلى صندوق الوارد فهو قرار لاحق بشأن السياسة والتصنيف داخل بيئة الاستقبال. وقد تجتاز الرسالة حالة وتفشل أو تُصنَّف بشكل مختلف في التالية. يقدّم SMTP دليلًا مباشرًا عن المعاملة الحالية وقد يُنتج إشعارات حالة تسليم لاحقة، لكنه لا يكشف المجلد النهائي للمستلِم. خزّن هذه الحالات بشكل مستقل بدلًا من وسم كل استجابة 250 بأنها تسليم إلى صندوق الوارد. فحدث المزوّد الذي يتضمن استجابة نجاح SMTP من الوجهة يدعم حالة «سُلِّمت إلى الخادم». والارتداد يدعم معالجة الإخفاق أو المنع. ولا يدعم أي منهما وعدًا بالظهور أو القراءة أو التفاعل. ويُبقي هذا النموذج الحالة صادقة ويمنع إعادات المحاولة غير الآمنة بعد أن تكون المسؤولية قد انتقلت فعلًا.

استخدم واجهة API الموثقة لـ SendHQ

يمكن للتطبيق أن يتحدث SMTP من خلال مكتبة مزوّد، أو يستدعي واجهة API للبريد الإلكتروني عبر HTTP يتولى مزوّدها نقل البريد عبر الإنترنت تحت تلك الواجهة. يوفر SendHQ واجهة API للبريد الإلكتروني على مستوى مساحة العمل مع فحوصات النطاقات الموثقة وموارد الرسائل الصادرة والواردة والأحداث وقوائم المنع وصناديق الوارد وحدود موارد مساحة العمل. يمكن أن توفر واجهة HTTP API الخاصة به طلبات منظَّمة ومعرّفات وأحداثًا إلى جانب إرسال SMTP المباشر. وهي لا تغير سلوك خادم الوجهة ولا تثبت قبول SMTP أو الوصول إلى صندوق الوارد أو تفاعل المستلِم.

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

ماذا يعني اختصار SMTP؟

SMTP اختصار Simple Mail Transfer Protocol. وهو يحدد كيف يقدّم عملاء البريد وخوادمه الرسائل الصادرة وينقلونها عبر الأوامر والردود والأظرف وبيانات الرسالة والامتدادات لقدرات مثل المصادقة وTLS.

هل يُستخدم SMTP لقراءة البريد من صندوق الوارد؟

لا. SMTP مخصص أساسًا لتقديم البريد الصادر ونقله. أما الوصول إلى صندوق الوارد فيستخدم واجهات أخرى مثل IMAP وPOP أو واجهة API لصندوق بريد خاصة بالمزوّد أو واجهة API للبريد الإلكتروني في التطبيق تعرض الرسائل الواردة المخزّنة.

ما الفرق بين المنافذ 25 و587 و465؟

يُستخدم المنفذ 25 عادةً لترحيل البريد بين الخوادم. والمنفذ 587 هو خدمة تقديم الرسائل القياسية وغالبًا ما يتفاوض على TLS. أما المنفذ 465 فهو مسجَّل للتقديم عبر TLS الضمني. اتبع نقطة النهاية ووضع الأمان الموثّقين لدى المزوّد بدلًا من تبديل المنافذ بالتجربة.

هل يثبت نجاح SMTP أن الرسالة وصلت إلى صندوق الوارد؟

لا. الرد الناجح لا يثبت إلا أن خادم SMTP المجيب قبل الأمر المعني أو مسؤولية الرسالة. ولا يزال النظام المستقبِل قادرًا على تطبيق سياسة لاحقة أو توليد إخفاق متأخر أو تصنيف البريد المقبول خارج صندوق الوارد الرئيسي.

هل ينبغي للتطبيق إعادة محاولة كل رد SMTP من نوع 4xx؟

يدل رمز 4xx على نتيجة سلبية عابرة، لكن إعادات المحاولة ينبغي أن تستخدم طابورًا دائمًا وتراجعًا أُسّيًا مع عشوائية (jitter) وعمرًا محدودًا وحدودًا للمحاولات مراعية للمستلِم. حقّق في الإخفاقات المؤقتة المتكررة بدلًا من إعادة المحاولة إلى ما لا نهاية.

هل HTTP API للبريد الإلكتروني بديل لـ SMTP؟

يمكنها أن تحل محل SMTP في شيفرة التطبيق، لكن المزوّد ما زال يستخدم عادةً SMTP للتواصل مع أنظمة بريد المستلِمين. وتضيف واجهة API مصادقة منظّمة وحمولات وتحديد نطاق للموارد ومعرّفات ومعالجة أحداث فوق طبقة النقل.

المصادر

تابع التعلّم

دليل تنفيذ واجهة API للبريد الإلكتروني لفرق المنتجصمّم تكامل واجهة API للبريد الإلكتروني بأمان مع نطاقات موثَّقة وإرسال عبر الطوابير ومعرّفات ثابتة وإعادات محاولة مضبوطة وأحداث تسليم ومنع وعزل للمستأجرين.