 |
| Bellacosa Mainframe e como funciona um email |
☕ Um Café no Bellacosa Mainframe
📧 A Autópsia de um E-mail — Ninguém Esperava a Spanish Inquisition!
SMTP → DNS → MX → SPF → DKIM → DMARC → antispam → mailbox, sob o olhar desconfiado dos inquisidores da Internet
Imagine a cena.
São 03:17 da madrugada.
Naturalmente.
Porque sistemas de produção raramente escolhem um horário civilizado para revelar seus segredos.
Em algum lugar do mundo, um usuário termina uma mensagem absolutamente inocente:
Para: joao@empresa.com
Assunto: Relatório de Produção
Ele escreve:
“Olá João, segue o relatório solicitado.”
Anexa um PDF.
Olha rapidamente para a mensagem.
E aperta:
SEND.
Pronto.
Na cabeça do usuário, aconteceu isto:
EU
│
│ SEND
▼
JOÃO
Que adorável.
Que inocente.
Que absolutamente errado.
Porque naquele exato instante o pequeno e-mail é arrancado do conforto do cliente de correio eletrônico e lançado em uma das maiores burocracias automatizadas criadas pela humanidade.
Ele encontrará servidores SMTP, consultará DNS, procurará registros MX, atravessará conexões de rede e será interrogado por SPF, DKIM, DMARC, mecanismos de reputação, antispam, antivírus e políticas corporativas.
Tudo isso antes de conseguir tocar na sagrada pasta:
INBOX.
Nosso pequeno e-mail ainda não sabe.
Mas alguém bate à porta.
— Toc, toc.
— Quem está aí?
Três homens aparecem.
Vestidos de vermelho.
O primeiro carrega uma enorme documentação de DNS.
O segundo segura uma chave criptográfica.
O terceiro traz uma política DMARC impressa em pergaminho.
E gritam:
NOBODY EXPECTS THE SPANISH INQUISITION!
Bem-vindo à autópsia de um e-mail.
🎬 Ato I — O botão SEND é apenas o começo
Uma das primeiras coisas que precisamos destruir é a ideia de que apertar SEND significa que o destinatário recebeu alguma coisa.
Não significa.
Significa apenas que você entregou a mensagem para a próxima etapa de uma cadeia.
Dependendo da arquitetura utilizada, existem diferentes componentes envolvidos, mas podemos imaginar inicialmente:
Usuário
│
▼
Cliente de e-mail
│
▼
Servidor de envio
│
▼
Internet
│
▼
Servidor destinatário
│
▼
Mailbox
Essa representação já é melhor.
Mas ainda é simples demais.
Quando abrimos a máquina:
MESSAGE
│
▼
SMTP
│
▼
DNS
│
▼
MX
│
▼
SMTP DESTINO
│
├── SPF
├── DKIM
├── DMARC
├── reputação
├── antispam
├── antimalware
└── políticas
│
▼
MAILBOX
Agora começamos a enxergar o problema.
Enviar e-mail é fácil.
Convencer o outro servidor a aceitar o e-mail é outra história.
📮 Ato II — SMTP, apresente-se!
O primeiro grande personagem dessa história é o SMTP — Simple Mail Transfer Protocol.
A palavra Simple merece carinho.
Ela pertence àquela época maravilhosa da computação em que alguém ainda acreditava que alguma coisa conectada à Internet permaneceria simples.
SMTP nasceu para transportar mensagens.
Podemos imaginar uma conversa bastante simplificada:
SERVIDOR: 220 mail.empresa.com ESMTP
CLIENTE: EHLO mail.remetente.com
SERVIDOR: 250 Hello
CLIENTE: MAIL FROM:<vagner@example.com>
SERVIDOR: 250 OK
CLIENTE: RCPT TO:<joao@empresa.com>
SERVIDOR: 250 OK
CLIENTE: DATA
SERVIDOR: 354 Start mail input
Então chegam cabeçalhos, corpo da mensagem, anexos codificados e demais informações necessárias.
O protocolo possui uma característica maravilhosa para quem gosta de entender computadores:
é uma conversa.
Um lado fala.
O outro responde.
Existem códigos.
Existem estados.
Existem erros.
Para quem trabalha com mainframe, isso deveria soar familiar.
É praticamente um diálogo transacional.
Você pede alguma coisa.
O outro lado responde se aceitou ou não.
Mas antes de nosso SMTP conseguir entregar a mensagem existe uma pergunta bastante importante:
Onde está o servidor responsável por
empresa.com?
🌎 Ato III — DNS, encontre o castelo!
Nosso destinatário é:
joao@empresa.com
Temos duas partes importantes.
joao
é a caixa ou identidade local.
E:
empresa.com
é o domínio.
Mas empresa.com pode possuir site, APIs, servidores, aplicações e dezenas de outros serviços.
Qual máquina recebe e-mail?
Precisamos perguntar ao DNS — Domain Name System.
E não estamos simplesmente perguntando:
“Qual é o IP de empresa.com?”
Queremos algo mais específico:
“Quem recebe e-mails destinados a empresa.com?”
É aí que aparece nosso próximo personagem.
🏰 Ato IV — MX aponta o portão
O registro MX — Mail Exchange indica servidores responsáveis pelo recebimento de e-mail de determinado domínio.
Poderíamos encontrar algo conceitualmente parecido com:
empresa.com. MX 10 mail1.empresa.com.
empresa.com. MX 20 mail2.empresa.com.
Temos dois servidores.
E temos prioridades.
Normalmente, valores menores possuem maior preferência.
Assim:
empresa.com
│
▼
DNS
│
┌────────┴────────┐
▼ ▼
MX 10 MX 20
│ │
▼ ▼
mail1.empresa.com mail2.empresa.com
Nosso servidor finalmente encontrou o castelo.
Aproxima-se.
Bate à porta.
— Bom dia. Tenho uma mensagem para João.
A porta abre lentamente.
Um homem vestido de vermelho pergunta:
— Seu nome?
— SMTP.
— Domínio?
— example.com.
— IP?
— Bem...
NOBODY EXPECTS THE SPANISH INQUISITION!
🔥 Ato V — Cardeal SPF entra na sala
O primeiro inquisidor é o SPF — Sender Policy Framework.
Ele não está particularmente interessado no conteúdo romântico, comercial, financeiro ou absolutamente inútil da mensagem.
Sua pergunta é outra:
Este sistema está autorizado a enviar mensagens em nome da identidade de domínio relevante para SPF?
Aqui encontramos um conceito que confunde muita gente.
Existe aquilo que vemos:
From: vagner@example.com
Mas existe também o chamado envelope SMTP.
Durante a comunicação podemos ter:
MAIL FROM:<bounce@example.com>
RCPT TO:<joao@empresa.com>
O SPF está relacionado à identidade SMTP usada nesse processo, não simplesmente ao From: visual que aparece no cliente do usuário.
O destinatário verifica a política SPF publicada pelo domínio através do DNS.
A pergunta conceitual é:
Este IP está autorizado
a enviar para este domínio?
A resposta poderá resultar em condições como:
PASS
FAIL
SOFTFAIL
NEUTRAL
entre outras possibilidades previstas pelo mecanismo.
Se o resultado for favorável, nosso Cardeal SPF anota:
PASS.
— Muito bem. Próximo!
Nosso e-mail suspira aliviado.
Péssima decisão.
Porque o segundo inquisidor acaba de entrar.
🔏 Ato VI — Cardeal DKIM exige a assinatura
O segundo homem olha para a mensagem.
— Documentos?
— Aqui.
— Identificação?
— Aqui.
— Assinatura?
Silêncio.
O DKIM — DomainKeys Identified Mail introduz assinatura criptográfica ao processo.
A organização remetente possui uma chave privada.
Partes determinadas da mensagem são utilizadas no processo de geração da assinatura.
Um cabeçalho DKIM pode conter informações semelhantes a:
DKIM-Signature:
v=1;
a=rsa-sha256;
d=example.com;
s=selector1;
...
Duas informações são particularmente interessantes para nossa investigação:
d=example.com
e:
s=selector1
O d= informa o domínio relacionado à assinatura.
O s= fornece o selector.
Com essas informações, o destinatário pode consultar o DNS e encontrar a chave pública correspondente.
Algo conceitualmente como:
selector1._domainkey.example.com
Agora podemos visualizar:
REMETENTE
│
▼
mensagem
│
▼
chave privada
│
▼
assinatura DKIM
│
▼
════════ INTERNET ════════
│
▼
DESTINATÁRIO
│
▼
consulta DNS
│
▼
chave pública
│
▼
verificação
│
▼
DKIM PASS / FAIL
O Cardeal DKIM examina cuidadosamente os documentos.
Olha para o e-mail.
Olha novamente para os documentos.
— Assinatura válida.
O e-mail sorri.
— Então posso entrar?
— HAHAHAHAHA!
Não.
🧐 Ato VII — Uma assinatura válida não significa “mensagem verdadeira”
Essa distinção é fundamental.
DKIM não é um selo mágico dizendo:
“Tudo que está escrito nesta mensagem é verdade.”
Ele ajuda a verificar criptograficamente a assinatura associada a determinado domínio e a integridade das partes assinadas segundo o mecanismo.
Isso é diferente de validar o conteúdo humano.
Uma mensagem pode estar perfeitamente assinada e dizer:
“Compre minha coleção de pedras lunares terapêuticas que executam COBOL.”
A criptografia não avalia a qualidade da oferta.
Ela verifica propriedades técnicas da assinatura.
Essa diferença entre:
autenticação
e:
confiança
será importantíssima daqui para frente.
👑 Ato VIII — Entra o Grande Inquisidor DMARC
As portas se abrem.
Todos ficam em silêncio.
Chega o terceiro cardeal.
DMARC — Domain-based Message Authentication, Reporting and Conformance.
O DMARC pergunta algo extremamente interessante:
“Muito bem. SPF falou uma coisa. DKIM falou outra. Mas isso combina com o domínio que o usuário está vendo no
From:?”
A palavra mágica aqui é:
ALIGNMENT
Imagine:
From:
vagner@bellacosa.com
Enquanto determinada autenticação SPF está associada a:
mailer-outraempresa.net
E DKIM possui:
d=servico-terceiro.net
Podemos possuir resultados tecnicamente válidos em determinadas verificações e, ainda assim, precisar responder:
Essas identidades estão alinhadas com
bellacosa.compara fins de DMARC?
Podemos representar a ideia:
HEADER FROM
│
▼
bellacosa.com
/ \
/ \
▼ ▼
SPF DKIM
│ │
alignment alignment
\ /
\ /
DMARC
De maneira simplificada, DMARC pode ser satisfeito quando existe SPF válido e alinhado ou DKIM válido e alinhado conforme suas regras.
O Grande Inquisidor olha para nosso pequeno e-mail.
— SPF?
— PASS!
— DKIM?
— PASS!
— Alignment?
Silêncio dramático.
Uma orquestra imaginária começa a tocar.
— PASS!
Todos comemoram.
O e-mail corre em direção à Inbox.
O Cardeal DMARC segura-o pela gola.
— Onde pensa que vai?
⚖️ Ato IX — none, quarantine ou reject
DMARC também permite que o domínio publique uma política.
Entre as políticas clássicas encontramos:
p=none
p=quarantine
p=reject
p=none permite essencialmente uma postura de monitoramento em relação ao tratamento DMARC.
p=quarantine solicita tratamento mais cauteloso para mensagens que falham à política.
p=reject solicita que mensagens que falhem sejam rejeitadas.
O domínio está dizendo ao mundo algo próximo de:
“Se alguém tentar se passar por mim e não atender às minhas regras de autenticação, eis como desejo que você trate a situação.”
Isso é extremamente importante contra determinadas formas de falsificação de identidade de domínio.
Mas existe uma pegadinha maravilhosa.
Nosso e-mail passou SPF.
Passou DKIM.
Passou DMARC.
Então está garantido na Inbox?
NÃO!
E essa é uma das lições mais importantes desta autópsia.
🕵️ Ato X — “Sabemos quem você é. Agora precisamos decidir se gostamos de você.”
Autenticação não é reputação.
Repita comigo:
autenticação não é reputação.
Um operador de spam pode possuir seu próprio domínio.
Pode configurar SPF corretamente.
Pode implementar DKIM.
Pode publicar DMARC.
E continuar enviando porcaria industrial em escala planetária.
Portanto, depois da Spanish Inquisition da autenticação, aparece outro departamento.
ANTISPAM.
Esse pessoal não usa roupas vermelhas.
Usa dashboards.
O que é muito mais assustador.
🔬 Ato XI — A máquina de suspeitar
Sistemas modernos de proteção de e-mail podem considerar uma quantidade enorme de sinais.
Por exemplo:
IP remetente
domínio
reputação
volume de mensagens
velocidade de envio
histórico
SPF
DKIM
DMARC
URLs
anexos
conteúdo
headers
padrões de phishing
malware
feedback de usuários
Não devemos imaginar necessariamente uma fórmula universal:
spam_score = 73
válida para todos os provedores.
Cada plataforma possui seus próprios mecanismos.
Mas como modelo mental podemos visualizar:
EMAIL
│
┌─────────────┼─────────────┐
▼ ▼ ▼
AUTENTICAÇÃO REPUTAÇÃO CONTEÚDO
│ │ │
└─────────────┼─────────────┘
▼
ANÁLISE
│
┌──────────┼──────────┐
▼ ▼ ▼
ACCEPT SPAM REJECT
E aqui nosso pobre e-mail começa novamente a suar.
🧨 Ato XII — “Você está carregando alguma coisa?”
O inquisidor olha para a mensagem.
— Bagagem?
— Uma.
— Abra.
Dentro:
relatorio.pdf
— O que é isso?
— Um PDF.
— Isso é exatamente o que alguém carregando um PDF malicioso diria!
O nome do arquivo não encerra a investigação.
Soluções de segurança podem analisar anexos procurando malware, formatos suspeitos, conteúdo ativo ou outros comportamentos considerados perigosos.
URLs também merecem atenção.
Imagine uma mensagem:
URGENTE!!!
SUA CONTA SERÁ CANCELADA!!!
CLIQUE AGORA:
https://dominio-estranhissimo.example
Mesmo que algum componente isolado não seja suficiente para condenar a mensagem, a combinação de diversos sinais pode torná-la altamente suspeita.
É investigação por contexto.
Algo como:
domínio recente
+
IP problemático
+
volume anormal
+
linguagem urgente
+
URL suspeita
+
comportamento semelhante a phishing
=
SPANISH INQUISITION TURBO MODE
🦠 Ato XIII — O inquisidor leva o anexo para a masmorra
Dependendo da solução utilizada, arquivos suspeitos podem receber análises adicionais.
Aqui entra um conceito fascinante:
sandboxing.
Em vez de simplesmente perguntar:
“Conhecemos a assinatura desse malware?”
podemos tentar observar:
“O que esse arquivo faz?”
É uma mudança extraordinária de perspectiva.
Uma abordagem procura reconhecer o criminoso pela fotografia.
A outra coloca o suspeito numa sala e observa se ele tenta desmontar a janela.
No mundo da segurança, comportamento conta muito.
📬 Ato XIV — Finalmente, a mailbox
Depois de uma jornada digna de uma campanha de RPG:
SEND
│
▼
SMTP
│
▼
DNS
│
▼
MX
│
▼
SMTP DESTINO
│
▼
SPF
│
▼
DKIM
│
▼
DMARC
│
▼
REPUTAÇÃO
│
▼
ANTISPAM
│
▼
ANTIMALWARE
│
▼
POLÍTICAS
│
▼
MAILBOX
Nosso e-mail vê finalmente uma placa:
INBOX
Corre em sua direção.
Mas aparecem três portas:
┌────────────┐
│ INBOX │
└────────────┘
┌────────────┐
│ SPAM │
└────────────┘
┌────────────┐
│ QUARANTINE │
└────────────┘
Existe ainda uma quarta possibilidade particularmente desagradável:
REJECT
O fato de uma mensagem ter chegado à infraestrutura destinatária não significa automaticamente que aparecerá gloriosamente diante do usuário.
Essa diferença é importantíssima durante troubleshooting.
🧾 Ato XV — A caixa-preta chamada header
Agora chegamos à parte deliciosa para quem gosta de investigação técnica.
O usuário vê:
De: Vagner
Para: João
Assunto: Relatório
O investigador pergunta:
“Mostre os headers completos.”
Porque ali encontramos a arqueologia da mensagem.
Entre informações úteis podemos encontrar:
Received:
Return-Path:
Message-ID:
Date:
From:
To:
Content-Type:
DKIM-Signature:
Authentication-Results:
Os campos Received: são particularmente interessantes.
À medida que sistemas SMTP manipulam uma mensagem, registros podem ser acrescentados.
Podemos encontrar algo conceitualmente semelhante a:
Received: from mail-a
by mail-b;
Received: from mail-b
by mail-c;
Essas informações ajudam a reconstruir partes do caminho percorrido pela mensagem.
É quase uma investigação forense.
A mensagem diz:
“Eu fui diretamente daqui até lá.”
O header responde:
“Curioso. Tenho testemunhas.”
🖥️ Ato XVI — O programador COBOL entra na investigação
Agora chegamos à parte Bellacosa Mainframe.
Alguém abre um incidente:
E-MAIL NÃO ESTÁ FUNCIONANDO.
Isso é quase tão útil quanto abrir um chamado dizendo:
COBOL DEU PROBLEMA.
Nossa primeira missão não é resolver.
É reduzir o universo do problema.
Pergunte:
Todos os usuários?
Um usuário?
Um domínio?
Um destinatário?
Mensagens externas?
Mensagens internas?
Somente mensagens com anexo?
Somente um tipo de anexo?
Começou quando?
Existe mensagem de erro?
Existe bounce?
Qual o timestamp?
Qual o Message-ID?
Veja como o incidente muda.
Antes:
EMAIL NÃO FUNCIONA
Depois:
Mensagens enviadas por determinado
domínio externo começaram a ser
rejeitadas às 03:17.
Agora temos alguma coisa investigável.
🥚 Easter egg — O incidente das 03:17
São 03:17.
Telefone toca.
— Bellacosa?
— Sim.
— O e-mail caiu.
Primeira pergunta:
— Todo o e-mail?
Silêncio.
— Não sei.
— Então ainda não sabemos se o e-mail caiu.
Essa frase deveria estar pregada na parede de toda War Room.
Porque existe uma tendência humana terrível de transformar:
“Eu tenho um problema.”
em:
“O sistema inteiro tem um problema.”
Nosso trabalho como investigadores é decompor.
TODOS?
│
├── SIM
│ │
│ ├── infraestrutura?
│ ├── rede?
│ ├── DNS?
│ └── serviço?
│
└── NÃO
│
├── remetente?
├── domínio?
├── destinatário?
├── política?
├── autenticação?
└── conteúdo?
Isso vale para e-mail.
Vale para MQ.
Vale para CICS.
Vale para Db2.
Vale para APIs.
Vale para batch.
Vale para praticamente qualquer sistema complexo.
🔍 Ato XVII — Procure o último GOOD
Aqui existe uma técnica extremamente poderosa.
Não comece perguntando:
“Onde está o erro?”
Pergunte:
“Qual foi o último ponto que sabemos que funcionou?”
Imagine:
Cliente
│
│ GOOD
▼
SMTP origem
│
│ GOOD
▼
DNS
│
│ GOOD
▼
MX
│
│ GOOD
▼
Servidor destino
│
│ GOOD
▼
SPF
│
│ GOOD
▼
DKIM
│
│ GOOD
▼
DMARC
│
│ ???
▼
Antispam
Pronto.
Acabamos de transformar um universo gigantesco em uma região investigável.
É praticamente uma busca binária operacional.
O mesmo raciocínio funciona no mainframe:
JOB entrou?
│
▼
JES aceitou?
│
▼
STEP executou?
│
▼
Programa carregou?
│
▼
Arquivo abriu?
│
▼
Db2 conectou?
Sempre procure fronteiras entre:
GOOD → BAD
Essa fronteira frequentemente contém a pista.
📭 Ato XVIII — SMTP não é POP3 nem IMAP
Existe ainda outra confusão clássica.
SMTP é fundamentalmente associado ao envio e transferência de mensagens.
Mas depois que a mensagem está armazenada, historicamente outros protocolos são utilizados para acesso às caixas postais.
Entre eles:
POP3
e:
IMAP.
Uma visão didática:
ALICE
│
SMTP
▼
SERVIDOR A
│
SMTP
▼
SERVIDOR B
│
├──── IMAP ────► BOB
│
└──── POP3 ────► CLIENTE
As arquiteturas modernas podem envolver APIs, sincronização proprietária, serviços em nuvem e inúmeras abstrações adicionais.
Mas essa separação é excelente para construir o modelo mental inicial:
SMTP transporta.
IMAP/POP tradicionalmente ajudam clientes a acessar mensagens armazenadas.
🧠 Ato XIX — O e-mail moderno é uma cadeia de confiança
Agora podemos finalmente enxergar o quadro completo.
Quando apertamos SEND, não estamos simplesmente transportando texto.
Estamos iniciando uma negociação de confiança.
O sistema precisa responder sucessivamente:
PARA ONDE?
│
▼
DNS / MX
QUEM ESTÁ CONECTANDO?
│
▼
SMTP / IP
ESTÁ AUTORIZADO?
│
▼
SPF
EXISTE ASSINATURA VÁLIDA?
│
▼
DKIM
AS IDENTIDADES ESTÃO ALINHADAS?
│
▼
DMARC
QUAL A REPUTAÇÃO?
│
▼
REPUTATION SYSTEMS
O CONTEÚDO É SUSPEITO?
│
▼
ANTISPAM
EXISTE AMEAÇA?
│
▼
ANTIMALWARE
QUAL O DESTINO?
│
▼
INBOX / SPAM / QUARANTINE / REJECT
E aqui está a grande diferença conceitual.
SPF, DKIM e DMARC não dizem simplesmente:
“Este e-mail é bonzinho.”
Eles trabalham com propriedades de autenticação, autorização e alinhamento de identidade.
Depois disso ainda existe outra pergunta:
“Mesmo sabendo melhor quem está falando, devo confiar no que ele trouxe?”
É exatamente por isso que autenticação e antispam coexistem.
🏛️ Ato XX — A Internet aprendeu a desconfiar
Nos primórdios das redes acadêmicas, muitos protocolos nasceram em ambientes muito diferentes da Internet comercial moderna.
A rede cresceu.
Vieram empresas.
Vieram milhões de usuários.
Vieram bilhões de mensagens.
E naturalmente vieram:
spam, phishing, malware, falsificação, campanhas automatizadas e fraude.
A arquitetura precisou ganhar camadas adicionais de defesa.
É um fenômeno recorrente na computação.
Primeiro criamos:
“Faça A conversar com B.”
Depois descobrimos que precisamos perguntar:
“Quem é A?”
Depois:
“A pode fazer isso?”
Depois:
“Posso provar que é A?”
Depois:
“Mesmo sendo A, seu comportamento é aceitável?”
É praticamente a história inteira da segurança da informação condensada em uma mensagem eletrônica.
🏰 Ato XXI — A Catedral do E-mail
Gosto de pensar nesses sistemas como catedrais.
Ninguém acordou numa terça-feira e desenhou toda a infraestrutura mundial de e-mail exatamente como ela existe hoje.
Camadas foram acrescentadas.
Problemas apareceram.
Soluções surgiram.
Protocolos foram ampliados.
Mecanismos de segurança foram incorporados.
E o resultado é uma construção que atravessa décadas mantendo enorme compatibilidade com conceitos antigos.
Isso deveria soar extremamente familiar para quem trabalha com mainframe.
O novo não necessariamente destrói o velho.
Muitas vezes:
o novo envolve o velho.
SMTP continua lá.
DNS continua lá.
Sobre eles construímos novas camadas.
Essa é uma das grandes lições da engenharia de sistemas maduros.
🇪🇸 Epílogo — O julgamento final
Nosso pequeno e-mail finalmente chega diante dos três inquisidores.
Cardeal SPF pergunta:
— Servidor autorizado?
PASS!
Cardeal DKIM pergunta:
— Assinatura?
PASS!
Grande Inquisidor DMARC pergunta:
— Alinhamento?
PASS!
O antispam entra.
— Reputação?
Boa.
O antimalware pergunta:
— Anexo?
Limpo.
O sistema de políticas olha seus registros.
Silêncio.
Nosso e-mail pergunta timidamente:
— Posso entrar agora?
Todos se entreolham.
A porta abre.
Atrás dela existe finalmente:
┌──────────────────────────────┐
│ INBOX │
│ │
│ From: Vagner │
│ Subject: Relatório Produção │
│ │
│ 01:17 │
└──────────────────────────────┘
O pequeno e-mail entra.
Depois de SMTP, DNS, MX, SPF, DKIM, DMARC, reputação, antispam, antimalware e políticas, finalmente cumpriu sua missão.
João chega ao escritório oito horas depois.
Abre a caixa postal.
Olha rapidamente para a mensagem.
E clica:
DELETE.
Silêncio absoluto.
SMTP olha para SPF.
SPF olha para DKIM.
DKIM olha para DMARC.
DMARC olha para o antispam.
Todos atravessaram meio planeta, executaram consultas DNS, verificaram identidades, calcularam criptografia, analisaram reputação e protegeram a infraestrutura para aquilo.
O Cardeal SPF pergunta:
— Podemos interrogá-lo novamente?
O Grande Inquisidor responde:
— Não.
— Por quê?
— Porque ninguém espera...
As portas se abrem.
...A SPANISH INQUISITION DO E-MAIL!
E em algum datacenter distante, às 03:17, outro alerta acaba de surgir.
SMTP DELIVERY FAILURE
O telefone toca.
— Bellacosa?
— Sim.
— O e-mail caiu.
— Todos?
Silêncio.
Pegue o café.
A investigação está apenas começando.
☕ Bellacosa Mainframe — moral da história
Nunca trate um sistema complexo como uma caixa preta chamada “não funciona”.
Divida-o em checkpoints.
Descubra quem falou com quem.
Identifique as evidências.
Encontre o último estado conhecido como GOOD.
Localize a transição:
GOOD
│
▼
GOOD
│
▼
GOOD
│
▼
???
│
▼
BAD
E comece exatamente ali.
Seja investigando SMTP, COBOL, CICS, Db2, MQ, RACF ou um job misteriosamente desaparecido no JES, o princípio continua extraordinariamente útil:
não interrogue o sistema inteiro quando você pode interrogar cada etapa.
Afinal...
ninguém espera a Spanish Inquisition.
Mas um bom analista de produção deveria esperar.
