Hm, okay, I don't understand enough of what they're discussing there.
For a schema, I'd simply use a spearate key for all possible pieces of
information that can be logged today. The existing labelled fields are a
start, free-form messages would be replaced or enhanced by unique IDs
defining their meaning. Embedded line breaks should be no issue at all
because JSON just uses backslash-escaping like \n. If JSON is to be used.
I cannot imagine there's a relevant existing schema that would suit
Exim. But I don't consider it important. Parsing the log is the hardest
part by far, and something like JSON takes away all of the complexity
immediately. Interpreting the parsed data is application-specific
anyway. For example, I'm not interested in lines like a passed DKIM test
or a broken TLS connection. Those don't describe interesting events on
the server, I couldn't react to them in any way. I'm not even sure I'd
use the "completed" entry for a message ID (that doesn't contain
anything else so I'd have to look up the ID from previously seen entries).
-Yves
-------- Ursprüngliche Nachricht --------
Von: Jeremy Harris via Exim-users <[email protected]>
Gesendet: Freitag, 25. Dezember 2020, 00:47 MEZ
Betreff: [exim] Queue ID format
On 24/12/2020 23:30, Yves Goergen via Exim-users wrote:
Well, if that log was intended for humans, would it be an interesting
idea to write a machine-readable log as well?
See bugs 2142 and 2610. So far, not enough actual interest to
get anyone to put the effort into the developement and maintanence.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
