E-mail

O Chinaski envia e-mails às pessoas quando algo acontece: redefinições de senha, decisões de revisão, novas submissões de formulários, publicação agendada, alertas de segurança e resultados de build. Toda mensagem sai por um relay SMTP único que você configura em Settings → Email. Esta página explica a configuração, as regras de segurança do transporte e tudo o que envia e-mail.

Configurando o relay

Na aba Email:

Campo	Padrão	O que saber
SMTP host	nenhum	O hostname do seu relay de e-mail (ex.: smtp.example.com)
SMTP port	587	Portas comuns: 587, 465, 25, 2525
Encryption	STARTTLS	Ou SSL/TLS, ou None (texto puro); prefira STARTTLS ou SSL
From address	nenhum	O endereço de origem das suas mensagens (ex.: noreply@example.com)
SMTP username	em branco	Em branco se o relay não exige autenticação
SMTP password	em branco	Armazenado criptografado; os formulários mostram “leave blank to keep current.” A dica sugere uma app password
Build notification email	em branco	Notas de sucesso/falha de build vão aqui; em branco desativa essas notas

Dois botões de teste vivem na própria aba:

• Send test email: digite qualquer endereço e o CMS envia uma mensagem pelo relay exatamente como configurado. Em caso de falha, a resposta diz qual estágio falhou (connect, TLS, autenticação, aceitação do remetente, validação do destinatário ou envio), além de “check host, port, and credentials.”
• Send test build notification: exercita especificamente o endereço de notificação de build, para que as duas metades possam ser verificadas de forma independente.

Segurança do transporte (embutida)

• STARTTLS atualiza a conexão após conectá-la; SSL/TLS conecta já criptografado desde o início. Ambos verificam certificados (contra o hostname do relay) por padrão, então as credenciais não podem ser capturadas por um certificado forjado. None conecta em texto puro; útil apenas para relays em rede privada.
• Se seu relay usa um certificado autoassinado, CHINASKI_SMTP_INSECURE_NOVERIFY=1 no env da instância é a única exclusão documentada da verificação de certificado.
• A autenticação é tentada apenas quando username e password estão definidos; relays sem autenticação funcionam bem com os campos em branco.
• Toda notificação é texto puro UTF-8; os valores de cabeçalho são sanitizados contra injeção.

Modo air-gap

No modo air-gap nenhum e-mail é enviado, nunca: o transporte retorna imediatamente, sem tentativa de rede. E-mails de formulários, notificações e resumos agendados são todos pulados, e a aba Integrations diz isso. Nada precisa ser configurado para isso acontecer; é global.

Quem recebe e-mail, e quando

• Você (admin do site), tipicamente pelo endereço de notificação de build ou pelo de notificação de revisão:
  • Um build teve sucesso ou falhou (se Build notification email está definido; enviado pelo builder após cada build, e falhas de entrega nunca perturbam o resultado do build).
  • Falhas de login repetidas e sustentadas (o primeiro alerta por hora, para o mesmo endereço de notificação de build).
  • Conteúdo foi autopublicado pelo scheduler (resumo com títulos e idiomas por item; endereço definido na aba Integrations).
  • Submissões de revisão: “A page has been submitted for review by …” com um link direto de edição (endereço definido em Settings → Workflow).
• Criadores de conteúdo, quando têm um e-mail cadastrado:
  • Aprovação de página (ou rejeição com um motivo): as notificações do Approval Workflow.
• Quem submete e destinatários (Forms):
  • Um e-mail de confirmação ao visitante quando o formulário tem um campo reply-to configurado (assunto/nome no From são configurações por formulário; o corpo é um agradecimento mais uma cópia das respostas), enviado de forma assíncrona.
  • O e-mail de notificação aos seus destinatários: um por submissão, listando o valor de cada campo, o IP de origem (a menos que desativado ou por solicitação de privacidade) e o timestamp.
• Usuários: links de redefinição de senha, e convites/redefinições enviados pelo admin, com seus limites de tempo documentados.

Os dois tipos de falha

• Falhas do lado do relay: o envio retorna um flash ou entrada de log nomeando o estágio que falhou (connect, STARTTLS, AUTH, MAIL FROM, RCPT TO ou DATA), mais o código do servidor. O botão de teste SMTP é o diagnóstico mais rápido.
• Não-configurações silenciosas: mais comumente “a configuração existe, mas o envio foi pulado”: modo air-gap ativo, nenhum endereço de From, os campos de notify/confirmação do formulário em branco, ou uma ação de reset/outra cujo destinatário não tinha e-mail válido. Cada caminho trata deliberadamente uma configuração ausente como “não enviar” em vez de um erro.
• As falhas de notificação de build são especiais: são registradas (um evento build_notify_email_failed), mas nunca transformam um build bom em uma falha, nem o contrário.

Orientação prática

• Use uma app password em vez da senha da sua conta pessoal (a dica do campo diz isso): credenciais de relay são sensíveis, mesmo criptografadas.
• Defina o From address antes de qualquer fluxo de envio: vários caminhos o exigem mesmo com um relay funcionando.
• Depois de mudar qualquer campo, use o botão de teste que corresponde ao que você mudou; o flash dá uma razão precisa em vez de “o e-mail não chegou”.
• As notificações específicas de formulário são configuradas por formulário (Forms → edit): campo reply-to, linha de assunto, endereços de notificação, inclusão de IP e a URL de agradecimento; a aba Email é o relay, não o comportamento.
• Se uma mensagem importante nunca chegou, as entradas do audit log (aprovações) e os resultados de flash da ação disparadora dizem se o envio foi tentado e o que o relay respondeu.