Quais sender IDs e corpos de mensagem uma conta pode usar, e o que é carimbado nos que casam.
conf.whitelist.enabled é padrão on
Então a chave mestra é a que decide. Um listener precisa dar opt-out.
smsg.whitelist.max.variable amplia todo template de uma vez
Subir isto amplia todo template aprovado no deployment simultaneamente. É o maior false-accept que
este design tem, então é logado em INFO e reportado como max_variable em /ops/health.
Os três modos de stamping
off é o padrão de propósito. Se assign fosse o padrão, começaria a escrever TLVs em pacotes
cruzando listeners que nunca escreveram nenhum. Uma mudança silenciosa no que chega a uma carrier.O relatório de cobertura do painel de controle é o que torna off descobrível em vez de simplesmente
quieto: ele diz, por linha aprovada, quais tags obrigatórias nada vai fornecer.
replace porque é o que a entrada REST fazia antes de o modo existir e um
upgrade não pode mudar comportamento.
O check do lado de fornecedor é diferente
O check por listener roda na entrada. O check por fornecedor roda contra o que de fato vai para o
fio, depois de default.tlvs.submit e depois de registered.tlvs.submit ter filtrado.
Uma mensagem faltando uma tag obrigatória lá é recusada com um receipt FAILED, um refund e uma linha
cdr_rejected. Não é re-roteada. Exigir uma tag que não está também em
registered.tlvs.submit nunca pode ser satisfeito, e é avisado no load.
Isenções por produto vivem no banco
app_product.whitelist_enabled = false isenta aquele produto completamente. O painel conta isso
quando decide se enforcement é seguro. Uma aprovação registrada sob um produto isento não protege
nada.
Toda chave acima é de fato lida por listener. Uma chave omitida fica na forma nua e lê um global que
ninguém define, então lê seu padrão independentemente de como você configure.
whitelist.tlvs.replace foi assim uma vez e não carimbou nada por SMPP enquanto durou.
0xC3. Veja Códigos de
status. Para o caminho de rollout, veja Fazendo rollout de
whitelisting. 