Volevo solo sottolineare questo dato che sembra essere diventato un malinteso comune: 587 non è “il futuro”, lo è la TLS implicita sulla porta 465.
Sono giunto a questa rivelazione tramite questo post
E dopo aver letto l’RFC effettiva del 2018 è chiaro: non è che STARTTLS sia la strada da percorrere, è che SMTPS non è la strada da percorrere, e la TLS implicita sulla porta 465 (o 587) è ciò che gli amministratori dovrebbero scegliere in futuro.
Il supporto alla TLS sulla porta 465 non dovrebbe essere classificato (e probabilmente de-prioritizzato) come “mantenimento della compatibilità retroattiva” o qualsiasi nozione simile.
Il meccanismo STARTTLS sulla porta 587 è relativamente diffuso a causa della situazione con la porta 465 (discusso nella Sezione 7.3. Questo differisce dai servizi IMAP e POP dove la TLS implicita è più diffusa sui server rispetto a STARTTLS. È auspicabile migrare nel tempo i protocolli principali utilizzati dal software MUA alla TLS implicita, per coerenza e per le ragioni aggiuntive discusse nell’Appendice A. Tuttavia, per massimizzare l’uso della crittografia per l’invio, è auspicabile supportare entrambi i meccanismi per l’invio di messaggi tramite TLS per un periodo di transizione di diversi anni. Di conseguenza, client e server DOVREBBERO implementare sia STARTTLS sulla porta 587 che TLS implicita sulla porta 465 per questo periodo di transizione. Si noti che non vi è alcuna differenza significativa tra le proprietà di sicurezza di STARTTLS sulla porta 587 e TLS implicita sulla porta 465 se le implementazioni sono corrette e se sia il client che il server sono configurati per richiedere la negoziazione riuscita di TLS prima dell’invio del messaggio.
La transizione non è a submissions sulla porta 587 tramite STARTTLS, ma a submissions tramite TLS implicita sulla porta 465 (al contrario di SMTPS sulla porta 465 che ora è deprecato).