>> 2) The recommendation for Message-IDs is to use a domain name for the >> right-hand side > >Recommendation or rule? I don't recall.
Officially, from RFC 5322 §3.6.4: Note: As with addr-spec, a liberal syntax is given for the right- hand side of the "@" in a msg-id. However, later in this section, the use of a domain for the right-hand side of the "@" is RECOMMENDED. Again, the syntax of domain constructs is specified by and used in other protocols (e.g., [RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore incumbent upon implementations to conform to the syntax of addresses for the context in which they are used. [...] The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this. Since the msg-id has a similar syntax to addr-spec (identical except that quoted strings, comments, and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right-hand side of the "@" (since domain names and IP addresses are normally unique), and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left-hand side. Though other algorithms will work, it is RECOMMENDED that the right-hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left-hand side within the scope of that domain. >> 4) Some people, for reasons I would classify as "vague", prefer to >> generate their Message-IDs locally so their saved copy of the >> message has the Message-ID in it. > >The reason you state seems precise rather than vague. I mean, that's not a reason in my thinking? Like, WHY do people want that? That's where things get vague when this came up before. >> 7) There's not too much prior art here to crib from because of (3). > >The first-hop MTAs would be a source of prior art. Most probably let >the domain part be given as configuration. Well, I was talking about prior art from MUAs. For MTAs that represent an email domain, it's relatively straightforward because they assume that they're the only one generating Message-IDs for that email domain. FWIW, I took a quick look at the MTAs Postfix and Sendmail; Postfix does not seem to have any Message-ID-specific configuration knobs, it hardcodes adding a Message-ID based on it's idea of the local hostname. Sendmail, yes, it looks like you could change it if you really want to; it also defaults to something based on the local hostname. I am personally skeptical that people actually configure this. And, well, we TRY to use the local hostname to generate the Message-ID for the people who actually want that (because being unique is a MUST in RFC 5322). But as we've seen there's not a fullproof way of doing that. >I think the existing -messageid option which takes either ‘local’ or >‘random’ should also accept ‘@...’ to allow the user to specify it. >This stops using heuristics if the user prefers. My personal feeling is that the people who (a) care about generating a local Message-ID, and (b) actually care WHAT appears right of the '@' either need to configure their system appropriately or write code to change nmh behavior. --Ken