Có thể gửi và nhận email từ một địa chỉ IP thay vì từ một tên miền?

Thông thường, một email có một tên miền ở bên phải của @, vì vậy bạn có thể xác định một tổ chức hoặc một công ty. Trên thực tế, tên miền này không có gì khác ngoài "tên" hoặc "bí danh" cho địa chỉ IP, được giải quyết bởi máy chủ tên.

Tôi nghĩ rằng điều này có thể được sử dụng ví dụ cho Internet of Things, bởi vì có nhiều khả năng hơn so với POST và GET như "many to one" hoặc "one to many".

Có cách nào để gửi và nhận email trực tiếp đến và từ một địa chỉ IP, chẳng hạn như user@xxx.xxx.xx.xxx không?

Đối với email, tên miền không chỉ là bí danh hoặc dạng có thể đọc được của con người đối với địa chỉ IP: tồn tại các bản ghi trao đổi thư MX để chỉ định máy chủ thư chịu trách nhiệm chấp nhận thư email thay cho tên miền của người nhận. Có thể có một số máy chủ chấp nhận thư cho tên miền và chúng không nhất thiết phải trên cùng một IP có trong Ahồ sơ cho tên miền. Một hệ thống thư có thể có một số máy chủ: máy chủ đến có thể được tách ra khỏi máy chủ gửi đi và máy chủ lưu trữ thư, v.v. Bản Aghi chỉ được sử dụng khi không có MXbản ghi nào được chỉ định cho tên máy chủ.

Tuy nhiên, không có giới hạn (khác) trong định dạng địa chỉ email mà bạn không thể gửi email trực tiếp đến <user@hostname.example.com>hoặc thậm chí <user@[198.51.100.10]>(IP với dấu ngoặc vuông). Nếu có một mailserver chấp nhận email bằng tên máy chủ đơn giản hoặc thậm chí địa chỉ IP, nó sẽ làm được. Nhưng những gì bạn đang đề xuất không hoạt động trên toàn cầu trong thực tế:

• Hầu hết các hệ thống email có một số tên miền và cần xử lý email riêng cho tất cả chúng. Tên người dùng có thể không bị ràng buộc với bất kỳ hộp thư thực tế nào vì <user@example.com>có thể là một người khác với<user@example.net>
• Trong khi điều này là phổ biến vài thập kỷ trước, việc chống thư rác đã khiến mọi thứ trở nên phức tạp hơn và việc chấp nhận email có giới hạn nghiêm ngặt.
• Việc sử dụng cổng SMTP 25rất hạn chế đối với các kết nối internet của người tiêu dùng do lạm dụng (spam bots). Thực sự không có nhiều sử dụng SMTP cho các thiết bị IoT.

Nhiều máy chủ SMTP (ví dụ sendmail) xử lý user@[aaa.bbb.ccc.ddd]địa chỉ email NHƯNG

1. Một số máy chủ SMTP không xử lý / nhận ra nó.
   Họ có thể từ chối chấp nhận địa chỉ người gửi đó hoặc không thể gửi đến địa chỉ đó.
2. Địa chỉ như vậy có thể gây ra vấn đề với một số phần mềm chống thư rác

RFC-5322: 3.4.1. Thông số kỹ thuật Addr-Spec

Wikipedia: Địa chỉ email - phần tên miền

... Bên cạnh đó, các tên miền có thể là một địa chỉ IP theo nghĩa đen, được bao quanh bởi dấu ngoặc vuông [], chẳng hạn như jsmith @ [192.168.2.1] hoặc jsmith @ [IPv6: 2001: db8 :: 1], mặc dù điều này hiếm khi được nhìn thấy trừ thư rác . Giáo dục

Nó sẽ hoạt động nếu tất cả các bên liên quan sử dụng phần mềm thực sự hiện đại.

Mặc dù SMTP hoạt động tốt trên lớp, nhưng ít nhất, ở dạng ban đầu, nó không phải là một giao thức DỰA TRÊN TCP / IP. Nếu bạn nhìn vào RFC 821 ban đầu, một "vận chuyển TCP" được xác định .... trong một phụ lục.

RFC 2821 (từ 1989) xem xét sử dụng địa chỉ số "không khuyến khích".

Ngay cả các phiên bản hiện đại hơn của thông số kỹ thuật vẫn duy trì triết lý đó ở một mức độ nào đó, từ RFC5321: "SMTP độc lập với hệ thống con truyền cụ thể và chỉ yêu cầu kênh luồng dữ liệu được đặt hàng đáng tin cậy. Phụ lục của RFC 821 [1] mô tả một số trong số chúng. "

Tuy nhiên, RFC này - từ năm 2008, thực sự rất MỚI, đã xử phạt việc sử dụng "chữ địa chỉ" là "được phép" ("Để vượt qua rào cản này, một dạng địa chỉ đặc biệt của địa chỉ được phép thay thế cho một miền tên. ") trong Mục 4.1.3 nhưng vẫn không khuyến khích nó là" KHÔNG NÊN "trong 2.1.4.

SMTP, và phần lớn phần mềm được xây dựng xung quanh nó, sử dụng máy chủ , không phải địa chỉ IP , như "tiền tệ bản địa" của nó - nếu "địa chỉ bằng chữ" có thể sử dụng như một "máy chủ", thì cũng vậy. Và các giao thức không phải là mã hóa (hầu hết đã lỗi thời) (ví dụ như thư UUCP) đã được sử dụng trong hệ sinh thái email cũ cùng với các hệ thống dựa trên SMTP.

Dựa vào mọi hệ thống liên quan tuân thủ đầy đủ với tiêu chuẩn năm 2008 có thể có nhiều rủi ro hơn nó có vẻ.