通常，电子邮件的 @ 右侧会显示域名，以便识别组织或公司。该域名实际上只不过是 IP 地址的“名称”或“别名”，由名称服务器解析。
我认为这可以用于物联网的例子，因为与 POST 和 GET 相比，有更多的可能性，例如“多对一”或“一对多”。
有没有办法直接通过 IP 地址发送和接收电子邮件，[电子邮件保护]例如？
答案1
对于电子邮件来说，域名不仅仅是 IP 地址的别名或人类可读的形式：邮件交换器 MX记录用于指定负责代表收件人域接收电子邮件的邮件服务器。可能有多个服务器为域接收邮件，并且它们不一定位于A域记录中的同一 IP 上。邮件系统可以有多个服务器：传入服务器可能与传出服务器和邮件存储服务器分开，等等。仅当主机名A没有指定记录时才使用此记录。MX
但是，电子邮件地址格式没有（其他）限制，您不能直接发送电子邮件，甚至（带方括号的 IP）。如果有一个邮件服务器使用纯主机名甚至 IP 地址接受电子邮件，那就可以了。但您的建议在实践中并不适用于全球：<[email protected]><user@[198.51.100.10]>
- 大多数电子邮件系统都有多个域，需要分别处理所有域的电子邮件。用户名本身可能没有绑定到任何实际邮箱，因为用户名可能与
<[email protected]><[email protected]> - 虽然这在几十年前很常见，但打击垃圾邮件使事情变得更加复杂，接受电子邮件也有严格的限制。
- 由于滥用（垃圾邮件机器人） ，SMTP 端口在消费级互联网连接上的使用
25非常有限。物联网设备对 SMTP 的使用并不多。
答案2
许多 SMTP 服务器（例如 sendmail）处理user@[aaa.bbb.ccc.ddd]电子邮件地址但
- 一些 SMTP 服务器无法处理/识别它，
它们可能拒绝接受这样的发件人地址或无法发送到这样的地址。 - 此类地址可能会导致某些反垃圾邮件软件出现问题
…此外，域名可以是 IP 地址文字，用方括号 [] 括起来，例如 jsmith@[192.168.2.1] 或 jsmith@[IPv6:2001:db8::1]，尽管这种情况除了在垃圾邮件中很少见。…
答案3
如果所有相关方都使用真正现代的软件，它应该会起作用。
虽然 SMTP 在 TCP 上工作良好，但它本身（至少在其原始形式下）并不是基于 TCP/IP 的协议。如果您查看原始 RFC 821，则会在附录中定义“TCP 传输”。
RFC 2821（自 1989 年起）认为“不鼓励”使用数字地址。
甚至更现代的规范版本也在某种程度上秉承了这一理念，如 RFC5321 所述：“SMTP 独立于特定的传输子系统，只需要可靠有序的数据流通道。虽然本文档专门讨论了通过 TCP 进行的传输，但其他传输也是可能的。RFC 821 [1] 的附录描述了其中的一些。”
但是，这个 2008 年的 RFC 实际上使其变得非常新，确实在第 4.1.3 节中批准使用“地址文字”为“允许”（“为了绕过这个障碍，允许使用特殊的文字形式的地址来替代域名。”）但在 2.1.4 中仍然不鼓励它，并将其列为“不应该”。
SMTP 以及围绕它构建的大部分软件都使用主办方， 不是IP 地址，作为其“本国货币”——如果“地址文字”可用作“主机”，那就这样吧。旧电子邮件生态系统中与基于 SMTP 的系统一起使用的（大多数过时的）非 SMTP 协议（例如 UUCP 邮件）也是如此。
依赖每个相关系统完全符合 2008 年标准可能比看起来更危险。
答案4
我正在运行一个场景，其中本地设备（NVR）过去在事件发生时向 Google 发送电子邮件，但它不支持 TLS1.2，而且我购买时被告知，如果我尝试修补它，它就会变砖。所以...它可以发送电子邮件，但不再发送给 Google。但它可以使用 IP 将其发送到本地服务器（运行 Postfix 的 Raspberry Pi）上的电子邮件服务器，因为我不想为此设置域。因此不需要 MX 记录或任何奇妙的东西 - 它可能是最不安全的电子邮件服务器......只要它可以转发 TLS1.2，因为我不会将它暴露给外界，否则会将电子邮件发送到我的 gmail 帐户。