ドメインではなくIPアドレスからメールを送受信することはできますか？
通常、メールのドメイン名は@の右側にあるため、組織または会社を識別できます。このドメインは、実際には、ネームサーバーによって解決されたIPアドレスの「名前」または「エイリアス」にすぎません。
POSTおよびGET to "many to one"または "one to many"と比較して、より多くの可能性があるので、これは、例えば、モノのインターネットに使用できると思います。
たとえば、user @ xxx.xxx.xx.xxxのように、IPアドレスと直接メールを送受信する方法はありますか？
電子メールの場合、ドメインは単なるIPアドレスのエイリアスや人間が読める形式ではありません。メールエクスチェンジャMXレコードは、受信者の代わりに電子メールメッセージを受け入れるメールサーバーを指定するために存在しますドメイン。ドメインのメールを受け入れるサーバーがいくつかある可能性があり、それらは必ずしもドメインのAレコードにある同じIP上にあるとは限りません。メールシステムには複数のサーバーを含めることができます。受信サーバーが送信サーバーやメールストレージサーバーなどから分離されている可能性があります。Aレコードは、ホスト名にMXレコードが指定されていない場合にのみ使用されます。
ただし、<[email protected]>または<user@[198.51.100.10]>（角かっこ付きのIP）に直接メールを送信できなかったメールアドレス形式には（その他の）制限はありません。プレーンなホスト名またはIPアドレスを使用して電子メールを受け入れるメールサーバーがあった場合、それは可能です。しかし、あなたが示唆していることは実際にはグローバルに機能しません：
- ほとんどのメールシステムにはいくつかのドメインがあり、それらすべてに対して個別にメールを処理する必要があります。
<[email protected]>は<[email protected]>とは異なる人物である可能性があるため、ユーザー名自体は実際のメールボックスにバインドされていない可能性があります - これは数十年前には一般的でしたが、スパムとの闘いは事態をより複雑にし、電子メールの受け入れには厳しい制限があります。
- SMTPポート
25の使用は、乱用（スパムボット）のために、コンシューマグレードのインターネット接続で非常に制限されています。 IoTデバイスでのSMTPの使用はそれほど多くありません。
多くのSMTPサーバー（sendmailなど）はuser@[aaa.bbb.ccc.ddd]メールアドレス[〜＃〜] but [〜＃〜]
- 一部のSMTPサーバーが処理/認識しない
そのような送信者アドレスの受け入れを拒否したり、そのようなアドレスに送信できない場合があります。 - このようなアドレスは、一部のスパム対策ソフトウェアで問題を引き起こす可能性があります
…さらに、ドメインは、jsmith @ [192.168.2.1]やjsmith @などの角かっこ[]で囲まれたIPアドレスリテラルの場合があります。 [IPv6：2001：db8 :: 1]、これは、電子メールスパム以外ではほとんど見られません。 …
関係するすべての関係者が本当に最新のソフトウェアを使用している場合は、機能するはずです。
SMTPはTCP上で適切に階層化されて機能しますが、少なくとも元の形式では、TCP/IPに基づくプロトコル自体ではありません。元のRFC 821を見ると、付録に「TCPトランスポート」が定義されています。
RFC 2821（1989年から）では、数値アドレスの使用を「非推奨」と見なしています。
RFC5321の仕様のはるかに新しいバージョンの仕様は、その哲学をある程度支持しています。「SMTPは特定の伝送サブシステムに依存せず、信頼できる順序付けられたデータストリームチャネルのみを必要とします。このドキュメントでは、TCPを介した転送について具体的に説明しますが、他の転送も可能です。 。RFC 821 [1]の付録には、それらのいくつかが説明されています。 "
ただし、このRFC-2008年から実際には非常に新しいものになり、「アドレスリテラル」の使用を「許可」として認可しています（「この障壁を回避するために、アドレスの特殊なリテラル形式がドメインの代替として許可されています名前。 "）4.1.3節に記載されていますが、2.1.4では" SHOULD NOT "として推奨されていません。
SMTP、およびその周囲に構築されたソフトウェアの多くは、「ネイティブ通貨」として、IPアドレスではなくホストを使用します-「アドレスリテラル」が「ホスト」、そうそれ。また、SMTPベースのシステムと共に古い電子メールエコシステムで使用されていた（ほとんど旧式の）非SMTPプロトコル（UUCPメールなど）も同様でした。
関係するすべてのシステムが2008年の標準に完全に準拠していると依存することは、見かけよりもリスクが高い可能性があります。