Demo
Demo

Knowledge base

PMTA knowledge base›Accounting record§ 12.2

Permanently bounced

critical

b
The message will not be delivered to this recipient

The recipient permanently did not receive the message — either the receiving server refused for good, or the node itself bounced the message when the deadline expired.

The record type letter is b. It comes first in the line, and that is how the parser tells one type from another.

This is where the bounce category and the receiving server’s reply text live. This record is what the decision to remove an address is based on.

A message bounced by the node on deadline and one rejected by the receiving server end up in the same record type. The category tells them apart: an expired deadline has its own, and it is about us, not about the address.

The main trap is counting things from the wrong records. One record type answers one question, and a substitution gives a plausible wrong number: attempts instead of messages, queues instead of recipients, the day a report was received instead of the day of sending.
What the Hub does. It reads them — the records arrive as a stream through a webhook, and all the analytics is built on them: volumes, deliverability, bounces by category.
Recommended values

Which question this record answers:

Question Is it this record
the message will not be delivered to this recipient yes
how many messages in total only together with the other types
why it happened look at the reply text, not at the record type

Record types are enabled and disabled in the accounting block. A disabled type does not disappear from a report — it disappears from the data, and the absence of events becomes indistinguishable from there genuinely being none.

The separation of questions is ours. From the manual here are the condition under which the record appears and its letter.
Example configuration
# the first letter of the line is the record type
b,2019-02-08 21:53:41+0000,...
Parsing accounting starts with this letter: all the other columns make sense only in combination with it.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

2 relations

Does not work without

Bounce categoryThe classification any decision to remove an address rests on. § 12.2.2

Depends on

The bounce category in accounting — configurable, not vendor-fixedThe patterns that assign this category. § 12.6

Referenced from

Parsed bounce from outsideThe same outcome, but learned from a report email rather than from the conversation with the receiver. § 12.2.6

How to check on the node
How many records of each type arrived:
grep -c "^b," /var/log/pmta/acct-*.csv
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
Zero while sending is going on means one of two things: there are no events of this kind, or the record type is disabled in the accounting block. The second command helps tell them apart — it prints a summary across all types.
◇

What else to read

3 articles

◇The bounce category in accounting — configurable, not vendor-fixedThe bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.◇Parsing bounces that arrive as messagesBounce reports that arrive as messages are parsed by a separate processor — and it runs before the complaint processor.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Bounce classification · Address suppression
Priority
critical