Est-il possible d'envoyer et de recevoir un e-mail à partir d'une adresse IP plutôt qu'à partir d'un domaine?

Habituellement, un e-mail a un nom de domaine sur le côté droit du @, vous pouvez donc identifier une organisation ou une entreprise. Ce domaine n'est en fait rien d'autre qu'un "nom" ou un "alias" pour une adresse IP, résolu par le serveur de noms.

Je pense que cela pourrait être utilisé par exemple pour l'Internet des objets, car il y a beaucoup plus de possibilités par rapport au POST et au GET comme "plusieurs à un" ou "un à plusieurs".

Existe-t-il un moyen d'envoyer et de recevoir des e-mails directement depuis et vers une adresse IP, comme user@xxx.xxx.xx.xxx par exemple?

email smtp email-server

— Peter Mortensen
source

En plus: si vous pensez que HTTP est trop restrictif pour l'IoT, jetez un œil à MQTT ou XMPP.

— Roger Lipscombe

Un domaine est plus qu'un «nom pour une adresse IP». Un domaine peut publier beaucoup plus d'informations sur son service de messagerie (via ses entrées DNS), qui peuvent inclure plusieurs adresses IP pour plusieurs serveurs de messagerie (par exemple à des fins d'équilibrage de charge ou de secours).

— jjmontes

Le courrier électronique n'est pas un à plusieurs non plus, c'est un à un, puis le serveur peut diffuser le message à plusieurs. Vous pouvez envoyer un message http à un serveur, puis demander à de nombreux clients de lire ce serveur dans le même modèle que celui utilisé par la messagerie électronique.

— djsmiley2k dans l'obscurité

En tant que personne qui doit régulièrement faire de l'archéologie réseau, veuillez ne pas coder en dur les adresses IP. DNS n'est pas difficile, et les serveurs DNS comme dnsmasq sont légers tout en permettant des remplacements d'hôte. Les IP Internet changeront avec le temps.

— Criggie

Le domaine n'est pas un alias pour une adresse IP. Plus précisément, le courrier électronique a des enregistrements MX où le nom de domaine correspond à un ou plusieurs tuples contenant à la fois une priorité et un nom d'hôte (où le courrier électronique sera remis). Vous mélangez deux concepts différents: nommer (qui l'envoyer aussi) et adresser (où l'envoyer).

— Patrick Mevzek

Réponses:

Pour les e-mails, un domaine n'est pas simplement un alias ou un formulaire lisible par l'homme pour une adresse IP: des MX enregistrements d' échangeur de courrier existent pour spécifier les serveurs de messagerie responsables de l'acceptation des e-mails au nom du domaine d'un destinataire. Il peut y avoir plusieurs serveurs acceptant le courrier pour le domaine, et ils ne sont pas nécessairement sur la même IP que celle Aenregistrée dans le domaine. Un système de messagerie peut avoir plusieurs serveurs: les serveurs entrants peuvent être séparés des serveurs sortants et des serveurs de stockage de courrier, etc. L' Aenregistrement n'est utilisé que si aucun MXenregistrement n'est spécifié pour le nom d'hôte.

Cependant, il n'y a aucune (autre) limite dans le format d'adresse e-mail à laquelle vous ne pouvez pas envoyer d'e-mails directement <user@hostname.example.com>ou même <user@[198.51.100.10]>(IP avec crochets). S'il y avait un serveur de messagerie qui accepte les e-mails en utilisant le nom d'hôte simple ou même l'adresse IP, ce serait le cas. Mais ce que vous proposez ne fonctionne pas globalement dans la pratique:

La plupart des systèmes de messagerie ont plusieurs domaines et doivent gérer le courrier électronique séparément pour tous. Le nom d'utilisateur lui-même peut ne pas avoir été lié à une boîte aux lettres réelle, car il <user@example.com>pourrait s'agir d'une personne différente de celle<user@example.net>
Alors que cela était courant il y a quelques décennies, la lutte contre le spam a rendu les choses plus compliquées et l'acceptation des e-mails a des limites strictes.
L'utilisation du port SMTP 25est très limitée sur les connexions Internet de qualité grand public en raison d'abus (spambots). Il n'y a pas vraiment beaucoup d'utilisation de SMTP pour les appareils IoT.

— Esa Jokinen
source

Mais s'il n'y a pas d'enregistrement MX dns pour un domaine (ou une adresse IP), le courrier est remis (ou tenté d'être remis à) la partie domaine de l'adresse e-mail (nom d'hôte ou adresse IP). Et le serveur de réception doit être configuré pour gérer le courrier pour ce nom d'hôte / cette adresse IP.

— ivanivan

Il peut gérer le courrier pour le nom d'hôte. Tous les serveurs du monde ne gèrent pas du tout le courrier. La plupart des serveurs basés sur Unix / Linux ont un serveur SMTP pour gérer le courrier interne (à partir de cron, etc.), mais ils peuvent aussi bien fonctionner sans.

— Esa Jokinen

Esa - si vous pointez votre enregistrement MX vers mes serveurs postfix, une connexion SMTP sera établie MAIS mes serveurs ne sont pas configurés pour gérer le courrier de votre domaine de quelque manière que ce soit, vous obtenez donc un rebond. MAIS mes serveurs sont configurés pour plusieurs domaines et utilisateurs spécifiques, tous provenant d'un serveur mysql. Tout dépend de 1) Un serveur de messagerie fonctionne-t-il réellement à l'adresse IP à laquelle vous envoyez du courrier et 2) Ce serveur de messagerie est-il configuré pour accepter le courrier destiné à cette adresse IP ou simplement un domaine / des domaines spécifiques, ou n'importe quel domaine (uniquement correspondant à la partie utilisateur de l'adresse)

— ivanivan

De nombreux serveurs SMTP (par exemple, sendmail) gèrent les user@[aaa.bbb.ccc.ddd]adresses e-mail MAIS

Certains serveurs SMTP ne les gèrent pas / ne les reconnaissent pas.
Ils peuvent refuser d'accepter une telle adresse d'expéditeur ou être incapables d'envoyer à cette adresse.
De telles adresses peuvent causer des problèmes avec certains logiciels anti-spam

RFC-5322: 3.4.1. Spécification Addr-Spec

Wikipédia: adresse e-mail - partie du domaine

… En outre, le domaine peut être un littéral d'adresse IP, entouré de crochets [], comme jsmith @ [192.168.2.1] ou jsmith @ [IPv6: 2001: db8 :: 1], bien que cela soit rarement observé sauf dans spam par e-mail . …

— AnFi
source

Notez que les adresses e-mail comme user@[aaa.bbb.ccc.ddd]sont correctes selon les spécifications et que la gestion est correctement définie, donc les serveurs qui ne le gèrent pas sont techniquement "cassés"

— Ferrybig

@Ferrybig: Vrai, car le rejet est aussi une manipulation technique.

— Esa Jokinen

Notez que "les e-mails ont été envoyés à une adresse IP spécifique plutôt qu'à un hôte" se classe assez haut dans la catégorie des drapeaux rouges "probablement du spam" et de nombreux logiciels AVAS peuvent décider de les rejeter en silence.

— Shadur

Cela devrait fonctionner si toutes les parties impliquées utilisent un logiciel vraiment moderne.

Bien que SMTP fonctionne bien en couches sur TCP, ce n'est, au moins dans sa forme originale, pas en soi un protocole BASÉ sur TCP / IP. Si vous regardez la RFC 821 d'origine, un "transport TCP" est défini .... dans une annexe.

La RFC 2821 (de 1989) envisage d'utiliser des adresses numériques "déconseillées".

Des versions encore plus modernes des spécifications soutiennent dans une certaine mesure cette philosophie, tirée de la RFC5321: "SMTP est indépendant du sous-système de transmission particulier et ne nécessite qu'un canal de flux de données ordonné fiable. Bien que ce document traite spécifiquement du transport via TCP, d'autres transports sont possibles Les annexes de la RFC 821 [1] en décrivent certaines. "

Cependant, ce RFC - de 2008, qui le rend très NOUVEAU, sanctionne l'utilisation des "littéraux d'adresse" comme "autorisés" ("Pour contourner cette barrière, une forme littérale spéciale de l'adresse est autorisée comme alternative à un domaine nom. ") dans la section 4.1.3 mais le décourage toujours comme" NE DEVRAIT PAS "dans 2.1.4.

SMTP, et une grande partie du logiciel construit autour de lui, utilise des hôtes , pas des adresses IP , comme sa «monnaie native» - si un «littéral d'adresse» est utilisable comme un «hôte», qu'il en soit ainsi. Il en a été de même pour les protocoles non SMTP (pour la plupart obsolètes) (par exemple, le courrier UUCP) qui étaient utilisés dans l'écosystème de la messagerie électronique ancien avec les systèmes SMTP.

S'appuyer sur la conformité totale de chaque système impliqué avec une norme de 2008 pourrait être plus risqué qu'il n'y paraît.

— rackandboneman
source

La RFC 5321 # 2.1.4 ne sanctionne pas l'utilisation de littéraux d'adresse: elle indique NE DEVRAIT PAS (et ensuite des liens vers la mauvaise section). Et le RFC 2821 n'est pas si vieux - c'était en 2001.

— Rup

Je dirais que cela prouve mon point entre les lignes :) .. intégré une clarification sur cette "micro-sanction", thx

— rackandboneman