Tema: email
-
Após quantos soft bounces, em que período, um remetente deve parar de enviar e-mails para um endereço?
Pergunta em aberto: os códigos de status avançados separam falhas permanentes (5.X.X) de falhas transitórias persistentes (4.X.X), mas o padrão deixa o caso transitório a cargo da política do remetente; que limites os remetentes já usaram e o que aconteceu com as taxas de recuperação e com a reputação?
-
Cabeçalhos List-Unsubscribe e cancelamento de inscrição com um clique (RFC 2369 e RFC 8058)
Os cabeçalhos da RFC 2369 permitem que clientes de e-mail ofereçam ações de lista; o modo de um clique da RFC 8058 acrescenta um URI HTTPS em List-Unsubscribe e List-Unsubscribe-Post: List-Unsubscribe=One-Click, processado por um HTTPS POST sem redirecionamento nem etapas adicionais, com ambos os cabeçalhos cobertos por DKIM. As diretrizes do Google exigem esse suporte de quem envia e-mail em massa.
-
Convites iCalendar: UID, SEQUENCE e como acertar nos fusos horários
Um evento iCalendar é identificado pelo UID e revisado pelo SEQUENCE; seus horários são UTC, hora local com um TZID que aponta para um VTIMEZONE incorporado, ou flutuantes. Use hora local ancorada ao fuso para reuniões recorrentes, UTC para eventos únicos entre fusos e envie atualizações e cancelamentos com o METHOD do iTIP que o cliente receptor espera.
-
Autenticação de e-mail: SPF, DKIM e DMARC
O SPF lista os servidores autorizados a enviar e-mail em nome de um domínio, o DKIM assina as mensagens com uma chave do domínio e o DMARC define o que os receptores devem fazer quando ambos falham e para onde enviar relatórios; os três são registros TXT no DNS que precisam ser preservados quando outros registros mudam.
-
Autenticação de e-mail com SPF, DKIM e DMARC
O SPF (RFC 7208) define quais servidores podem enviar e-mails por um domínio, o DKIM (RFC 6376) assina as mensagens com uma chave publicada no DNS, e o DMARC (RFC 7489) determina o que os destinatários fazem em caso de falha e para onde enviam relatórios. Os três são registros TXT no DNS e precisam sobreviver a qualquer alteração de DNS.
-
Envio confiável de e-mail transacional: linha de outbox, worker, novas tentativas e chaves de idempotência
Não envie e-mail dentro do handler da requisição: registre a mensagem na mesma transação do evento de negócio, deixe um worker entregá-la, faça novas tentativas com backoff diante de respostas transitórias (4yz) e falhas de conexão, pare nas respostas permanentes (5yz) e evite duplicatas após uma falha com uma chave de idempotência por evento e um Message-ID estável.
-
Cabeçalhos de cancelamento de inscrição com um clique reduzem a taxa de reclamações de spam em comparação com apenas um link no rodapé
Hipótese: para a mesma lista e o mesmo conteúdo, mensagens com os cabeçalhos List-Unsubscribe e List-Unsubscribe-Post (RFC 8058) recebem menos ações de «denunciar spam» por mensagem entregue do que mensagens com apenas um link no rodapé, porque o cliente de e-mail oferece o cancelamento da inscrição ao lado do botão de spam; propõe-se um teste A/B com distribuição aleatória.
-
Validação de endereços de e-mail: o que uma verificação de sintaxe pode e não pode revelar
A RFC 5321 limita a local-part a 64 octetos e um caminho a 256; o padrão HTML usa de propósito uma gramática mais simples que a da RFC 5322 em input type=email; endereços internacionalizados exigem SMTPUTF8 de ponta a ponta. Verifique sintaxe e tamanhos, consulte o MX no cadastro, confirme a posse com uma mensagem e nunca "corrija" um endereço automaticamente.
-
Estrutura MIME de um e-mail: multipart/alternative, a parte em texto simples e as codificações
Uma mensagem com texto e HTML é um multipart/alternative cujas partes seguem da mais simples à mais rica (text/plain primeiro, text/html por último); corpos com bytes não ASCII usam quoted-printable ou base64, e os cabeçalhos usam encoded-words da RFC 2047. Gere a parte em texto a partir dos mesmos dados do HTML, escape as variáveis e respeite os limites de tamanho de linha.
-
Tratamento de bounces e reclamações: DSNs, códigos de status aprimorados e feedback loops
Os bounces chegam como notificações de status de entrega (DSN) cujo campo Status é um código aprimorado no formato classe.assunto.detalhe: 5.X.X é falha permanente e 4.X.X, falha transitória persistente. As reclamações chegam como relatórios ARF. Analise ambos, suprima endereços com base em evidências e guarde os diagnósticos brutos.
Legível por máquina: JSON