Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To replaceme nt text)

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Wed, 2 Jun 1999 09:46:30 -0700

Yes, but the message-format draft currently suggests:

	be globally unique. In order to do this, a common practice is to
form 
	the local-part by using a combination of the current absolute time
and 
	some other currently unique identifier on the host (for example a
system 
	process identifier).

My (albeit naive) reading of this is that the algorithm recommended is to
concatenate the result of time() with the process ID.  I might suggest that
if this portion of the specification is intended to be authoritative, more
words might be suggested.

For example:

In order to do this, a common practice is to form the local-part by using a
combination of the current absolute time and some other currently unique
identifier on the host (for example a system process identifier) and a
strictly increasing counter.  Care must be taken to ensure that the
granularity of the absolute time is sufficiently fine as to guarantee that
the process ID+counter value cannot be reused within the absolute time
interval.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 7:45 PM
> To: Larry Osterman (Exchange)
> Cc: 'Keith Moore'; 'Matt Curtin'; 'Robert Elz'; Pete Resnick; DRUMS
> Subject: Re: Message-ID (was: RE: Take 2: References/In-Reply-To
> replaceme nt text) 
> 
> 
> > Cool - I didn't know that there were "reasonable" operating 
> systems out
> > there that actively worked to prevent handle re-use across time 
> 
> I don't know of any UNIX systems that can reuse the same PID within a 
> tick of the system clock.  so if you do PID + clock + per-process 
> serial #, you're in good shape.
> 
> > > so should RFC822-bis also include a warning about the 
> security risks of
> > > basing message-ids on hardware serial numbers (as in when 
> UUIDs are used)?
> > 
> > Only if DRUMS also includes a warning about the security 
> risks of including
> > a dns name in a message-id.  
> 
> seems fair.
> 
> Keith
>

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Jun 1999 03:14:44 +1000

Date:        Wed, 2 Jun 1999 09:46:30 -0700 
    From:        "Larry Osterman (Exchange)" <[email-masked]>
    Message-ID:  <01D6C7224936D211BA450000F805D53805421690@TOTO>

  | My (albeit naive) reading of this is that the algorithm recommended is to
  | concatenate the result of time() with the process ID.

It is, and you're right, this should probably be improved.  As stated
it works fine on almost every unix system around (process id's simply can't
and don't get re-used within a second - neither because of a reboot, which
no unix system I have ever seen can do in a second, nor because of simple
reuse, as they just aren't reused that fast - process ids on unix are not a
table index).

But the whole world is not unix, and that text doesn't say that the algorithm
as stated is unix specific.

I'd suggest:

	In order to do this, a common practice is to form 
	the local-part by using a combination of the current absolute time
	and some other currently unique identifier on the host which cannot
	be reused within the granularity of the timestamp.   On some systems
	a process identifier will serve for the latter.

We don't (necessarily) need another counter, the process id can serve
on its own.   On the other hand, if the process-id isn't sufficient by
itself, and a counter would be needed, then the process-id would add nothing
useful, and the extra identifier might just as well be the counter.   Or, if
the system has a clock with sufficient precision that the same value can
never be returned twice (it increments faster than the time taken to read it)
then that could be used alone.

What is really important here is that what will work is system and
implementation dependant, and there is no single "right" answer.   This
yet again reinforces the need for a proper RHS to correctly establish
the algorithm used by the LHS.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jun 1999 06:22:51 -0000

Robert Elz writes:
> process id's simply can't and don't get re-used within a second

False. Process IDs are assigned sequentially, but on most UNIX systems
they wrap around after 30000. A process that lasts longer than the
wrap-around time can have its process ID reused immediately. This
happens many times a day on busy systems.

This is a minor tangent on the already minor issue of Message-IDs, but
there are other applications where it's very important.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Jun 1999 17:59:22 +1000

Date:        6 Jun 1999 06:22:51 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | False. Process IDs are assigned sequentially, but on most UNIX systems
  | they wrap around after 30000. A process that lasts longer than the
  | wrap-around time can have its process ID reused immediately. This
  | happens many times a day on busy systems.

Yes, you're right, I had forgotten that border case.   However, as mailers
don't tend to run all day (or anything close to it), this isn't generally
much of an issue.   That is, the part of the mailer which takes the user's
message and adds in the generally machine generated fields (like Message-Id).

It does highlight the care needed in constructing a message-id uniqueness
algorithm though.  To account for the case above, the algorithm would merely
need to take the timestamp from the time it's process started running
(always) - then if the process just happened, for some obscure reason, to
run all day amd hence allow the possibility of another mailer being assigned
the same process id immediately after it finished, the timestamp field would
serve to distinguish the two cases.

  | This is a minor tangent on the already minor issue of Message-IDs, but
  | there are other applications where it's very important.

Yes.

kre

ps: there are some unix systems where process-ids are not assigned
sequentially, though even on those, immediate re-use doesn't seem to occur.

---

From: [email-masked] (Kai Henningsen)
Date: 06 Jun 1999 18:42:00 +0200

[email-masked] (Robert Elz)  wrote on 03.06.99 in <[email-masked]>:

> never be returned twice (it increments faster than the time taken to read
> it) then that could be used alone.

You're missing the purpose of the counter. It's for the case where your  
process needs to produce more than one message-id per timestamp  
granularity. Reuse isn't the problem it's supposed to cure (and it's not  
particularly good at curing it).

And in any case, reuse can be easily cured by making sure you won't  
generate a message id before your timestamp has changed at least once.  
Though I'd probably rather simply insert a random number.

MfG Kai