Improve how Message-IDs are generated so as not to have (rare, if any) duplicates when the right-hand side is the same, especially on virtual hosts.
Message-IDs are currently based on the date, nnrpd's PID and a global static counter incrementing at each post. An improvement could be to also add random bytes from RAND_bytes() if OpenSSL support is available (which is most often the case).
Also, use a 64-character alphabet (with valid characters) instead of the current 32-character alphabet.
If possible, the new Message-ID should be shorter or have the same length as the legacy Message-ID.
A timestamp may be added before the randomness to reduce the chances of a collision to effectively nothing because every second you move into a new message ID space. That takes for instance the date as a number (20220922153000) and represents it in 6 bytes, which is good enough for the next 10 000 years. And then add 8 bytes of randomness.
Improve how Message-IDs are generated so as not to have (rare, if any) duplicates when the right-hand side is the same, especially on virtual hosts.
Message-IDs are currently based on the date, nnrpd's PID and a global static counter incrementing at each post. An improvement could be to also add random bytes from
RAND_bytes()if OpenSSL support is available (which is most often the case).Also, use a 64-character alphabet (with valid characters) instead of the current 32-character alphabet.
If possible, the new Message-ID should be shorter or have the same length as the legacy Message-ID.
A timestamp may be added before the randomness to reduce the chances of a collision to effectively nothing because every second you move into a new message ID space. That takes for instance the date as a number (20220922153000) and represents it in 6 bytes, which is good enough for the next 10 000 years. And then add 8 bytes of randomness.