أردت فقط الإشارة إلى هذا الأمر نظرًا لأنه يبدو أنه أصبح سوء فهم شائع - 587 ليس “المستقبل” - بل TLS الضمني عبر 465 هو.
لقد قادني هذا المنشور إلى هذا الاكتشاف
وبعد قراءة وثيقة RFC الفعلية من عام 2018، يتضح الأمر - ليس أن STARTTLS هو الطريق إلى الأمام، بل أن SMTPS ليس هو الطريق إلى الأمام، وأن TLS الضمني عبر المنفذ 465 (أو 587) هو ما يجب على المسؤولين اختياره للمضي قدمًا.
لا ينبغي تصنيف دعم TLS عبر 465 (ومن المحتمل تقليل أولويته) على أنه “الحفاظ على التوافق مع الإصدارات السابقة” أو أي مفهوم مشابه.
آلية STARTTLS على المنفذ 587 منتشرة على نطاق واسع نسبيًا بسبب الوضع مع المنفذ 465 (المناقش في القسم 7.3. يختلف هذا عن خدمات IMAP و POP حيث يكون TLS الضمني أكثر انتشارًا على الخوادم من STARTTLS. من المرغوب فيه ترحيل البروتوكولات الأساسية التي تستخدمها برامج MUA إلى TLS الضمني بمرور الوقت، من أجل الاتساق بالإضافة إلى الأسباب الإضافية التي تمت مناقشتها في الملحق أ. ومع ذلك، لزيادة استخدام التشفير للإرسال، من المرغوب فيه دعم كلتا الآليتين لإرسال الرسائل عبر TLS لفترة انتقالية تمتد لعدة سنوات. ونتيجة لذلك، يجب على العملاء والخوادم تنفيذ كل من STARTTLS على المنفذ 587 و TLS الضمني على المنفذ 465 لهذه الفترة الانتقالية. لاحظ أنه لا يوجد فرق كبير بين خصائص الأمان لـ STARTTLS على المنفذ 587 و TLS الضمني على المنفذ 465 إذا كانت التطبيقات صحيحة وإذا تم تكوين كل من العميل والخادم لطلب التفاوض الناجح على TLS قبل إرسال الرسالة.
الانتقال ليس إلى submissions عبر 587 عبر STARTTLS، بل إلى submissions عبر TLS الضمني على المنفذ 465 (على عكس SMTPS عبر المنفذ 465 الذي تم إيقافه الآن).