On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote:
On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote:I would also note that the current message id generation algorithm is deterministic. It's easy to understand how it generates, and to know the exact limitations where it might fail. Swapping out those bits of uniqueness with a random() call takes away the determinism.The tiny (in my opinion too) information leaks, are not worth that trade-off.I think having the message ID being non deterministic would be of greater value. The more deterministic it is, the easier it would be for someone to create a clash.
The opposite, I would say. Unless you mean adversarially. But there is no such threat model: I can easily steal your message id after you've sent the email.
I can't think of an example why someone would want to do that, but I also can't really think of an example where a (fully) deterministic Message-ID would be of value.
The date/time partitions by time. The host by... host. The pid by mutt instance. The counter within a single instance.
With this, I can say that two mutt instances on the same machine won't generate the same message id, even if they are sent within the same second. The same mutt instance also won't do that, unless you send >26 messages in a single second.
Is this perfect? No. But your patch can no longer say even say that. It can merely say "probably".
In my opinion my patch reduces the complexity of the code, albeit in a neglectable way, and also addresses the concerns about information being leaked even when these concerns might be considered tiny or pointless by you/Derek/some/most.
But not without compromising the primary purpose of the id: to be unique.
If there were a *real* threat model, Derek and I would take this more seriously. But I'm not going to backtrack on the generator determinism just to satisfy vague "security" threats.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
