É possível enviar e receber um email de um endereço IP em vez de um domínio?

Question

Normalmente, um email tem um nome de domínio no lado direito do @, para que você possa identificar uma organização ou uma empresa. Este domínio é, na verdade, nada mais do que um "nome" ou um "alias" para um endereço IP, resolvido pelo servidor de nomes.

Acho que isso poderia ser usado, por exemplo, para a Internet das Coisas, porque há muito mais possibilidades em comparação ao POST e GET, como "muitos para um" ou "um para muitos".

Existe uma maneira de enviar e receber e-mails diretamente de e para um endereço IP, como [email protected] por exemplo?

    

Answer 1

Para e-mails, um domínio não é apenas um alias ou um formulário legível para um endereço IP: mail exchanger MX records existe para especificar servidores de e-mail responsáveis por aceitar mensagens de e-mail em nome de um destinatário domínio. Pode haver vários servidores aceitando e-mail para o domínio e eles não estão necessariamente no mesmo IP que está no registro A do domínio. Um sistema de correio pode ter vários servidores: os servidores de entrada podem ser separados dos servidores de saída e de armazenamento de mensagens, etc. O registro A é usado apenas quando não há registros MX especificados para o nome do host.

No entanto, não há (outro) limite no formato de endereço de e-mail que você não pode enviar e-mails diretamente para <[email protected]> ou mesmo <user@[198.51.100.10]> (IP com os colchetes). Se houvesse um servidor de e-mail que aceitasse e-mail usando o nome de host simples ou até mesmo o endereço IP, ele funcionaria. Mas o que você está sugerindo não funciona globalmente na prática:

• A maioria dos sistemas de email tem vários domínios e precisa lidar com emails separadamente para todos eles. O nome de usuário em si pode não ter sido vinculado a nenhuma caixa de correio real, pois <[email protected]> pode ser uma pessoa diferente de <[email protected]>
• Embora esse seja um par comum de décadas atrás, o combate ao spam tornou as coisas mais complicadas e a aceitação de e-mails tem limites estritos.
• O uso da porta SMTP 25 é muito limitado em conexões de Internet do consumidor devido a abuso (spambots). Não há realmente muito uso de SMTP para dispositivos IoT.

Answer 2

Muitos servidores SMTP (por exemplo, sendmail) manipulam user@[aaa.bbb.ccc.ddd] endereços de e-mail MAS

1. Alguns servidores SMTP não lidam com / reconhecê-lo
   Eles podem se recusar a aceitar o endereço do remetente ou não conseguir enviar para tal endereço.
2. Tais endereços podem causar problemas com alguns softwares anti-spam

RFC-5322: 3.4.1. Especificação Addr-Spec

Wikipedia: endereço de e-mail - parte do domínio

… In addition, the domain may be an IP address literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in email spam. …

    

Answer 3

Deve funcionar se todas as partes envolvidas usarem software realmente moderno.

Embora o SMTP funcione bem em camadas no TCP, ele é, pelo menos na sua forma original, não em si um protocolo BASEADO no TCP / IP. Se você olhar para o RFC 821 original, um "transporte TCP" é definido .... em um apêndice.

A RFC 2821 (de 1989) considera o uso de endereços numéricos "desencorajados".

Até mesmo versões mais modernas das especificações sustentam essa filosofia até certo ponto, da RFC5321: "O SMTP é independente do subsistema de transmissão particular e requer apenas um canal de fluxo de dados ordenado confiável. Enquanto este documento discute especificamente transporte sobre TCP, outro transportes são possíveis. Os apêndices do RFC 821 [1] descrevem alguns deles. "

No entanto, este RFC - de 2008, que na verdade o torna NOVO, sanciona o uso de "literais de endereço" como "permitido" ("Para contornar essa barreira, uma forma literal especial do endereço é permitida como uma alternativa" para um nome de domínio. ") na Seção 4.1.3, mas ainda assim desencoraja-o como" NÃO DEVE "em 2.1.4.

O SMTP, e grande parte do software construído em torno dele, usa hosts , não endereços IP , como sua "moeda nativa" - se um "literal de endereço" for utilizável como um "host", assim seja. E o mesmo aconteceu com os protocolos (não obsoletos) não-SMTP (por exemplo, correio UUCP) que foram usados no ecossistema de e-mail antigo junto com sistemas baseados em SMTP.

Confiar em todos os sistemas envolvidos, estando em total conformidade com um padrão de 2008, pode ser mais arriscado do que parece.