Qual é a diferença entre as portas 465 e 587?

245

Essas portas 465 e 587 são usadas para enviar e-mails (enviando e-mails), mas qual é a diferença real entre elas?

email  smtp  port  postfix-mta  email-client 
— Ilia Rostovtsev
fonte
1
A única diferença são os padrões formalizados e a porta 465 é para suporte legado?
— Ilia Rostovtsev 03/04
o "Nome do Serviço e Registro do Número da Porta do Protocolo de Transporte" da iana é o guia formal para o uso recomendado de portas; o uso do 465 para SMTP sobre SSL não é oficial. Leia sobre portas no SMTP . O uso oficial da iana nem sempre é o mesmo para os protocolos de transporte TCP e UDP. NB: se você é o administrador do servidor SMTP , VOCÊ controla quais portas são usadas; se você é o cliente , você obtém apenas portas disponibilizadas para você.
— usar o seguinte código
— Ciro Santilli escreveu:
— Rick

Respostas:

235

Protocolo SMTP: smtps (porta 465) v. Msa (porta 587)

As portas 465 e 587 destinam-se à comunicação do cliente de email com o servidor de email - enviando email usando o protocolo SMTP.

A porta 465 é para smtps A
criptografia SSL é iniciada automaticamente antes de qualquer comunicação no nível SMTP.

A porta 587 é para msa.
É quase como a porta SMTP padrão. O MSA deve aceitar o email após a autenticação (por exemplo, após o SMTP AUTH). Ajuda a interromper o spam de saída quando os netmasters de intervalos DUL podem bloquear as conexões de saída com a porta SMTP (porta 25).
A criptografia SSL pode ser iniciada pelo comando STARTTLS no nível SMTP se o servidor suportar e o seu ISP não filtrar a resposta EHLO do servidor (relatado em 2014) .

A porta 25 é usada pela comunicação MTA para MTA (servidor de email para servidor de email). Pode ser usado para comunicação cliente-servidor, mas atualmente não é o mais recomendado. A porta SMTP padrão aceita email de outros servidores de email para suas caixas de correio "internas" sem autenticação .

— AnFi
fonte
7
A porta SMTP padrão aceita email de outro servidor de email sem autenticação - não é tecnicamente correto. A porta 25 padrão pode transferir correio usando autenticação e não dependendo da configuração do MTA.
— Ilia Rostovtsev 03/04
2
A porta SMTP padrão da Itália do MTA normal não pode rejeitar (todas) conexões SMTP não autenticadas.
— ANFI
1
E o Postfix? Não permite a retransmissão de email por padrão, mas apenas para conexões da mesma rede ?
— Ilia Rostovtsev 03/04
4
@Ilia Também há e -mails recebidos nos domínios de e- mail locais.
— AnFi
6
Observe que, embora não oficial, a porta 465 oferece ao usuário final mais segurança de que ele está realmente falando sobre um canal criptografado. A porta 587, com o TLS sendo opcional, significa que um usuário final pode estar fornecendo suas credenciais em um canal não criptografado. Como os clientes de email são o que são, você não pode garantir que o MUA alertará o usuário que a conexão foi rebaixada.
— Sporker 19/05/19
132

587 vs. 465

Essas atribuições de porta são especificadas pela IANA (Internet Assigned Numbers Authority) :

  • Porta 587 : [SMTP] Envio de mensagens (SMTP-MSA), um serviço que aceita o envio de email de clientes de email (MUAs). Descrito na RFC 6409.
  • Porta 465 : Diretório de encontro de URLs para SSM (totalmente não relacionado ao email)

Historicamente, a porta 465 foi inicialmente planejada para o "invólucro" de criptografia e autenticação SMTPS sobre SMTP, mas foi rapidamente preterida (em meses e mais de 15 anos atrás) em favor do STARTTLS sobre SMTP (RFC 3207). Apesar disso, provavelmente existem muitos servidores que suportam o invólucro de protocolo descontinuado, principalmente para oferecer suporte a clientes mais antigos que implementaram o SMTPS. A menos que você precise oferecer suporte a clientes mais antigos, o SMTPS e seu uso na porta 465 devem permanecer apenas uma nota de rodapé histórica.

O termo irremediavelmente confuso e impreciso, SSL , costuma ser usado para indicar o wrapper SMTPS e o TLS para indicar a extensão do protocolo STARTTLS .

Para completude: Porta 25

  • Porta 25 : SMTP-MTA ( Simple Mail Transfer ), um serviço que aceita o envio de email de outros servidores (MTAs ou MSAs). Descrito na RFC 5321.

Fontes:

— danorton
fonte
1
boa explicação técnica, estava procurando SSL vs TLS.
— kiranking
11
SMTPS and its use on port 465 should remain nothing more than an historical footnote. Exceto que o Gmail e a maioria dos outros provedores de email usam a Porta 465 para SSL, também conhecida como SMTPS. É uma realidade que não vai a lugar nenhum, não importa o que a IANA especifique.
— Eric J.
6
@EricJ. ... Mas o gmail também suporta a porta 587. Você sabe qual porta o Google usa internamente? Caso contrário, o fato de que eles suportam o 465 não conta realmente como evidência de que é preferível ou mesmo particularmente usado.
— Tiro parta
2
Bem, estamos em 2018 e não vejo nenhuma porta se tornando história. 456ainda está sendo usado por grandes jogadores. Além disso, eu editaria minha resposta para refletir que a IANA está uma bagunça e eles ainda não concordam se devem 456ou não usar - RFC 8314 tools.ietf.org/html/rfc8314#page-6 - When a TCP connection is established for the "submissions" service (default port 465), a TLS handshake begins immediately- Este RFC é referenciado por seu Link "Porta 456" :) - data do registro: 12/12/2017
1
"Rendezvous" ortografia já foi corrigido no iana.org
— Arni
19

A resposta correta para esta pergunta foi alterada pela publicação da RFC 8314 . Como resultado, as portas 465 e 587 são portas válidas para um agente de envio de email (MSA). A porta 465 requer negociação de TLS / SSL na configuração da conexão e a porta 587 usa STARTTLS se optar por negociar o TLS. O registro da IANA foi atualizado para permitir o uso legítimo da porta 465 para esse fim. Para retransmissão de email, apenas a porta 25 é usada, portanto, STARTTLS é a única maneira de executar o TLS com retransmissão de email. É útil pensar na retransmissão de mensagens e no envio de mensagens como dois serviços muito diferentes (com muitas diferenças de comportamento, como exigir autenticação, tempos limite diferentes, regras diferentes de modificação de mensagens etc.) que usam um protocolo de conexão semelhante.

— Chris
fonte
É melhor usar a porta 465 ou 587?
— Aaron Franke
Se você estiver executando um serviço SMTP público: ambos para compatibilidade. Se for privado, prefira o TLS implícito no 465, a menos que você deva dar suporte a clientes que não o suportam. Trecho de suporte: "No entanto, para maximizar o uso da criptografia para envio, é desejável oferecer suporte a ambos os mecanismos de envio de mensagens por TLS por um período de transição de vários anos. Como resultado, clientes e servidores DEVEM implementar o STARTTLS nas portas 587 e TLS implícito na porta 465 para este período de transição " tools.ietf.org/html/rfc8314#section-3.3
— Alain O'Dea
4

Porta 465: a IANA reatribuiu um novo serviço a essa porta e não deve mais ser usado para comunicações SMTP.

No entanto, como ela já foi reconhecida pela IANA como válida, pode haver sistemas legados que são capazes apenas de usar esse método de conexão. Normalmente, você usará essa porta apenas se seu aplicativo exigir. Uma rápida pesquisa no Google e você encontrará muitos artigos de ISP de consumidores que sugerem a porta 465 como a configuração recomendada. Espero que isso termine em breve! Não é compatível com RFC.

Porta 587: Esta é a porta de envio de email padrão. Quando um cliente ou servidor de email está enviando um email para ser roteado por um servidor de email adequado, ele deve sempre usar essa porta.

Todos devem considerar o uso dessa porta como padrão, a menos que você seja explicitamente bloqueado pela sua rede upstream ou provedor de hospedagem. Essa porta, juntamente com a criptografia TLS, garantirá que o email seja enviado com segurança e siga as diretrizes definidas pela IETF.

Porta 25: essa porta continua a ser usada principalmente para retransmissão SMTP. A retransmissão SMTP é a transmissão de email do servidor de email para o servidor de email.

Na maioria dos casos, os clientes SMTP modernos (Outlook, Mail, Thunderbird etc.) não devem usar esta porta. É tradicionalmente bloqueado, por ISPs residenciais e provedores de hospedagem na nuvem, para reduzir a quantidade de spam que é retransmitida de computadores ou servidores comprometidos. A menos que você esteja gerenciando especificamente um servidor de email, não deverá haver tráfego atravessando essa porta no seu computador ou servidor.

— Sameer S
fonte
1

Não quero citar nomes, mas alguém parece estar completamente errado. O organismo de normas referenciado declarou o seguinte: submissões 465 tcp Message Submission over TLS protocol [IESG] [IETF_Chair] 12-12-2017 [RFC8314]

Se você é tão inclinado, pode querer ler a RFC mencionada.

Isso parece implicar claramente que a porta 465 é a melhor maneira de forçar a comunicação criptografada e garantir que ela esteja no lugar. A porta 587 não oferece essa garantia.

— Pesquisador
fonte
Por que é melhor usar a porta 465?
— Aaron Franke
1

Eu uso a porta 465 o tempo todo.

A resposta de danorton está desatualizada. Como ele e a Wikipedia dizem, a porta 465 foi inicialmente planejada para a criptografia SMTPS e foi rapidamente descontinuada há 15 anos. Mas muitos ISPs ainda estão usando a porta 465, especialmente para estar em conformidade com as recomendações atuais da RFC 8314 , que incentivam o uso de TLS implícito em vez do uso do comando STARTTLS com a porta 587. (Consulte a seção 3.3 ). Usar a porta 465 é a única maneira de iniciar uma sessão implicitamente segura com um servidor SMTP que atua como um agente de envio de email (MSA).

Basicamente, o que a RFC 8314 recomenda é que as trocas de e-mail em texto não criptografado sejam abandonadas e que todos os três protocolos de correio IETF comuns sejam usados ​​apenas em sessões TLS implícitas para obter consistência, quando possível. As portas seguras recomendadas, portanto, são 465, 993 e 995 para SMTPS, IMAP4S e POP3S, respectivamente.

Embora o RFC 8314 certamente permita o uso continuado de TLS explícito com a porta 587 e o comando STARTTLS, isso abre o agente do usuário de email (MUA, o cliente de email) para um ataque de downgrade no qual um homem do meio intercepta o STARTTLS solicitar atualização para a segurança TLS, mas a nega, forçando a sessão a permanecer em texto não criptografado.

— HJJ
fonte
4
Ele está correto. Só porque os ISPs abusam e não atualizam sua documentação não a torna incorreta. Ele não disse que não é usado - apenas que não é uma prática que segue as RFCs. Em outras palavras, você deve usar 25 e 587 com email e usar somente 465 se precisar, por algum motivo.
— dodexahedron
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.