O futuro do e-mail
(fastmail.com)- Em um ambiente em que a IA lê a caixa de entrada, resume mensagens e até executa tarefas, a verificação do remetente se torna a condição central de confiança no e-mail
- SPF, DKIM e DMARC formam a estrutura básica da autenticação de e-mail ao combinar autorização do servidor, integridade da mensagem e política de tratamento em caso de falha
- À medida que filtros de IA e ferramentas assistivas de IA se tornam recursos padrão da experiência de e-mail, os resultados de autenticação passam a ser dados importantes para decidir sobre spam, phishing e ações automáticas
- Como Google e Yahoo passaram a exigir configuração de DMARC de remetentes em massa no início de 2024, a infraestrutura de autenticação se tornou pré-requisito básico para entrega confiável
- A autenticação confirma a identidade do domínio, mas não garante a intenção, e serve para aumentar o custo e a complexidade da falsificação em um ambiente de e-mail automatizado
Autenticação de e-mail: a camada de confiança da qual o futuro do e-mail depende
- O e-mail convive há muito tempo com o problema de spoofing, já que qualquer pessoa podia colocar qualquer coisa no campo “From” de um e-mail
- No passado, usuários atentos conseguiam perceber o problema por sinais como nomes de domínio levemente diferentes, urgência irrealista ou frases estranhas
- Com o uso disseminado de IA, a forma como as pessoas lidam com e-mails está mudando, e passou a ser mais importante conseguir verificar de fato a origem do que apenas saber se a mensagem chegou
- Padrões sobre os quais a maioria dos usuários de e-mail nunca precisou pensar estão silenciosamente se tornando a base da experiência de e-mail
O que é autenticação de e-mail
- A autenticação de e-mail é composta por três padrões interligados: SPF, DKIM e DMARC
- O SPF verifica se o servidor que enviou a mensagem tem autorização para enviar em nome daquele domínio
- O DKIM adiciona uma assinatura criptográfica a cada mensagem para que o servidor de recebimento possa verificar se houve alteração durante o transporte
- O DMARC reúne SPF e DKIM e instrui o servidor de recebimento a rejeitar, colocar em quarentena ou permitir mensagens que falhem na verificação
- Esses três padrões permitem que a caixa de entrada determine se uma mensagem que parece ter sido enviada por um banco ou empregador realmente veio daquele domínio
- Sem autenticação, não é possível distinguir mensagens falsificadas de mensagens legítimas, e esse problema aumenta à medida que a forma de interagir com e-mails muda
Como a IA está se envolvendo com o e-mail
- Dois tipos de IA estão se consolidando como recursos padrão na experiência de e-mail
- O primeiro é a filtragem por IA, que decide o que é spam, phishing ou uma mensagem digna de atenção
- Esses sistemas existem há anos, mas as versões modernas se tornaram muito mais poderosas
- Os resultados de autenticação estão se tornando cada vez mais uma entrada central para os filtros de IA tomarem decisões
- O segundo são as ferramentas assistivas de IA que resumem a caixa de entrada, destacam itens de ação, criam rascunhos de resposta e, em alguns casos, agem em nome do usuário
- A Fastmail não integrou IA à caixa de entrada, e os e-mails dos usuários não são processados por modelos em segundo plano
- O servidor MCP é um endpoint de API que pode se conectar ao cliente de IA escolhido quando o usuário aprova isso explicitamente
- Se o usuário não conectar, nada muda
- No ecossistema mais amplo de e-mail, ferramentas assistivas de IA que agem de forma autônoma na caixa de entrada estão se tornando cada vez mais comuns
- Quando uma pessoa lê um e-mail suspeito, ela pode perceber que o domínio do remetente tem caracteres extras ou que o pedido soa estranho
- Ferramentas assistivas de IA podem procurar itens que exigem ação, ler o conteúdo e a urgência, e agir de acordo com isso
- Se uma mensagem de spoofing for convincente, a autenticação precisa bloqueá-la antes que ela chegue à caixa de entrada
A autenticação está se tornando infraestrutura
- Google e Yahoo começaram a exigir, no início de 2024, que remetentes em massa configurassem corretamente o DMARC para conseguir entregar e-mails de forma confiável
- Com essa mudança, a autenticação deixou de ser algo que remetentes podiam tratar como baixa prioridade e passou a ser condição básica para chegar à caixa de entrada
- A autenticação de e-mail está seguindo uma trajetória parecida com a do HTTPS na web
- O HTTPS passou de boa prática a expectativa, e depois a infraestrutura
- Mesmo sem saber exatamente o que significa o cadeado na barra de endereço, a ausência dele em um site se torna um sinal de alerta impossível de ignorar
- Novos padrões estão sendo construídos sobre essa base de autenticação
- O BIMI permite que remetentes verificados exibam seu logotipo diretamente em caixas de entrada compatíveis
- Isso se torna um pequeno sinal visual de confiança em um momento em que é cada vez mais difícil identificar phishing gerado por IA apenas pelo conteúdo
- O desenho do DKIM está sendo reavaliado com base nas lições aprendidas na especificação experimental ARC
- Isso permite rastrear e atribuir mudanças em fluxos complexos de e-mail, para que sistemas de filtragem possam determinar a origem de conteúdo malicioso
- Também ajuda a evitar que a reputação da entidade errada seja prejudicada
Só autenticação não basta
- A autenticação confirma a identidade do domínio, mas não confirma a intenção
- Um golpista com um domínio parecido e um registro DMARC corretamente configurado pode passar nas verificações de autenticação do remetente
- A autenticação aumenta bastante o custo e a complexidade da falsificação, e isso se torna ainda mais importante quanto mais automatizado for o futuro do e-mail
- A caixa de entrada do futuro será mais rápida, mais inteligente e mais capaz do que a que a maioria dos usuários usa hoje
- A autenticação é o que faz esse futuro ser não apenas conveniente, mas confiável
- Os padrões vêm amadurecendo há anos, e será necessário continuar construindo sobre essa base à medida que o e-mail se automatiza mais
O e-mail não vai desaparecer
- Todo mundo precisa de e-mail: bancos enviam extratos, médicos enviam informações de consulta e outros sites enviam redefinições de senha
- Todo mundo tem e-mail
- O melhor indicador da longevidade de uma tecnologia é há quanto tempo ela já existe, e o e-mail existe há muito tempo
- A Fastmail está na linha de frente do desenvolvimento de padrões que vão sustentar o e-mail do futuro, e continuará evoluindo junto com o e-mail para torná-lo melhor para todos
1 comentários
Opiniões no Hacker News
É difícil julgar o quanto isso realmente ajudaria, mas eu apoio qualquer direção em que o email fique mais seguro a ponto de as organizações, especialmente bancos, governos e seguradoras, deixarem de criar alternativas como caixas de mensagens seguras fechadas
Eles dizem “faça login no centro de mensagens seguras”, e lá você só consegue ver mensagens mal formatadas por um curto período antes de serem excluídas permanentemente
Minha caixa de entrada é uma espécie de registro da vida pesquisável, e essas alternativas quebram isso
Por exemplo, seguradoras precisam seguir a HIPAA, e informações de saúde só podem ser enviadas para outros sistemas compatíveis com a HIPAA
Para isso, é preciso ter um contrato chamado BAA com esse sistema, o que na prática é impossível por email
A seguradora não pode assinar contratos com todos os hosts de email do mundo, nem sabe onde a mensagem vai parar no fim
Também é muito difícil separar com precisão emails que contêm informações de saúde dos que não contêm, e até nome de pessoa ou endereço IP pode se enquadrar dependendo do contexto
Então o padrão acaba sendo mandar tudo para o centro de mensagens, e por melhor que a segurança do email fique, essa parte dificilmente mudará
Os remetentes precisariam ser aprovados com antecedência, como adicionar amigos numa rede social
Já vi clínica médica apagar mensagens que poderiam prejudicá-la em tribunal
Por isso digo para quem me manda esse tipo de coisa enviar por email de verdade
E também manda um email separado, então às vezes eu entro de novo achando que é outra mensagem
Também existe um botão “baixar esta mensagem em PDF”, mas na prática ele só leva para um wrapper de navegador
Disseram que chegaria na semana seguinte
Certamente há vários motivos de compliance, mas isso parece completamente sem sentido
Fui lendo o texto até o fim e fiquei surpreso. Tudo parecia a introdução de algum anúncio ou novidade, mas não veio nada
Posso estar sendo lerdo, mas por isso não entendi qual era a conclusão principal
Sempre que uma empresa começa a falar de futuro brilhante, normalmente significa que minha experiência de usuário vai piorar em breve
Na prática, era “agora precisa passar no DMARC”, mas isso já é realidade há uns 2 anos
Também é verdade que autenticação ajuda a impedir domínios falsificados, mas não acho que esse seja o maior problema
Atacantes descobrem formas de fazer plataformas de pagamento como PayPal e Stripe enviarem emails
Depois entendem quais informações entram no email gerado e definem o nome da empresa como algo tipo “há um problema, ligue para este número”
Aí esse nome aparece no assunto ou no corpo de um email legítimo vindo do próprio PayPal, com todas as autenticações aprovadas, e a mensagem parece urgente
Como esses emails são realmente enviados por empresas reais e passam em todas as verificações, o DMARC não consegue barrá-los, e tenho visto atacantes agirem exatamente assim ultimamente
Eu realmente esperava que o Fastmail lançasse algo para lidar com esse problema
Em resumo, é isso. Não sei como se chega lá, mas a ideia é que o email ficará mais rápido e mais inteligente
Sinceramente, fico me perguntando por que esse texto foi postado e recebeu votos
Gosto do Fastmail. Mudei do Proton há alguns anos porque concluí que os compromissos do email criptografado não valiam tanto a pena
Mesmo confiando totalmente no Proton, a maioria dos emails de qualquer forma acaba passando por AWS, Outlook e Gmail
Estou muito satisfeito com o serviço do Fastmail. O preço é justo, ele é muito rápido mesmo com caixas de entrada grandes, e não fica adicionando recursos desnecessários ou inchaço
Eu pretendia usar o app de email padrão do sistema operacional, mas o app e o site do Fastmail são tão bons que acabei usando só eles
Trinta anos de memória muscular acumulada usando webmail viram inúteis por causa desse “app”
Parece coisa de algum desenvolvedor web querendo brincar de desenvolvedor de app desktop
E não foi acidente: disseram que foi uma escolha deliberada não incluir atalhos de teclado para voltar à página anterior
O suporte ao cliente disse que adicionaria isso como “pedido de recurso”
Estamos basicamente terceirizando o julgamento do email para a IA, enquanto tentamos compensar reforçando SPF/DKIM
É como fazer fechaduras mais fortes enquanto distribuímos mais chaves-mestras
Não dá para falar como se o Fastmail tivesse autoridade absoluta sobre email
O Fastmail não é o próprio email, e sim um serviço dependente dele
Até que eu possa mover minha caixa de entrada e roteá-la para o provedor que eu quiser, esses sistemas de autenticação parecem ter valor prático limitado em larga escala
Se é possível portar número de telefone, em teoria também deveria ser possível portar endereço de email
Os sistemas de autenticação mencionados aqui não ajudam o suficiente para tornar essa portabilidade viável
É preciso uma forma válida de autenticar a própria pessoa, e não o nome de domínio do email, independentemente de qual provedor ela use
Em outras palavras, precisa evoluir um padrão que permita assinar em nome do próprio provedor de hospedagem
Em 2026, não faz sentido que assinatura e criptografia de e-mail ainda não sejam o padrão.
Mas, enquanto o modelo de negócios dos grandes provedores de e-mail depender de nós não usarmos isso, provavelmente vai continuar assim
Para tornar a caixa de entrada realmente utilizável, todo o processamento de machine learning precisa rodar, e para isso o e-mail não pode estar criptografado
Se quisessem, teria sido muito mais difícil para a Microsoft compartilhar dados do Outlook com 1000 parceiros
E-mail criptografado soa bem, mas, quando se analisam as ameaças reais, ele não oferece tanta proteção em comparação com o estado atual e ainda perde muita funcionalidade.
Partindo da premissa básica, o e-mail já é criptografado do meu computador até o servidor de e-mail, do meu servidor de e-mail até o servidor de e-mail do destinatário, e do servidor de e-mail do destinatário até o computador dele.
As únicas entidades que podem ver algo além de mim e do destinatário são os servidores de e-mail intermediários, e o melhor que se consegue com e-mail criptografado é excluir algumas das entidades que desempenham papel central nesse processo.
Em especial, os cabeçalhos do e-mail continuam expostos, então mesmo no melhor cenário isso não vira uma comunicação realmente privada.
Em compensação, e-mail criptografado quebra processamentos como filtros no lado do servidor. O tratamento de spam também entra nisso e, considerando especialmente a enorme quantidade de spam que nem chega à pasta de spam, não há solução prática.
Os usuários esperam poder entrar no webmail e ler o e-mail na hora, e o webmail é o cliente de e-mail dominante.
Se, para resolver isso, você entregar a chave ao servidor, o servidor volta a ser uma entidade capaz de ler o e-mail, e não muda nada em relação ao estado atual.
O problema maior é a distribuição de chaves. Para enviar um e-mail, é preciso encontrar a chave do destinatário, e a forma mais prática em larga escala é perguntar ao servidor de e-mail pela chave pública do usuário.
Só que esse servidor é justamente a única entidade capaz de interceptar todas as mensagens destinadas àquele usuário, então ele pode fornecer a própria chave, remover a criptografia e depois criptografar de novo para o usuário sem ser facilmente detectado.
Alternativas como servidores de chave PGP também não funcionam. Mesmo na época em que havia menos de um milhão de usuários interessados em criptografia PGP, o ecossistema de servidores de chave PGP já tinha colapsado há alguns anos, e isso nem se compara à escala de bilhões de usuários de e-mail.
E-mail criptografado me parece menos um sonho inviabilizado pelo modelo de negócios das empresas de e-mail e mais um sonho pouco realizável porque a arquitetura do e-mail já oferece uma segurança boa o suficiente, tornando muito difícil extrair benefícios reais de criptografia adicional
Precisa ser um sistema com boa experiência de usuário e excelente criptografia
O texto menciona a proposta fracassada de ARC, que tentava impedir que o DKIM fosse quebrado no encaminhamento de e-mails.
https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
Seria interessante ver se o Google pode ser convencido a migrar do ARC para outra abordagem.
Hoje em dia o Gmail dá muita importância à reputação do servidor de e-mail, então consegue tratar de forma consistentemente negativa servidores de e-mail de que não gosta
“A segunda é o suporte por IA. Ferramentas que resumem a caixa de entrada, destacam itens de ação, rascunham respostas e, em alguns casos, agem em nome do usuário”
Essa parte é a mais perversa. No fim, a estrutura vira bots conversando com bots, e os humanos ficam de fora.
Todos os problemas de e-mail podem ser resolvidos com GPG, mas isso destruiria o negócio de serviços de e-mail como o Fastmail.
Porque eles não poderiam ler e analisar os e-mails dos usuários, não poderiam vender anúncios, não poderiam vender perfis de usuários para empresas de publicidade e não poderiam treinar IA com os dados dos usuários.
O futuro do e-mail que eu quero ver é nessa direção. Infelizmente, ninguém usa GPG, e também é bem difícil ensinar as pessoas a usar
A única forma de provar que a comunicação é genuína será fazer troca de chaves presencialmente com antecedência.
O GPG é só um dos caminhos, e alguém vai apresentar uma forma de tornar isso fácil em nível organizacional
Para análise, metadados têm mais valor do que o conteúdo das mensagens. Como o GPG resolve isso?
Eu esperava que este texto fosse sobre JMAP
Não são criptografia do corpo da mensagem, mas mostram que ainda há espaço para melhorar até o ambiente básico de e-mail
É frustrante não conseguir enviar e-mail em um projeto de hobby, mesmo seguindo todas as regras e colocando os cabeçalhos corretos.
O texto do jeremyevans sobre hospedagem própria de e-mail foi uma leitura divertida, mas fala só sobre recebimento e não aborda envio.
https://code.jeremyevans.net/2021-07-29-running-my-own-email...