Selecting the fields that answer questions

The task. Questions answered by accounting fields — whether delivery was encrypted, which proxy it went through, after how many failures — come up after the campaign. But a field not named in advance did not get into the file, and there is no data for that period.

What it is made of:

• dlvTlsProtocol — whether delivery was actually encrypted; next to it is dlvTlsCipher;
• numRetries — how many failed attempts there were before delivery; next to it are timeFirstAttempt and totalSecondsQueued;
• dlvProxyName — which proxy the delivery went through;
• bounceCat — the bounce category: for b records it is in the default set, for d it is not.

The parts have different scopes. Fields are selected per record type in each <acct-file> block, so a node can write a detailed file for one consumer and a sparse one for another. Record types are selected the same way: by default only d and b.

How they interact. This is one decision, not four: what a delivery record must say. Without these fields it says the message arrived; with them — with what transport protection, through which proxy, after how many failures and how long it all took. The cost is bytes per record; the limitation is that a field works only going forward.