Expiração e limpeza de filas de SMS A2P: como evitar entregas tardias

Três limites distintos: validade, fila interna e expiração do provedor

A expiração de mensagens SMS A2P não é um único temporizador. Convém manter separados três controles: o prazo funcional, que determina até quando o conteúdo é útil para o destinatário; a política de expiração da fila interna ou do broker; e o período de validade solicitado ao provedor ou ao centro de serviço.

O TP-Validity-Period definido pela 3GPP expressa por quanto tempo o centro de serviço mantém a mensagem antes de concluir a entrega. Ele não equivale ao TTL da fila da aplicação. Além disso, a implementação e o escopo de uma opção de expiração da plataforma variam entre provedores.

Por exemplo, a Twilio documenta um período de validade para o tempo que a mensagem permanece na fila de saída da plataforma. A própria documentação alerta que, depois de enviada à rede das operadoras, a mensagem ainda pode ficar na fila e ser entregue mais tarde. Não transforme esse parâmetro em uma garantia de entrega antes de determinado horário.

• Prazo funcional: até quando faria sentido que o destinatário recebesse esta mensagem?
• TTL interno: por quanto tempo o broker pode mantê-la disponível para processamento?
• Validade do provedor: qual etapa é abrangida pelo parâmetro documentado para essa conexão?
• Confirme por escrito o significado, os limites e o comportamento de cada parâmetro na documentação técnica aplicável.

Por que uma rota recuperada pode liberar mensagens obsoletas

Quando uma conexão tem capacidade limitada, algumas plataformas enfileiram solicitações para enviá-las mais tarde. Se a rota voltar a ficar disponível, essas mensagens poderão retomar o percurso. O congestionamento, por si só, não invalida o conteúdo nem garante que o provedor o descarte.

Antes de despachar um item retido, verifique seu prazo funcional. Se ele já tiver vencido, não o reenvie apenas porque a conexão recuperou a capacidade. A expiração do broker pode ajudar, mas sua aplicação depende do produto e do estado da mensagem. Por exemplo, o Azure Service Bus documenta particularidades para mensagens expiradas e mensagens que já estão bloqueadas; essas informações não devem ser extrapoladas para outros brokers.

• Verifique a validade funcional imediatamente antes do envio, não apenas no momento de enfileirar.
• Quando uma rota for recuperada, processe primeiro a verificação de expiração e, em seguida, selecione as mensagens elegíveis.
• Monitore e alerte sobre a idade da fila; a latência observada não substitui uma regra de expiração.
• Verifique como o broker trata mensagens expiradas, bloqueadas e encaminhadas para dead-letter.

Defina políticas por classe de tráfego

Um único período não serve para todos os casos. A regra deve derivar da utilidade temporal da mensagem e dos requisitos aplicáveis, e ser traduzida em um prazo verificável. A expiração do provedor e a validade interna devem ser configuradas separadamente quando a arquitetura permitir.

Para OTP, o NIST SP 800-63B-4 estabelece que uma autenticação fora de banda deve ser considerada inválida se não for concluída em até 10 minutos e que o segredo deve ser aceito uma única vez. A OWASP também recomenda TTL curto, uso único, limites de tentativas e invalidação após uma verificação bem-sucedida. Esse limite de autenticação não é um período universal para a fila nem uma recomendação para outras classes de mensagens.

Alertas transacionais e mensagens não urgentes exigem regras próprias. Defina a expiração de acordo com a operação notificada, as expectativas do usuário e as obrigações aplicáveis. Se não for possível justificar um período específico, não o apresente como padrão: documente o critério e valide o comportamento.

• OTP: o sistema de autenticação deve rejeitar o código vencido e impedir sua reutilização, mesmo que o SMS chegue depois.
• Alertas transacionais: defina qual evento os torna irrelevantes e como evitar uma notificação atrasada que contradiga o estado atual.
• Mensagens não urgentes: estabeleça uma janela funcional de acordo com a finalidade; não herde automaticamente a configuração de OTP.
• Em todas as categorias: mantenha o consentimento e a conformidade aplicáveis e não reenvie mensagens promocionais fora da autorização correspondente.

Projete o ciclo de vida e trate estados incertos com cuidado

Modele o percurso com estados explícitos: enfileirado, elegível, enviado ao provedor, aceito pela operadora, expirado, cancelado e encerrado com resultado incerto. Os nomes específicos variam; use o contrato da sua plataforma e mantenha a correspondência com os estados dela.

A aceitação de uma solicitação não significa que o SMS já foi entregue. Na documentação da Twilio, por exemplo, «sent» indica aceitação pela operadora upstream, enquanto «delivered» depende de uma confirmação posterior. Um DLR ou callback é um sinal do sistema correspondente, não uma prova independente de recebimento por uma pessoa nem uma garantia universal de confirmação no dispositivo.

Se não houver um resultado conclusivo, mantenha o estado como incerto até a chegada de um evento posterior ou até o encerramento da conciliação, conforme uma política documentada. Evite tentativas automáticas que possam duplicar a mensagem sem avaliar o risco.

• Armazene o prazo funcional junto ao identificador da mensagem e verifique-o em cada transição de processamento.
• Diferencie solicitação aceita, envio à operadora upstream e entrega informada; não agrupe tudo em um único estado de «sucesso».
• Defina qual evento encerra uma operação e como conciliar casos sem DLR ou com estados contraditórios.
• Proteja os OTP: não registre seus valores em texto simples como parte da auditoria habitual.

Mudar de rota ou limpar a fila: o que fazer com mensagens em trânsito

Uma limpeza interna pode impedir o processamento de mensagens que ainda estão sob controle do seu sistema, mas não se deve presumir que ela possa retirar um SMS que já chegou à rede. As possibilidades de cancelamento dependem do provedor e do estado: a documentação da Twilio, por exemplo, descreve o cancelamento de determinadas mensagens programadas antes do horário de envio; isso não estabelece um cancelamento geral após o despacho à operadora.

Ao mudar de rota, separe os itens que ainda estão na sua fila daqueles que o provedor já aceitou. Para os primeiros, verifique o prazo e decida se serão retidos, descartados ou redirecionados, conforme as regras documentadas. Para os segundos, consulte os estados e comprovantes, mas deixe claro o limite de controle: a mensagem pode continuar avançando mesmo depois que a fila local for limpa.

Em uma limpeza ampla, delimite o escopo por identificador, classe de tráfego, rota, intervalo de tempo ou outro critério operacional verificável. Use um modo de revisão prévia, se disponível, e evite excluir indiscriminadamente itens cujo estado seja incerto.

• Interrompa ou limite o despacho antes de mudar as regras, se o desenho operacional permitir.
• Classifique as mensagens como ainda internas, entregues ao provedor ou com resultado incerto.
• Cancele remotamente somente quando o provedor documentar essa ação para o estado específico.
• Não afirme que a limpeza impedirá a entrega de mensagens que já foram aceitas pela rede.

Torne a limpeza auditável e conciliável

Uma limpeza operacional deve poder ser reconstruída: o que foi removido, por quê, dentro de qual escopo e quem autorizou a ação. Armazene registros de data e hora e os identificadores necessários para relacionar a decisão local aos estados do provedor e aos comprovantes posteriores.

A auditoria não precisa armazenar o corpo do SMS para ser útil. Em especial, evite registrar OTP em texto simples. Se o broker oferecer dead-lettering para mensagens expiradas, isso poderá ajudar na revisão e conciliação, mas é um recurso que precisa ser habilitado e configurado explicitamente; o comportamento depende do broker.

• Registre o motivo, o escopo da limpeza, o ator ou processo autorizado e os registros de data e hora.
• Mantenha identificadores de correlação e os estados anterior e posterior, com acesso restrito.
• Não inclua rotineiramente conteúdo sensível nem segredos de autenticação nos registros.
• Documente a retenção, as permissões de limpeza e o procedimento de conciliação de mensagens expiradas ou incertas.

Teste cada conexão e etapa antes de depender da expiração

Um parâmetro com o mesmo nome pode ter escopos diferentes entre provedores. Valide a documentação da conexão específica e faça testes controlados em um ambiente e com destinatários autorizados. Não transforme um resultado pontual em garantia para outras operadoras, rotas ou estados da rede.

Observe separadamente a expiração da fila interna, a solicitação de expiração ao provedor, os estados de aceitação e os comprovantes de entrega. Registre o que ocorreu com mensagens enfileiradas, enviadas e com resultado incerto. Repita os testes diante de alterações relevantes de configuração ou conexão, respeitando os limites e as condições do provedor.

• Confirme as unidades, a faixa permitida, o valor padrão e a etapa abrangida por cada parâmetro.
• Teste mensagens que expiram antes do despacho e mensagens cujo estado muda durante o teste.
• Compare o estado local com callbacks ou comprovantes e documente os casos sem confirmação conclusiva.
• Revise as ressalvas do broker e do provedor; não generalize resultados de uma plataforma.

Lista de verificação operacional

Antes de ativar ou alterar uma política, confirme que a equipe consegue identificar mensagens expiradas, distingui-las das que já estão em trânsito e explicar quais evidências recebe em cada etapa. A revisão também deve abranger permissões, alertas e comunicação entre as equipes de operações, engenharia e produto.

Cada classe de tráfego tem um critério funcional de expiração documentado.

O consumidor verifica o prazo antes do despacho, inclusive após a recuperação de uma rota.

O TTL do broker e a expiração do provedor estão documentados como controles separados.

Os estados de aceitação, envio, entrega informada e incerteza não são confundidos.

• A limpeza tem escopo, motivo, autorização, registros de data e hora e identificadores para conciliação.
• Há alertas de idade da fila, acúmulo, expirações e falta de confirmação, com limites definidos pela equipe.
• As alterações operacionais são comunicadas às equipes afetadas e contam com um procedimento de reversão.