Which sender IDs and message bodies an account may use, and what gets stamped onto the ones that
match.
conf.whitelist.enabled defaults on
So the master switch is the one that decides. A listener has to opt out.
smsg.whitelist.max.variable widens every template at once
Raising this widens every approved template on the deployment simultaneously. It is the largest
false-accept this design has, so it is logged at INFO and reported as max_variable on
/ops/health.
The three stamping modes
off is the default on purpose. Defaulting to assign would start writing TLVs onto packets
crossing listeners that have never written any — a silent change to what reaches a carrier.The control panel’s coverage report is what makes off discoverable rather than merely quiet: it
says, per approved row, which mandatory tags nothing will supply.
replace instead, because that is what the REST ingress did before the mode
existed and an upgrade must not change behaviour.
The vendor-side mandatory check is different
The per-listener check runs at ingress. The per-vendor one runs against what is actually going on
the wire — after default.tlvs.submit and after registered.tlvs.submit has filtered.
A message missing a required tag there is refused with a FAILED receipt, a refund and a cdr_rejected
row. It is not re-routed. Requiring a tag that is not also in registered.tlvs.submit can never be
satisfied, and is warned about at load.
Per-product exemptions live in the database
app_product.whitelist_enabled = false exempts that product outright. The panel counts that when it
decides whether enforcing is safe — an approval filed under an exempt product protects nothing.
Every key above is genuinely read per listener. A key left
out keeps its bare form and reads a global nobody sets, so it reads its default however you configure
it. whitelist.tlvs.replace shipped that way once and stamped nothing over SMPP for as long as it
lasted.
0xC3 — see Status codes.
For the rollout path, see Rolling whitelisting out. 