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

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

Eu acho que isso poderia ser usado, por exemplo, para a Internet das Coisas, porque existem muito mais possibilidades em comparação com o POST e o GET, como "muitos para um" ou "um para muitos".

Existe uma maneira de enviar e receber emails diretamente de e para um endereço IP, como user@xxx.xxx.xx.xxx, por exemplo?

email smtp email-server

— Peter Mortensen
fonte

Além: Se você acha que o HTTP é muito restritivo para a IoT, dê uma olhada no MQTT ou no XMPP.

— Roger Lipscombe

Um domínio é mais do que 'um nome para um endereço IP'. Um domínio pode publicar muito mais informações sobre seu serviço de email (por meio das entradas DNS), que podem incluir vários endereços IP para vários servidores de email (por exemplo, para fins de balanceamento de carga ou fallback).

— Jjmontes 04/04

O email também não é um para muitos, é um para um e, em seguida, o servidor pode espalhar a mensagem para muitos. Você pode fazer uma postagem http em um servidor e fazer com que muitos clientes leiam esse servidor exatamente no mesmo modelo que o email usa.

— djsmiley2k - Cow

Como alguém que periodicamente precisa fazer arqueologia de rede, não codifique IPs. O DNS não é difícil, e servidores DNS como o dnsmasq são leves, permitindo substituições de host. IPs da Internet mudarão com o tempo.

— Criggie

O domínio não é um alias para um endereço IP. Especificamente, o email possui registros MX, nos quais o nome de domínio é mapeado para uma ou várias tuplas, contendo uma prioridade e um nome de host (onde o email será entregue). Você está misturando dois conceitos diferentes: nomear (quem também deve enviá-lo) e endereçar (para onde enviá-lo).

— Patrick Mevzek

Respostas:

Para emails, um domínio não é meramente um apelido ou formulário legível por humanos para um endereço IP: existem registros do trocador de email MX para especificar servidores de email responsáveis por aceitar mensagens de email em nome do domínio de um destinatário. Pode haver vários servidores que aceitam correio para o domínio e eles não estão necessariamente no mesmo IP Aregistrado no domínio. Um sistema de correio pode ter vários servidores: os servidores recebidos podem ser separados dos servidores de saída e dos servidores de armazenamento de correio etc. O Aregistro é usado apenas quando não háMX registros especificados para o nome do host.

No entanto, não há (outro) limite no formato de endereço de email para o qual você não pode enviar emails diretamente para <user@hostname.example.com>ou mesmo <user@[198.51.100.10]>(IP com colchetes). Se houvesse um servidor de correio que aceite e-mail usando o nome de host simples ou mesmo o endereço IP, seria o caso. 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 email separadamente para todos eles. O nome de usuário em si pode não ter sido vinculado a nenhuma caixa de correio real, pois <user@example.com>pode ser uma pessoa diferente da<user@example.net>
Embora isso tenha sido comum há algumas décadas, 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 nas conexões à Internet para consumidores devido a abuso (spambots). Na verdade, não há muito uso de SMTP para dispositivos IoT.

— Esa Jokinen
fonte

Porém, se não houver um registro DNS MX para um email de domínio (ou IP), será entregue (ou tentará ser entregue) a parte do domínio do endereço de email (nome do host ou endereço IP). E o servidor de recebimento deve ser configurado para lidar com o correio para esse nome de host / endereço IP.

— precisa saber é o seguinte

Ele pode lidar com mensagens para o nome do host. Nem todos os servidores do mundo lidam com o correio. A maioria dos servidores baseados em Unix / Linux possui servidor SMTP para lidar com mensagens internas (do cron etc.), mas elas podem funcionar bem sem elas também.

— Esa Jokinen 04/04

Esa - se você apontar seu registro MX para meus servidores postfix, uma conexão SMTP será estabelecida, mas meus servidores não estão configurados para lidar com e-mails para seu domínio de qualquer forma ou formato, para que você receba um retorno. MAS meus servidores estão configurados para vários domínios e usuários específicos, todos provenientes de um servidor mysql. Tudo depende de 1) Um servidor de email está em execução no IP para o qual você está enviando e 2) O servidor de email está configurado para aceitar emails destinados a esse IP ou apenas um domínio / domínios específicos ou qualquer domínio (apenas combinando a parte do usuário do endereço)

— ivanivan

Muitos servidores SMTP (por exemplo, sendmail) lidam com user@[aaa.bbb.ccc.ddd]endereços de email, MAS

Alguns servidores SMTP não os manipulam / reconhecem
Eles podem se recusar a aceitar esse endereço de remetente ou não podem enviar para esse endereço.
Esses endereços podem causar problemas com algum software anti-spam

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

Wikipedia: Endereço de email - parte do domínio

… Além disso, o domínio pode ser um endereço IP literal, entre colchetes [], como jsmith @ [192.168.2.1] ou jsmith @ [IPv6: 2001: db8 :: 1], embora isso raramente seja visto, exceto em spam por email . ...

— AnFi
fonte

Observe que endereços de e-mail como user@[aaa.bbb.ccc.ddd]estão corretos de acordo com a especificação e o manuseio está definido corretamente, para que os servidores que não o

— mantenham

@Ferrybig: Verdade, já que rejeitar é tecnicamente manipular também.

— Esa Jokinen 04/04

Observe que "o email foi enviado para um endereço IP específico, e não para um host", é bastante alto na categoria de sinalizadores "provavelmente spam" e muitos softwares AVAS podem decidir descartá-lo silenciosamente.

— Shadur

Deveria funcionar se todas as partes envolvidas usassem software realmente moderno.

Embora o SMTP funcione bem em camadas no TCP, ele é, pelo menos em sua forma original, não um protocolo baseado em TCP / IP. Se você observar 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".

Versões ainda mais modernas das especificações mantêm essa filosofia, até certo ponto, da RFC5321: "O SMTP é independente do subsistema de transmissão específico e requer apenas um canal de fluxo de dados ordenado e confiável. Embora este documento discuta especificamente o transporte por TCP, outros transportes são possíveis. Os apêndices da RFC 821 [1] descrevem alguns deles ".

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

O SMTP e grande parte do software criado em torno dele usa hosts , não endereços IP , como sua "moeda nativa" - se um "endereço literal" puder ser usado como um "host", que assim seja. E o mesmo fizeram os protocolos não SMTP (principalmente fora de moda) (por exemplo, correio UUCP) que foram usados no ecossistema de email antigo juntamente com os sistemas baseados em SMTP.

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

— rackandboneman
fonte

A RFC 5321 # 2.1.4 não sanciona o uso de endereços literais: diz NÃO DEVE (e vincula à seção errada). E a RFC 2821 não é tão antiga - era 2001.

— Rup:

Eu diria que isso prova minha entre o ponto linhas :) .. integrado um esclarecimento sobre que "micro-sanção", thx

— rackandboneman