通常,电子邮件在@的右侧有一个域名,因此您可以识别一个组织或公司。实际上,这个域只不过是IP地址的“名称”或“别名”,由名称服务器解析。
例如,我认为这可以用于物联网,因为与“多对一”或“一对多”相比,有更多的可能性。
有没有一种方式可以直接收发来自IP地址的电子邮件,比如user@xxx.xxx.xx.xxx?
发布于 2018-04-04 05:57:53
对于电子邮件,域不仅仅是IP地址的别名或人类可读的形式:邮件交换机MX记录用于指定负责代表收件人域接受电子邮件消息的邮件服务器。可能有几个服务器接受域的邮件,它们不一定位于域的A记录中的同一个IP上。一个邮件系统可以有几个服务器:传入的服务器可能与传出的服务器和邮件存储服务器分离,等等。只有当没有为主机名指定A记录时,才使用MX记录。
但是,电子邮件地址格式没有(其他)限制,您不能直接将电子邮件发送到<user@hostname.example.com>,甚至<user@[198.51.100.10]> (带有方括号的IP)。如果有一个使用普通主机名甚至IP地址接受电子邮件的邮件服务器,就可以了。但你的建议在实践中并不适用于全球:
<user@example.com>可能与<user@example.net>不同。25在消费者级互联网连接上的使用非常有限。在IoT设备上并没有太多的使用SMTP。发布于 2018-04-04 05:53:55
许多SMTP服务器(例如sendmail)处理user@[aaa.bbb.ccc.ddd]电子邮件地址,但是
…此外,该域可能是一个IP地址文本,被方括号[]所包围,例如jsmith@192.168.2.1或jsmith@IPv6 6:2001:Db8::1,尽管除了在电子邮件垃圾邮件中很少看到这一点。…
发布于 2018-04-04 20:18:16
如果所有参与方都使用真正现代化的软件,它就会起作用。
虽然SMTP在TCP上工作得很好,但它本身并不是一个基于TCP/IP的协议,至少在其原始形式中是如此。如果您查看原始的RFC 821,就会定义"TCP传输“.在附录里。
RFC 2821 (1989年起)考虑使用“不鼓励”的数字地址。
更现代的规范版本在某种程度上支持了RFC5321的这一理念:"SMTP独立于特定的传输子系统,只需要一个可靠的有序数据流通道。虽然本文档专门讨论了通过TCP传输的问题,但其他传输是可能的。RFC 821 1的附录描述了其中的一些传输。“
然而,这个RFC --从2008年开始,它实际上是非常新的--允许使用“地址文字”作为“允许”(“为了绕过这一障碍,允许使用一种特殊的地址形式作为域名的替代。”)在第4.1.3节中,但仍不鼓励2.1.4中的“不应”。
SMTP和许多围绕它构建的软件使用主机而不是ip地址作为其“本机货币”--如果“地址文字”可以用作“主机”,那么也可以。同样,在旧的电子邮件生态系统和基于SMTP的系统中使用的非SMTP协议(如UUCP邮件)也是如此。
依赖于每一个涉及的系统完全符合2008年的标准可能比它看起来的风险更大。
https://serverfault.com/questions/905886
复制相似问题