Arnt Gulbrandsen wrote in
 <[email protected]>:
 |Hi,
 |
 |https://gitlab.com/muttmua/mutt/-/work_items/453 notes that some 
 |people consider the local hostname to be private information, and 
 |requests that Message-ID not contain the local hostname.
 |
 |Some MUAs use the sending domain, which I don't really like. It's 
 |fine for your own domain, but many people use gmail addresses.
 |
 |Message-ID: 
 |<[email protected]>
 |needs a LOT of entropy in the localpart in order to be safely 
 |unique.
 |
 |However, the sending domain isn't conveniently available at that 
 |spot in the code.
 |
 |Another alternative is to use a domain from the MUA, I like that 
 |better, so I suggest the below as a solution for #453. The 
 |repeated %r gives 120 bits of entropy while keeping the message-id 
 |fairly short.
 |
 |I removed the time. I don't see the value of including the time, 
 |it's bulky and reminds me of the passage on Knuth vol 2 where he 
 |"attempted to create a fantastically good", etc. The best 

Fwiw i for one am in the totally different camp regarding date.
I hate that "over-randomization".  The Message-ID is what makes an
email identifiable, and being able to deduce things only from
looking at it i perceive with sympathy; only from glancing over it
i know certain things.  I mean, Grace Jones, o-ha.  Hm!  You know?

It is also used for Maildir names, and really, a mail message and
a Date: belong together.  For example i could derive from

  Steffen Nurpmeso wrote in
   <20260324144838.Lop5n115@steffen%sdaoden.eu>:

  It has been over two months since i sent this message

without looking again at the Date: of the original message.  Cool,
eh?  Having said that certain IETF moderators silently discard
message, so likely that will not show up until i complain, but
that not before next week.
For the MUA i maintain i did

 [message-id]
 If unset or empty, or if results are shorter 10 bytes or without
 randoms ‘%Y%m%d%H%M%S.%r%r@%a’ is used.  Date and time are in
 UTC (Coordinated Universal Time).

   ‘%%’      Doubling avoids expansion.
   ‘%a’      Sender address, with ‘@’ replaced by ‘%’ because some
             spam detectors trigger otherwise for unknown reasons.
             If unavailable equals ‘%h’.
   ‘%d’      Two-digit day.
   ‘%H’      Two-digit hour (24-hour notation).
   ‘%h’      Either hostname† or the real hostname; if unavailable
             equals ‘%r%r’.
   ‘%M’      Two-digit minute.
   ‘%m’      Two-digit month.
   ‘%r’      A base64-URL (RFC 4648) encoded random string of size
             four (4).
   ‘%S’      Two-digit second.
   ‘%Y’      Four-digit year.

(We do $hostname stuff distinctly from mutt.  But the formats are
in parts stolen from mutt.)

 |protection against clashing message-ids is IMO to spend the entire 
 |length on high-entropy randomness and avoid low-entropy components 
 |like the time. If we can increase the length, it's IMO better to 
 |spend the extra length on more entropy.

"More entropy" than 8 bytes of base64-encoded random and an ISO
8601 date to the second per sending address.

Btw why that effort .. if the IETF pushes through that DKIM2, and
they will, what is in Received: is nothing against that.  Right.?.

 |Arnt
 |
 |diff --git a/init.h b/init.h
 |index af684866..ae3760f9 100644
 |--- a/init.h
 |+++ b/init.h
 |@@ -2202,7 +2202,7 @@ struct option_t MuttVars[] = {
 |   { "msg_format",       DT_SYN,  R_NONE, {.p="message_format"}, {.p=0} },
 |   /*
 |   */
 |-  { "message_id_format", DT_STR, R_NONE, {.p=&MessageIdFormat}, {.p="<%\
 |z@%f>"} },
 |+  { "message_id_format", DT_STR, R_NONE, {.p=&MessageIdFormat}, {.p="<%\
 |r%r%r%[email protected]>"} },
 |   /*
 |   ** .pp
 |   ** This variable describes the format of the Message-ID generated
 --End of <[email protected]>

(I had a CX 25, Prestige, thirty-five years ago; but that was
slave to the rhythm, was it.  Great car!)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Reply via email to