Hi Eric,
On Sat, Jan 09, 2021 at 10:54:28PM +0000, Eric wrote in
<20210109225428.GA27462@dcvr>:
So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
(I noticed this in mutt 2.0.2 on FreeBSD)
Encoding YYYYmmddHHMMSS into the Message-ID doesn't hurt users
privacy in cases where mutt is generating the Date: header.
I agree with you on this. This part of the Message-ID was not a concern for me
and the new message ID's actually still include a timestamp; We are days away
from rolling over from the X* era into the Y* era ;-)
This is a bad change for public mail archives which use
https://$SOMETHING_SOMETHING/$MSGID for robustness across
different public mail archives and hosts.
Having the date information in the Message-ID (and thus archive
URL) is an important reference for quickly identifying the
message date without having to open the URL itself.
This saves readers time and bandwidth.
In my opinion the Message-ID should be just that, an ID which is so unique that
clashes are very very unlikely to occur by accident and that the ID can't be
predicted.
While I agree that there might be some utility in easily identifying the
timestamp from the Message-ID, I would also suggest the Date header is a lot
more useful for this. Whenever I browse mailing list archives online, I usually
am presented with a year and month selection first, and then see a threaded view
of the messages during that period. Given how many of the other (and dare I say
more widely used) email clients produce Message-ID's without a timestamp
incorporated in them, I'd think trying to use Message-ID's in the way you
(propose to) use them is not going to be very useful.
If this is desired, I think the proper place to implement this would be by
incorporating it into how the messages are stored in the public mail archive,
instead of doing it by (just) the Message-ID. To use your format, something in
the form of https://$SOMETHING_SOMETHING/YYYYmmddHHMMSS_$MSGID might work
better and work for all possible Message ID formats.
I agree adding some randomness after YYYYmmddHHMMSS is
necessary, and PID was a bad choice originally; but
YYYYmmddHHMMSS is a good prefix.
The timestamp still is in there, just a little more efficiently encoded. I don't
feel particulary strong on this, other than that I do feel the current approach
addresses most of the concerns I had with the old format. In my view, it is
elegant in that it packs both a timestamp and sufficient randomness in a limited
amount of characters. I'm sorry that you feel this new approach is less useful
or
memorable.
I actually think having good, memorable Message-IDs can help
mutt attract some users away from MUAs/services that generate
less memorable Message-IDs :)
Thanks for reading.
Thank you for the feedback, I do appreciate it!
