--- Comment #7 from Jeremy Harris <email@example.com> ---
On single identifiers for message lines -
- I think HS had a notion of allocating the message_id earlier in the receive
sequence, which would help here.
- It still wouldn't tie together pre-MAIL-command actions: things done in
connect ACL, helo ACL, authentication...
I guess we could invent a connection identifier, and log that also.
- It wouldn't tie together multiple messages on a connection, if that was
On "output when message processing completes" - you'd then have no visibility
of any message with a recipient still on the queue. I don't think that's
what you want?
It's also moot for the one-JSON-document-per-line approach (treating certain
current multi-line log items as single "logical" lines for this purpose).
It'd be up to still-required postprocessing to tie together all the records
for a message for this approach.
There's a problem with logging done by ACL log_message/logwrite too; unless we
invent reams of specialised stuff for it the best we could do is a freeform
string item tagged with the message_id - the config-file facilities know
of JSON facilities for logging currently. Designing syntax for saying "use a
JSON object with <blah> name" for this log string might sounds hard.
The hardwired log items are where the advantage, such as it is, comes. Exim
knows the semantics of each element of the log "line", and can label JSON
unambiguously (vs. the current text lines where not all items have a LABEL=
leader, and some can have embedded spaces).
None of the above addresses defining the schema, which is a significant effort.
We'd also have to maintain both log formats, making the choice configurable.
You are receiving this mail because:
You are on the CC list for the bug.
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##