A return address that explains itself

The task. A bounce or complaint arrives several days after sending. Figuring out which client, campaign and recipient it concerns means either parsing a report whose format differs for every receiver, or reading the address it arrived at.

What it is made of:

• <bounce-processor> — identifies a bounce report and writes an rb record;
• verp — a unique return address for each recipient;
• <feedback-loop-processor> — the same for complaints, by its own address list;
• job-header — the campaign label in accounting records.

The parts have different scopes. The processors are node-level, and their lists are matched against the address the message arrived at; changing the bounce processor’s list requires a restart. Both require the node to accept this mail: for complaints, to be the MX of the complaint domain.

How they interact. The manual recommends a unique address per message directly — something like customer1-campaign563-uniqueID498294@bounce.yourdomain.com — and the idea generalizes: such an address names the campaign and the recipient by itself, and identification becomes a lookup rather than an interpretation. VERP generates such addresses itself, so the two halves of the scheme are one solution from different ends: at submission and at receipt. The scheme does not eliminate the variety of formats: identification is reliable, parsing is not, so unidentified reports are worth keeping.