Apenas queria apontar isso, pois parece ter se tornado um mal-entendido comum – 587 não é “o futuro” – TLS implícito sobre 465 é.
Fui levado a essa revelação por este post
E, após ler o RFC real de 2018, fica claro – não é que STARTTLS seja o caminho a seguir, é que SMTPS não é o caminho a seguir, e TLS implícito sobre a porta 465 (ou 587) é o que os administradores devem escolher daqui para frente.
O suporte a TLS sobre 465 não deve ser classificado (e provavelmente ter sua prioridade diminuída) como “manutenção de compatibilidade retroativa” ou qualquer noção semelhante.
O mecanismo STARTTLS na porta 587 é relativamente amplamente implantado devido à situação com a porta 465 (discutida na Seção 7.3. Isso difere dos serviços IMAP e POP, onde o TLS implícito é mais amplamente implantado em servidores do que o STARTTLS. É desejável migrar os protocolos principais usados pelo software MUA para TLS implícito ao longo do tempo, por consistência, bem como por razões adicionais discutidas no Apêndice A. No entanto, para maximizar o uso de criptografia para submissão, é desejável suportar ambos os mecanismos para Submissão de Mensagens sobre TLS por um período de transição de vários anos. Como resultado, clientes e servidores DEVEM implementar STARTTLS na porta 587 e TLS implícito na porta 465 durante este período de transição. Observe que não há diferença significativa entre as propriedades de segurança do STARTTLS na porta 587 e do TLS implícito na porta 465 se as implementações estiverem corretas e se o cliente e o servidor estiverem configurados para exigir a negociação bem-sucedida de TLS antes da Submissão de Mensagens.
A transição não é para submissions sobre 587 via STARTTLS, é para submissions via TLS implícito na porta 465 (em oposição a SMTPS sobre a porta 465, que agora está obsoleta).