Bounce classifier
Hard and soft is the wrong split. A 4xx that repeats for three days is a block wearing a retry code, and a 5xx for a full mailbox will clear on its own. What decides your next move is the enhanced code and the text beside it, not the first digit.
Why hard and soft bounce is not enough
A full mailbox, a rate limit and a reputation block all arrive as soft bounces, and they need opposite responses. Retry the full mailbox and it may clear. Retry the rate limit and you make it worse. Retry the reputation block and you damage the sending IP further while the underlying problem goes unfixed.
So the classifier answers with an action rather than a severity:
- retry: temporary at the receiving end. The normal schedule handles it.
- throttle: you are sending faster than this provider will accept. Drop concurrency for that provider only, not globally.
- suppress: permanent. Remove the address. Retrying costs reputation and dormant addresses turn into spam traps.
- pause: a reputation or blocklist problem. Stop sending to this provider from this IP and fix the cause before resuming.
- review: a content or recipient-side policy rule. Change the message, not the rate.
- fix_config: an authentication failure. No amount of retrying helps.
Where the ruleset comes from
The same ordered ruleset as smtpsift, exported at build time rather than retyped, so this page and the command-line tool cannot disagree about what a response means. Nothing is trained: it is regular expressions matched in order, first match wins, because a classifier you cannot explain is the wrong thing to put in front of a decision about whether to keep sending.
Recognised a response the classifier did not? That is a missing rule, and worth telling me about.