Envio transacional de saída e em massa através de instâncias separadas Postfix, recebimento através de sua própria, caixas de correio em Dovecot, filtragem e pontuação através do Rspamd. A identidade do remetente é verificada em relação ao DNS ativo antes que uma mensagem possa reivindicar o domínio de um cliente.
| Medida | Valor | Fonte | Medido |
|---|---|---|---|
| Componentes de correio em produção | 5 (Postfix outbound, Postfix bulk, Postfix inbound, Dovecot, Rspamd) | kubectl get deployments -n mail | |
| Envio de caminhos separados por classe de reputação | 2 (transactional and bulk, on distinct instances) | kubectl get deployments -n mail | |
| Verificações de domínio do remetente realizadas antes de um envio ser autorizado | 2 (domain ownership proven by DNS record, and SPF authorisation verified live) | transactional sender-identity resolution in the email service |
Que edifício nos ensinou
Quando um e-mail de marketing não chega, a ferramenta de campanha o relata como enviado. Isso é tecnicamente verdade e completamente inútil. A mensagem foi aceita para entrega e, em seguida, descartada, adiada ou arquivada como spam por um sistema de recepção de acordo com regras que a ferramenta de campanha não pode ver e seu fornecedor não explica.
Nós separamos o envio em massa do envio transacional para que um boletim informativo não possa danificar a reputação da qual as redefinições de senha dependem. Nós verificamos, em relação ao DNS ao vivo no momento do envio, se um domínio realmente foi provado pertencer ao inquilino que o reivindica e se seu registro SPF realmente nos autoriza — e se essa pesquisa falhar, não registramos nenhum veredicto em vez de adivinhar, porque uma suposição aqui envia e-mails que falham na autenticação e ensina os sistemas de recebimento a não confiar no domínio.
Uma vez perdemos uma classe de mensagem de entrada porque um webhook postou dados codificados em formulário e o manipulador tentou analisá-lo como JSON, retornando um feliz 200 enquanto descartava o conteúdo. Três drop-s silenciosos separados existiam nesse caminho. Nada alertou, porque tudo relatou sucesso. Sistemas que falham por ter sucesso são os mais difíceis de encontrar e a razão pela qual instrumentamos caminhos de ingestão obsessivamente no trabalho do cliente.
Há um limite de conexão que vale a pena mencionar também, porque é o tipo de detalhe que só aparece sob carga real: um servidor de e-mail permite um número limitado de conexões simultâneas por usuário e endereço, por processo, exceder isso e as coisas param de funcionar de maneiras que parecem falhas de autenticação. O planejamento de capacidade para e-mail é uma engenharia real, e quase ninguém orçamenta para isso.
Construído com
- Postfix
- Dovecot
- Rspamd
- SPF
- DKIM
- DMARC
- IMAP
- Java
- Spring Boot
Diga-nos o que você está tentando fazer
Uma breve conversa geralmente é suficiente para dizer se somos as pessoas certas, se não formos, diremos isso e indicaremos um lugar melhor.