Isso porque a resposta a STARTTLS simplesmente indica que você deve prosseguir e fazer a negociação TLS; ele não significa que o link agora é coberto pelo TLS. Negociação TLS é o processo dos dois sistemas envolvidos, concordando com chaves, trocando certificados, etc., tudo em nome de estabelecer um canal confiável e criptografado entre os dois sistemas.
Citando RFC 2487 (extensão de serviço SMTP para SMTP protegido por TLS), seção 5 The STARTTLS Command :
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
commands.
Veja também a seção 6 Usage Example no mesmo RFC. Observe que elide especificamente o processo real de negociação do TLS.
Quando o servidor espera que você comece a negociar o TLS e, em vez disso, forneça um comando SMTP (ou nem mesmo SMTP), é extremamente provável que seja um erro. Não estou familiarizado com os internos do processo de negociação TLS, mas as probabilidades de que as estrofes MSG FROM: ou MAIL FROM: sejam válidas parecem ser incrivelmente pequenas. O servidor SMTP, neste caso, está bem no seu direito de recusar sua tentativa fracassada de negociação TLS; daí o erro que você recebe de volta.
Além disso , há dois problemas com o seu MSG FROM: [email protected] imediatamente após o STARTTLS :
- Não há comando
MSG FROMno SMTP. A sintaxe apropriada éMAIL FROM:<[email protected]> - A sessão SMTP é redefinida para o estado inicial quando a negociação TLS é concluída (consulte a RFC 2487 seção 5.2), portanto, você deve reiniciar primeiro atribuindo
EHLOou possivelmenteHELO
Se você deseja se conectar a um servidor SMTP que requer STARTTLS, use cliente SSL / TLS do OpenSSL para esse efeito, em vez de telnet. Isso será algo nos moldes de openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 para SMTP STARTTLS. Uma vez que a conexão tenha sido estabelecida, você pode simplesmente usar a conexão SMTP corretamente configurada (comece no EHLO ).