CL-2026-09-10 — BK-210: e-mail da lista diaria reativado, com a causa raiz do incidente corrigida

Pedido

O dono queria que o Termo de Parceria dissesse a verdade sobre a lista diaria de compradores.

Ao conferir, o item 1.1 falava so em e-mail — e o e-mail estava desligado desde 11/04/2026,

como contencao do incidente do BK-210. Decisao dele: *"pode tratar o problema agora e ja

fazemos em php atual com as correcoes de seguranca"*.

Causa raiz do incidente (achada agora, 5 meses depois)

O certificado TLS do servidor de e-mail cobre rionoteatro.com.br e www.rionoteatro.com.br,

mas nao mail.rionoteatro.com.br — que era o host configurado em todo o codigo:

```

Verify return code: 62 (hostname mismatch)

```

O PHPMailer valida o nome do host e recusava a conexao. Resultado: **todo envio por SMTP

autenticado falhava** e caia no fallback mail() local (z_dispara_diario.php:125), que

despeja no MTA da propria maquina. Foi assim que a fila acumulou as 426 mensagens que

levaram a purga emergencial de 11/04. O diagnostico da epoca tratou o sintoma (desligar o

canal) sem achar isso.

Provado nos dois sentidos: com mail.rionoteatro.com.br o envio falha igual em 5.6 e 8.3

(logo, nao era regressao da virada do BK-348); com rionoteatro.com.br o SMTP responde

235 Authentication successful e a mensagem chega.

Correcoes de seguranca

Credenciais — o "risco residual" que o proprio BK-210 deixou anotado:

• novo config/mail_credentials.php: le usuario/senha do .env e pode ser incluido antes do

connect.php, no lugar exato onde ficavam os define(). Sem credencial aborta o envio,

em vez de tentar autenticar vazio.

• 16 arquivos vivos deixaram de trazer senha em texto claro, incluindo action.php,

config/functions.php, apps/Helpers/GetMailer.class.php e os tres data/functions.php.

• Divergencia encontrada: o sac@ aparecia com duas senhas diferentes. A que estava em

z_dispara_pagamento.php nao autentica mais (SMTP 535) — ou seja, aquele canal estava

quebrado em silencio. A valida vivia em painel/data/functions.php e foi para o .env.

• disparaemail.php ainda trazia a senha do conteudo@, e o SMTP secundario a sua propria.

Exposicao

• disparaemail.php respondia 500 por HTTP (fatal em $send_list->isMail(), metodo que

nao existe na classe). Ganhou guard de CLI: agora 403. A chamada virou setSMTP().

PHP 8.3 — o que de fato impedia migrar os crons (o lint passava, o runtime nao):

• apps/phpmailer/class.smtp.php: each() em 3 pontos, removido no PHP 8 → foreach.
• apps/Helpers/PHPMailer/src/PHPMailer.php:3631: FILTER_FLAG_HOST_REQUIRED, removida no

PHP 8.0 → fatal em todo envio pelo GetMailer. Removida a flag, como o upstream ja fez.

Reativacao

• Os dois wrappers do painel bt que rodam z_dispara_diario.php (08:01 e 09:00) passaram de

/usr/bin/php (5.6.40) para php83 e ganharam RNT_LISTA_DIARIA_EMAIL_ENABLED=1.

Para voltar ao modo WhatsApp-only, basta apagar essa linha do wrapper.

• Volume conferido antes de ligar: as duas sessoes de 11/09 com sec_enviolista=1 estao com

email_lista vazio, entao so o destinatario interno recebe. Nao ha rajada retroativa:

a consulta e DATE(sec_data)=CURDATE().

Achado que ninguem tinha notado

O bloco de "pecas que terminaram ontem" (z_dispara_diario.php:303) **envia e-mail sem checar

a flag**. Ou seja, o modo "WhatsApp-only" nunca foi completo: esse aviso de prorrogacao seguiu

saindo desde abril — e, com o SMTP quebrado, indo para a fila local. Agora que o SMTP funciona,

esses e-mails passam a ser entregues de verdade.

Validacao

• php83 -l em todos os arquivos tocados.
• Envio real por SMTP autenticado para a conta de teste, recebido: OK em 8.3 e em 5.6.
• curl em disparaemail.php: 500 → 403.
• Site no ar depois de tudo: / 200, /peca.php 200, /checkout.php 302, /admin/ 302.
• Varredura final: zero senha em arquivo vivo.

Pontas abertas

• Rotacionar as senhas (lista@, sac@, conteudo@, secundario). Elas ficaram anos no

codigo e no historico do Git; tirar do codigo nao desfaz isso. O repositorio e privado

(a API do GitHub responde 404 anonima), o que reduz, mas nao elimina, o risco.

• Os outros 10 crons do painel bt seguem em 5.6 (BK-411). Passam no lint 8.3, mas nao

pude executa-los: disparam e-mail, Facebook e relatorios reais.

• Dois crons rodam o mesmo z_dispara_diario.php (08:01 e 09:00). Pode ser intencional

(o termo fala em segundo envio), mas vale o dono confirmar.

• Primeiro ciclo real com e-mail ligado: amanha, 08:01. Conferir o log do wrapper.