مصطلح · منفذ SMTP

أي منفذ SMTP ينبغي أن يستخدمه التطبيق للبريد الإلكتروني؟

ينبغي لمعظم التطبيقات استخدام نقطة نهاية الإرسال والمنفذ اللذين يوثقهما مزوّد البريد الإلكتروني. المنفذ 587 هو منفذ إرسال الرسائل القياسي وعادةً ما يبدأ بـ SMTP عادي قبل ترقية STARTTLS. المنفذ 465 هو إرسال رسائل مع TLS ضمني، لذا تبدأ مصافحة TLS فورًا. المنفذ 25 مخصص أساسًا لترحيل SMTP من خادم إلى خادم، لا لإرسال التطبيقات الروتيني المصادَق عليه. يجب أن يطابق الإعداد العامل أربعة أمور معًا: اسم المضيف والمنفذ ووضع TLS وطريقة المصادقة.

يحدد منفذ SMTP دور البروتوكول ووضع الاتصال

رقم المنفذ ليس مجرد باب قابل للتبديل إلى الخدمة نفسها. فهو يساعد في تحديد دور SMTP الذي يقدّمه الخادم وكيف يبدأ الاتصال. تسليم الرسائل (submission) هو أول تسليم من تطبيق أو وكيل مستخدم إلى خدمة تسليم. أما الترحيل (relay) فهو نقل البريد بين خوادم البريد. تفصل المعايير بين المهمتين لأن التسليم قد يتطلب مصادقة وتفويض المُرسِل وفحوص سياسة الرسالة التي لا تنطبق بالطريقة نفسها على الترحيل العام للبريد. ويمكن أن يشير المنفذ أيضًا إلى ما إذا كان العميل يبدأ بأوامر SMTP ثم يرقّي لاحقًا عبر STARTTLS أو يبدأ بمصافحة TLS فورًا. تعامل مع اسم مضيف المزوّد والمنفذ ووضع TLS وتعليمات المصادقة بوصفها مجموعة إعداد واحدة. فنسخ منفذ من مزوّد لا صلة له، أو تغيير المنفذ وحده بعد خطأ، قد يحوّل مشكلة شبكة إلى إخفاق في TLS أو المصادقة دون علاج السبب الأصلي.

المنفذ 25 مخصص أساسًا لترحيل خوادم البريد

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

المنفذ 587 هو منفذ تسليم الرسائل القياسي

يخصص RFC 6409 المنفذ 587 لتسليم الرسائل ويصف خدمة تسليم تستطيع رفض البريد غير المصرح به واشتراط المصادقة وفرض السياسة قبل قبول رسالة جديدة. تبدأ جلسة المنفذ 587 الشائعة بوصفها SMTP، وتعلن عن امتداد STARTTLS بعد `EHLO`، وترقّي الاتصال إلى TLS، وتكرر `EHLO`، وتصادق، ثم تسلّم الرسالة. وكلمة «الشائعة» مهمة: فآليات المصادقة الدقيقة ومتطلباتها تأتي من وثائق المزوّد الحالية وإمكانات الخادم. ينبغي للعميل الآمن أن يشترط ترقية TLS المتوقعة وأن يتحقق من شهادة الخادم بدلًا من المتابعة دون تشفير بعد فشل التفاوض. ولا تخلط بين تحية بروتوكول أولية غير مشفّرة وجلسة موثَّقة غير محمية؛ فقد صُمّم STARTTLS لترقية الاتصال قبل إرسال بيانات الاعتماد وبيانات الرسالة. يحدد المنفذ 587 خدمة التسليم، بينما يعتمد نجاح فرض TLS على سياسة العميل الصحيحة.

يستخدم المنفذ 465 TLS الضمني للتسليم

المنفذ 465 مسجَّل لتسليم الرسائل عبر TLS الضمني. ومع TLS الضمني يجري العميل مصافحة TLS بمجرد فتح اتصال TCP ولا يرسل أوامر SMTP إلا داخل القناة المحمية. يختلف هذا عن المنفذ 587 مع STARTTLS، حيث يتلقى العميل أولًا تحية SMTP ثم يطلب الترقية. ويوصي RFC 8314 بـ TLS الضمني للتسليم، ويصف في الوقت نفسه انتقالًا يستطيع فيه المزوّدون والعملاء دعم المنفذ 465 مع TLS الضمني والمنفذ 587 مع STARTTLS. ويلاحظ RFC أن العملاء والخوادم المنفَّذة بشكل صحيح قادرة على توفير أمان متكافئ إلى حد كبير في أي من الوضعين عندما يكون TLS إلزاميًا. والقاعدة العملية ألا يُعلن أن منفذًا واحدًا صحيح عالميًا. استخدم النقطة والوضع اللذين يدعمهما المزوّد بالضبط. فضبط STARTTLS على مستمع TLS ضمني، أو TLS الضمني على مستمع STARTTLS، يفشل عادةً قبل المصادقة.

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

يقدّم بعض المزوّدين منافذ بديلة للالتفاف على قيود الشبكة، لكن هذه الأرقام ليست معايير SMTP عالمية لكل خدمة. توثّق Amazon SES حاليًا STARTTLS على المنافذ 25 و587 و2587، وTLS Wrapper، وهو مصطلحها لـ TLS الضمني، على المنفذين 465 و2465. وتشترط SES اتصالات مشفّرة وتنشر نقاط SMTP خاصة بكل منطقة. يوضح هذا لماذا يجب أخذ المنفذ من وثائق المزوّد المختار لا من قائمة عامة. فالمنفذ 2587 لا يعني STARTTLS في كل مكان، والمنفذ 2465 لا يحدد خدمة TLS ضمني على مضيفات عشوائية. كما أن المنافذ البديلة لا تتجاوز توثيق المُرسِل ولا نطاق بيانات الاعتماد ولا الحصص ولا سياسة المزوّد. سجّل عنوان URL للمصدر وتاريخ التحقق مع إعداد الإنتاج ليستطيع المشغّل التمييز بين إعداد مقصود لدى المزوّد و«رقم سحري» غير مفسَّر نُسخ إلى متغير بيئة قبل سنوات.

اضبط اسم المضيف والمنفذ وTLS والمصادقة معًا

إعداد SMTP المتين حزمة واحدة: اسم مضيف المزوّد والمنفذ ووضع أمان النقل وسياسة التحقق من الشهادة وآلية المصادقة واسم المستخدم والسر ومهلة الاتصال وهوية الإرسال. اسم المضيف مهم لأن شهادة TLS يُتحقق منها مقابله ولأن المزوّدين قد يعرضون نقاط نهاية إقليمية مختلفة. ويجب أن يتفق المنفذ ووضع TLS. وينبغي أن تجري المصادقة فقط بعد وجود القناة المحمية المقصودة، وأن تبقى الأسرار في مدير أسرار لا في شيفرة المصدر أو حزم المتصفح أو السجلات أو مخرجات التشخيص. وافصل بيانات الاعتماد والإعدادات بحسب البيئة حتى لا يرسل اختبار محلي عبر الإنتاج عن غير قصد. وحدّد مهلات اتصال وأوامر محدودة، لكن اترك إعادة محاولات الرسائل لطابور تطبيق دائم. وقد يعني خيار في مكتبة اسمه `secure` TLS الضمني في SDK ومجرد اشتراط STARTTLS في آخر، لذا تحقق من تعريف المكتبة واختبر السلوك المتفاوَض عليه بدلًا من الاعتماد على اسم الخيار.

اختبر الاتصال على طبقات دون كشف الأسرار

ابدأ بتحليل DNS وإمكانية الوصول عبر TCP من شبكة وقت التشغيل نفسها التي يعمل عليها التطبيق. تشير المهلة قبل الاتصال إلى التوجيه أو الجدار الناري أو سياسة الخروج لدى المزوّد أو اسم مضيف خاطئ أو منفذ مغلق. ثم اختبر وضع TLS المتوقع. في TLS الضمني ينبغي أن يتلقى عميل TLS شهادة ثم تحية SMTP. وفي STARTTLS ينبغي أن يتلقى عميل يدرك SMTP التحية، ويصدر `EHLO`، ويرى STARTTLS معلَنًا، ويطلب الترقية، ويتحقق من الشهادة، ويصدر `EHLO` مرة أخرى بعد TLS. يشترط RFC 3207 أن يتخلص العميل والخادم من المعرفة المكتسبة قبل المصافحة، ولهذا يهم `EHLO` الثاني. وعندها فقط اختبر المصادقة بحساب مضبوط. واحجب أسماء المستخدمين والرموز وعناوين المستلِمين ونصوص الخادم الكاملة ومحتوى الرسائل قبل مشاركة السجلات. ولا يحتاج فحص الاتصال إلى إرسال إنتاجي ولا إلى عنوان عميل حقيقي.

صنّف الإخفاقات بحسب المرحلة التي أخفقت فعلًا

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

نجاح المنفذ ليس تسليم رسالة ولا وصولًا إلى صندوق الوارد

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

اختر بين تسليم SMTP وواجهة API للبريد عن قصد

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

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

هل ينبغي أن يستخدم تطبيقي منفذ SMTP 587 أم 465؟

استخدم المنفذ ووضع TLS اللذين يوثّقهما مزوّدك. يستخدم المنفذ 587 عادةً STARTTLS، بينما يستخدم المنفذ 465 TLS الضمني. وكلاهما يستطيع حماية التسليم عند تنفيذه بشكل صحيح وفرضه؛ ويجب أن يطابق إعداد العميل مستمع الخادم.

لماذا يُحجب منفذ SMTP 25 أو تنتهي مهلته؟

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

هل أستطيع التبديل من المنفذ 587 إلى 465 دون تغيير أي شيء آخر؟

عادةً لا. يبدأ المنفذ 587 عادةً بـ SMTP ثم يُرقّى عبر STARTTLS، بينما يبدأ المنفذ 465 بمصافحة TLS فورية. غيّر المنفذ ووضع TLS في العميل معًا، وفق وثائق المزوّد والمكتبة.

هل المنفذ 587 مشفّر افتراضيًا؟

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

ماذا يعني رفض اتصال SMTP (connection refused)؟

يعني أن وجهة TCP رفضت الاتصال قبل تفاوض SMTP. وتشمل الأسباب الشائعة مضيفًا أو منفذًا خاطئًا، أو خدمة لا تستمع، أو رفض جدار ناري، أو نقطة نهاية للمزوّد غير متاحة من تلك الشبكة.

هل يثبت اختبار منفذ SMTP الناجح تسليم البريد؟

لا. فهو لا يثبت سوى المراحل التي أكملها الاختبار فعلًا، مثل TCP أو TLS. أما المصادقة وقبول الرسالة وقبول الخادم الوجهة ومعالجة الارتداد وتصنيف صندوق البريد وتفاعل المستلِم فتتطلب أدلة منفصلة ويجب الإبلاغ عنها على حدة.

المصادر

تابع التعلّم

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