send-log-format verifiedimportantWritten by the Hub
Shape of a delivery line
send-log-format: [{$date}] {$result.state}:{$result.result} {$attempt} <{if $email.envelope}{$email.envelope}{/if}> <{$email.recipient}> [{$result.from}] [{$result.to}] {$email.tags} {$result.code} {$result.status} {$result.description}Template for each delivery line, with access to any field of the message and of the result, plus conditionals.
Values
- Values
literal text with {$object.path} substitutions and {if …}{/if} conditionals- Default
[{$date}] {$result.state}:{$result.result} {$attempt} <{if $email.envelope}{$email.envelope}{/if}> <{$email.recipient}> [{$result.from}] [{$result.to}] {$email.tags} {$result.code} {$result.status} {$result.description} · taken from the build- applying
restart required- where it can be set
in the config file · with a startup flag · as an environment variable
In detail
The shipped template exposes the structure: {$date}, then {$result.state}:{$result.result}, the attempt number, envelope and recipient in angle brackets, the sending and receiving addresses in square brackets, the tags, and finally code, extended status and the server's own words. {$email} and {$result} are whole objects addressed by path, and {if …}{/if} guards fields that may be missing — the shipped format uses it around the envelope, which can legitimately be empty. The consequence worth acting on: any property we put into a message can be logged. A campaign identifier, a customer id, a warm-up plan number — added to the job as a custom property, it can be written into every delivery line and read back by the collector without touching the message body or the result queues.