Os padrões RFC literalmente nos forçam a aceitar conexões não criptografadas na porta 25. Para entender o porquê, temos que entender como funciona o envio de e-mail. Mas enviar e-mail é um tema bastante complexo e criei este exemplo junto com uma tabela para tentar entender tudo.
Alguém pode ler e me dizer se estou errado em alguma parte da explicação? Porque não tenho certeza se meu entendimento do assunto está correto.
EXEMPLO
Quando o usuário (remetente) envia e-mail através"agente de usuário de e-mail" (MUA), este e-mail é imediatamente transferido para o"agente de envio de correspondência"(MSA) que está ou não em uma máquina separada. A MSA pré-processa o e-mail e o entrega para"agente de transferência de correio"(MTA) na mesma máquina. O MTA (remetente) então usa o DNS e determina para qual e-mail do MTA (destinatário) deve ser enviado. Esta parte do transporte é feita apenas por porto 25. Quando o MTA (destinatário) recebe o e-mail, ele o transfere para o MSA na mesma máquina e então o usuário (destinatário) pode ler o e-mail usando o MUA.
A comunicação entre MUA e MSA e MSA e MTA pode usar portas seguras, mas a conexão entre MTA e MTA não. A tabela abaixo mostra quais protocolos são usados ou podem ser usados e quais portas podem ser usadas para cada etapa do exemplo acima. Também usamos ✘ e ✔ onde há uma opção para indicar o que uma configuração moderna deve usar.
| # | remetente | receptor | protocolos que podemos usar | portas dos respectivos protocolos |
|---|---|---|---|---|
| 1 | MUÁ | MSA | (✘)SMTP (✔)SMTPS |
(✘) 25(✔) 587 |
| 2 | MSA | MTA | (✘)SMTP (✔)SMTPS |
(✘) 25(✔) 587 |
| 3 | MTA | MTA | (✔)SMTP | (✔)25 |
| 4 | MTA | MSA | (✔)SMTP | (✔)25 |
| 5 | MSA | MUÁ | (✘) POP3 (✘) POP3S (✘) IMAP (✔) IMAPS |
(✘) 110(✘) 995(✘) 143(✔) 993 |
Responder1
Isso se baseia no equívoco de que as portas têm algo a ver com criptografia. No entanto, considero esta uma boa pergunta, pois dá uma oportunidade de corrigir este mal-entendido.
As portas não devem indicar criptografia, mas são usadas para finalidades diferentes:
- A porta
25é usada para SMTP (RFC 5321)retransmissão de mensagementre MTA:s. - A porta
587é usada paraenvio de mensagem(RFC 6409) de MUA para MSA. - Ambos podem ser criptografados com
STARTTLS(RFC 3207). - Além disso, existe o SMTPS que envolve o SMTP (de MUA para MSA) dentro do TLS na porta
465. Este foi registrado em 1997, mas revogado em 1998, quandoSTARTTLSfoi padronizado. No entanto, esta situação foi revertida 20 anos depois, em 2018, quandoRFC 8314agora considera o texto simples obsoleto e traz de volta o TLS implícito para envio POP, IMAP e SMTP.
A maior parte dos e-mails hoje é criptografada em trânsito (entre MTAs), dizRelatório de transparência do Google.
A comunicação entre os MTAs ainda deve aprovar conexões não criptografadas para compatibilidade com versões anteriores e, portanto, é fácil para um intermediário fazer o downgrade da conexão removendo a 250-STARTTLSresposta que indica o suporte para a extensão. No entanto, se o remetente apoiarDANE oportunista(RFC 7672) e o destinatário tiver um TLSAregistro informando que não precisa de tentativas de entrega não criptografadas (como uma exceção à compatibilidade com versões anteriores), esse tipo de ataque falhará.
A ilustração a seguir (CC BY-SA 3.0deAle2006-de-enna WikipédiaAgente de envio de mensagens) mostra as diferentes funções de servidor, e as setas azuis podem ser implementadas por diferentes variações de SMTP. Observe também que o mesmo servidor pode ter múltiplas funções na entrega da mensagem.
Para melhorar sua mesa:
| # | remetente | receptor | protocolos e portas em uso |
|---|---|---|---|
| 1 | MUÁ | MSA | (✘) envio 587com STARTTLS(✔) SMTPS 465com TLS implícito |
| 2 | MSA | MTA | Entrega interna (mesmo servidor com duas funções) |
| 3... | MTA | MTA (possivelmenteMX) | (✘✘) SMTP não criptografado 25(✘) SMTP 25com STARTTLS(✔) SMTP 25, STARTTLSaplicado com DANE |
| N-1 | MX | MDA➔MS | Entrega interna (mesmo servidor com múltiplas funções) |
| N | EM | MUÁ | (✘) IMAP 143com STARTTLS(✔) IMAPS 993com TLS implícito |
As duas últimas etapas não podem ser vistas exatamente como emissor e receptor, pois oAgente de usuário de mensagemO MUA se conecta aoArmazenamento de mensagensMS e puxa a mensagem em vez de push. O MX MTA final entrega o correio ao MS com uma funcionalidade chamadaAgente de entrega de mensagens(MDA). OAgente de envio de mensagens(MSA) refere-se apenas ao envio de correio. Informações mais detalhadas sobre essas definições podem ser encontradas emArquitetura de correio da Internet RFC 5598.