The RFC 5322 as cited is concerned about domains and their internet address, where the sender's address needs to be resolvable through DNS by the recipient. If the email infrastructure serves local messages in a company, then LAN addresses get the job done. But delivering messages across autonomous systems calls for *public* fully qualified domain names and their *public* IP addresses, or the delivery will fail.
-------- Original Message -------- On Sep 23, 2021, 19:56, Grant Taylor < gtay...@tnetconsulting.net> wrote: On 9/23/21 2:38 AM, Rupert Gallagher wrote: > A LAN address is not the "Internet address of the particular host", and > therefore, by RFC 5322 line 969, the header in the OP is not RFC compliant. Sure it is. What you refer to as a "LAN address" is in fact an Internet (Protocol) address just like what you re referring to as an "Internet address". The only effective difference is the values assigned to them. Both of them function identically from a technological stand point. Particularly as viewed by the end systems. The only difference between them is an agreed upon convention of how / where the different address values are used. -- That is a human imposed requirement and definitely not a technical requirement. The closest that it comes to a technical requirement is that the Internet at large does not have routes for RFC 1918 IP addresses. This lack of routes has been chosen by humans for the aforementioned agreed upon convention. There is no /technical/ reason that RFC 1918 IP addresses can't be routed across the Internet. -- We have all experienced leaks of RFC 1918 addresses at some point. What's more is that RFC 5322 § 3.6.4 ¶ 5 states: The message identifier is intended to be machine readable and not necessarily meaningful to humans. Further, the entire message ID is what's to be globally unique. And using a domain or a globally routed IP address via domain-literal on the RHS is the RECOMMENDED way to achieve global uniqueness. But there are other ways. If we take meaning for humans out, we can have something like the "Message-ID: <omissis@43f011297907b952855484a6635191ff>" That's the same domain-literal converted to an MD5 hash. It complies with obs-id-right -> domain -> obs-domain -> atom -> atext. "Message-ID: <omissis@[IPv6::ffff:193.168.1.30]>" So why does "43f011297907b952855484a6635191ff" work for the id-right when you say that "[IPv6::ffff:193.168.1.30]" doesn't work for the id-right? They are both the same information, just different representations. If you don't like MD5 because it's lossy, how about Base64 "W0lQdjY6OmZmZmY6MTkzLjE2OC4xLjMwXQ==". You seem to be enforcing that the id-right be meaningful to humans, when RFC 5322 explicitly states that such is not necessary. If you do not super-impose human conventions on top of the Message-ID, then the Message-ID that Rupert asked about is perfectly valid. If you do super-impose human conventions on top of the Message-ID, then say that you are doing so. But know that you are going above and beyond the RFC. I believe in the same spirit that grey listing did years ago. Do so if you want to, but admit that you are doing so. -- Grant. . . . unix || die
