On 29-Aug-07, at 1:07 PM, Guy Hulbert wrote:
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
Then forget about the word "security", and let's just say that
people might
want to have unique IDs that'll be unique even when they've got
more than one
server and centralized/aggregated logging... But we're not even
there right
now, "we" are still stuck on how to make the IDs 100% unique
within a single
server as it might be setup by "any" qpsmtpd-user.
There have been several adequate suggestions. This is only a
problem if
it goes into the qpsmtpd core since some of the suggestions are
reported
to be in use already.
That doesn't matter as they haven't created $tran->id - they've just
put something in ->notes() which will continue to work.
Perhaps it would help to agree on a list of requirements. From what I
can remember these are:
1. A unique ID per message (on one server).
2. Ability to distinguish per recipient.
3. Ability to identify the server.
I think you've made #2 confusing... I think what you mean is we want
a new id when the transaction is reset (i.e. same connection, new
email). That's fine.
A sequence solves (1) except for simultaneous processing of
incoming messages via:
a) async
b) threads/multiple cpus
c) local ports (possibly on multiple addresses)
I don't think any of these break when using a the timer. But to
settle that concern I've updated the implementation again to use even
finer grained time (microseconds) and add in rand() in case the
gettimeofday timer is on a slow clock.
So now it's:
"secs.microsecs.rand.pid"
There's a requirement that I'd like to add in: the ability to use the
id as a filename for storage, and have it sort by time.
Except with multiple CPUs, time with sufficient resolution is a
satisfactory replacement for a sequence.
I don't see what difference multiple CPUs makes. Adding in pid takes
care of that.
It may be useful to log things like remote_port but it doesn't seem to
help directly to solve problem 1.
Yup. I removed it now - it was stupid to add it in - I just wasn't
thinking.
A counter solves 2.
Consider counter = rand().
Any tag which is unique per server solves 3. It is probably
simpler to
make this configurable by the end-user.
I've added in a basic hashed version of hostname now.
Matt.
