The task. One recipient or one submission source behaves unevenly, and the breakage must be observed over time rather than caught with a single attempt. The recording must be narrow so as not to flood the log, and removed as soon as the answer is obtained.
What it is made of:
The parts have different scopes. The directives are documented for the source, but are also written in the recipient block: outbound recording in the recipient’s <domain>, inbound in the <source> for the submitting program’s address. The narrowness of the block is what keeps the volume down.
How they interact. The connection log and the command log complement each other: the first gives the session boundaries, the second what is inside, and reading a recording with only one of the two is guesswork. Data is a third level on top, not a replacement. No line expires by itself, and the manual does not say how much the byte-level stage writes.
Three levels:
| Line | What it writes | When to turn on |
|---|---|---|
| log-connections | connection start and end | together with the next one |
| log-commands | commands and replies | the first step of diagnosing a connection |
| log-data | bytes as text and in hexadecimal | only when line endings or non-printable characters are suspected |
<domain outlook.com> log-connections yes log-commands yes</domain>
grep -rn -B3 'log-commands yes\|log-data yes' /etc/pmta/