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 à POST et 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 [email protected] par exemple?
Pour les e-mails, un domaine n'est pas simplement un alias ou un formulaire lisible par l'homme pour une adresse IP: échangeur de messagerieMX des enregistrements existent pour spécifier les serveurs de messagerie chargés d'accepter les e-mails au nom du destinataire. domaine. Il peut y avoir plusieurs serveurs acceptant le courrier pour le domaine, et ils ne sont pas nécessairement sur la même adresse IP qui se trouve dans l'enregistrement A pour 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'enregistrement A n'est utilisé que si aucun enregistrement MX 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 à <[email protected]> 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 en tant que
<[email protected]>peut être une personne différente de<[email protected]> - 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é sur les connexions Internet grand public en raison d'abus (spambots). Il n'y a pas vraiment beaucoup d'utilisation de SMTP pour les appareils IoT.
De nombreux serveurs SMTP (par exemple, sendmail) gèrent user@[aaa.bbb.ccc.ddd] adresses e-mail [~ # ~] mais [~ # ~]
- Certains serveurs SMTP ne le gèrent pas/ne le reconnaissent pas
Ils peuvent refuser d'accepter cette adresse d'expéditeur ou être dans l'impossibilité d'envoyer à cette adresse. - Ces adresses peuvent provoquer des problèmes avec certains logiciels anti-spam
RFC-5322: 3.4.1. Spécification Addr-Spec
Wikipedia: adresse e-mail - partie du domaine
… De plus, 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 vu, sauf dans le courrier indésirable . …
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 un" NE DEVRAIT PAS "dans 2.1.4.
SMTP, et une grande partie du logiciel construit autour de lui, utilise hôtes, pas adresses ip, comme sa "monnaie native" - si un "littéral d'adresse" est utilisable comme " Host ", 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 des 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.