[ libetpan-Feature Requests-767269 ] Message-ID suggestion

Feature Requests item #767269, was opened at 2003-07-07 20:32
Message generated for change (Comment added) made by g_roualland
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=767269&group_id=41064

Category: other
Group: libEtPan!
Status: Open
Priority: 1
Submitted By: Melvin Hadasht (mhadasht)
Assigned to: Nobody/Anonymous (nobody)
Summary: Message-ID suggestion

Initial Comment:
Message-ID is currently based on:
- the current epoch as a long (8) hex
- a random number as a long (8) hex
- the currend pid as a short (4) hex
- the hostname where libEtPan is running

I think the Message-ID should not provide more info than
the message headers already provide, so the hostname
should not be used in the message id. 

The current PID does not add much more randomness
compared to the random number. Moreover, it could even
be a privacy issue for the paranoid (messages with same
pid and same hostname in certain intervall of time but
with different From: address could mean the different
addresses belong to the same person.). Although, this
is not an issue as long as we live in a democracy.

I'd propose a new scheme, providing more readability,
more randomness and more privacy:

Let's split the message-ID value in 4 fields:
ETPAN.TIME.RANDOM.LOCAL@DOMAIN

- DOMAIN: this should be related to the email address
and should be the domain part of it. We should not
provide info about the local host. For privacy reasons,
we should provide as less info as possible.
- LOCAL: as we use the DOMAIN that does not belong to
the running instance of libEtPan, but as the DOMAIN is
the domain part of the email address and as that DOMAIN
guarantees the uniqueness of the complete address, we
can use the local part of the email address to two
people having the same domain sending at the same time
and having a bogus random generator will have different
LOCAL field. To shorten the LOCAL part, we would not
use the local part of the email directly but we compute
a hash value. As a hash value may reduce the domaine of
uniqueness, we add to the hash value the value of
clock() (ANSI C function).
- RANDOM: this is the most "random" field that should
guarantee at best the uniqueness of the ID. But as
random generators are not really random (two generators
using the same algorithm and feeded with the same seed
will issue the same sequence of number), the TIME, and
the email address (LOCAL + clock() part and the DOMAIN
part) will guarantee a good level of uniqueness. 
- TIME: the UTC time of message creation. I'd use a
human readable form using the following format:
YYMMDDHHmmss
- ETPAN: etPan field

thus, with the proposed scheme, the message ID would be:
<etPan.030707181201.01234567.89ABCDEF-Tb2yze0ITc8@public.gmane.org>
The proposed scheme has 8 more bytes, 4 more because of
the LOCAL part, and 4 more because of the TIME part.

Readability is enhanced by the human readable creation
time and complete DOMAIN part

Randomness is enhanced by adding a clock() part to the
hash value in the LOCAL part

Privacy is enhanced by using the email address (local
part and domain part) without using the name of the
issuing host. The email address being in the From:
header, using it is not a decrease in privacy.

----------------------------------------------------------------------

Comment By: Gaël Roualland (g_roualland)
Date: 2004-11-14 23:32

Message:
Logged In: YES 
user_id=25267

Some remarks :
- I agree with the use of the local email domain part as
message id domain, although this does not really hide the
hostname; (think of Received headers or NNTP-Posting-Host..)
- Regarding time : is it really needed to be readable ? 
There's already a Date header in the message for this...
More over the suggested time in the message ID would
probably be relative to the local timezone, which is not
very usefull elsewhere.
- As for the local part, I'm not sure that it's better than
one more random number, especially when using a good PRNG
such as /dev/random.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=767269&group_id=41064


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8