Re: [Exim] $message_id is blank

Philip Hazel wrote:
> On Fri, 13 Jun 2003, Wakko Warner wrote:
>
> > Interpretation... Tell me, what would be the difference between generating
> > a message id at the start of the session (resetting on each reset) instead
> > of after headers are received?
>
> Wasted effort for the cases when the message is refused. I probably
> originally did it the way it is as a copy from smail, which used the
> inode number of the spool file in the id - the spool file isn't created
> until the headers are read. Also, I guess I felt it wasn't necessary to
> create it until it was needed.
>
> The code also uses the existence of a message id to indicate "message
> was received", so changing this would involve checking all those uses.
> There would also have to be some hacking to make the microsecond
> timestamp available in two different modules - at present it is all
> handled in one place.

I see...

> > What I woundup doing is generating a temp ID (something like
> > TMP-${hmac{md5}{}{$pid-$tod_log}} and setting acl_m1 to it) then after data,
>
> $pid-$tod_log isn't unique enough these days - that's why the message id
> format changed in the latest releases of Exim.

I'm running on a linux box which takes a while to wrap around (more than a
second), so this is sufficient for me. Using this is a way for me to look
at the data in SQL (which is what it's for) and if it begins with a TMP-,
I'll know it never completed. I do an update of the tables in the data acl.

The original reason I wanted the message ID is so I could go back to the
log and find it. After posting my original question, I realized that if the
message wasn't fully received, no logs would be written with a message id.

Sorry to have wasted your time with this.

--
Lab tests show that use of micro$oft causes cancer in lab animals