Reflexões públicas sobre um e-mail de 2ª geração

Note: Este texto é apenas uma organização das minhas ideias. Não foi algo pensado a fundo, e não é necessário considerar que seja uma boa ideia. Leia com as expectativas o mais baixas possível.

Problemas do e-mail

• Muitas tecnologias antigas ainda continuam em uso, mas o e-mail me irrita toda vez que preciso usá-lo.
• Do ponto de vista do usuário, o e-mail funciona bastante bem. Às vezes envia e-mails demais por causa de spam, mas é antigo, confiável, fácil de entender e relativamente fácil de pesquisar.
• Porém, o backend do e-mail é uma bagunça.

Problemas do backend de e-mail

• Muitos recursos do e-mail não têm uma especificação clara. Por exemplo, ao enviar uma resposta, não está claramente definido se ela deve ir no topo ou no fim da mensagem.
• Não está claro que tipo de HTML pode ser usado em e-mails. Há casos em que o Microsoft Outlook abusa do renderizador de HTML do Microsoft Word.
• Também não está claro como criptografar e-mails. Inventaram algo chamado OpenPGP, mas ele quase não foi usado e tem falhas graves.
• Nunca foi possível verificar sempre a autenticidade do e-mail. Então inventaram o SPF, mas o SPF também não resolveu todos os problemas. Depois inventaram o DKIM, mas o DKIM também não resolveu tudo. Então inventaram o DMARC, mas como o próprio DKIM tem falhas grandes, o DMARC também pode ser contornado.
• Adicionaram outra camada chamada BIMI, que também depende de DMARC, que depende de DKIM, e o DKIM tem falhas.
• Mesmo quando há DMARC, 68,2% dos registros estão configurados com p=none. Isso significa que, na prática, o DMARC não faz nada por padrão.
• Por causa de tudo isso, somado a políticas agressivas de combate a spam, hospedar seu próprio e-mail é muito difícil.
• Por fim, existe a gestão de reputação de IP. Alguns endereços IP são mais “limpos” do que outros, especialmente em sistemas compartilhados como SendGrid ou AWS SES. Isso complica o registro de contas de envio em massa e faz com que e-mails legítimos sejam frequentemente classificados como spam.

Hipótese sobre um e-mail de 2ª geração

• Criar um novo registro DNS MX2. A maioria dos serviços de e-mail teria registros MX2 e MX. Serviços antigos teriam apenas MX.
• Se um cliente de e-mail antigo, de 20 anos atrás, tentar enviar uma mensagem, ele procurará o registro MX e enviará a mensagem. Clientes modernos olharão para MX2 e enviarão a mensagem por ele.
• Serviços de e-mail que implementarem MX2 publicariam uma data de divulgação e, após essa data, classificariam automaticamente como spam todas as mensagens enviadas para o registro MX.

Prioridades do e-mail de 2ª geração

1. Fornecer uma especificação padronizada de HTML para e-mail e uma suíte de testes de conformidade.
2. Fornecer um cabeçalho para preferências de encadeamento de e-mail ou outras preferências relacionadas a e-mail.
3. Fornecer, junto com a visualização em HTML, uma cópia somente em texto, sem HTML.
4. Todos os registros MX2 devem incluir uma chave pública.
5. Gerar um hash para verificar a autenticidade e a integridade do e-mail, criptografá-lo e adicioná-lo ao cabeçalho.
6. Eliminar SPF, DKIM e DMARC, padronizando tudo em um único registro MX2 para simplificar stacks de e-mail self-hosted.
7. Autenticar e-mails com base no domínio, e não no endereço IP.
8. Clientes que implementarem MX2 poderiam escolher um novo esquema de criptografia para substituir o OpenPGP.

Pensamentos adicionais

• É necessário algum meio de compartilhar arquivos grandes.
• Sem a participação do Google e da Microsoft, o MX2 nunca se tornará realidade.
• Também seria possível considerar substituir o SMTP por HTTP com uma API REST padronizada e corpo em JSON.
• O próprio uso de HTML pode ser controverso. O e-mail originalmente não foi projetado para HTML.
• Existe uma oportunidade de impor um novo padrão de forma rígida.

Opinião do GN⁺

• A tentativa de resolver a complexidade e os problemas de segurança do sistema de e-mail é muito interessante. Em especial, propor uma nova forma de garantir a autenticidade e a integridade do e-mail pode ser útil.
• No entanto, introduzir um novo padrão é algo muito difícil. Em especial, a participação de grandes players como Google e Microsoft é essencial.
• A controvérsia em torno do uso de HTML continua existindo. Para resolver os problemas de segurança, pode ser necessário considerar outra linguagem de marcação.
• Fazer cumprir rigidamente um novo padrão seria o ideal, mas, na prática, isso pode ser difícil. Seriam necessários mecanismos adicionais para evitar desvio do padrão e erros de implementação.
• A centralização do sistema de e-mail pode ajudar na introdução de um novo padrão, mas ao mesmo tempo pode aumentar a dependência de empresas específicas.

[cometkim]

Pelo menos no que diz respeito às melhorias de renderização, Google e Microsoft já investiram nisso... afinal, ambos participaram e deram suporte ao projeto AMP Email.

[coremaker]

Criar um padrão de dados como JSON é bom,
mas também seria preciso discutir junto a especificação de renderização, então não parece algo simples.

Será que o motivo de terem escolhido HTML
não foi justamente pegar carona, sem custo, na especificação de renderização de HTML+CSS?

[ldmsys]

Como o pessoal acima já mencionou Shop Mail como um caso extremo, pessoalmente vejo com bastante ceticismo a própria ideia de classificar abertamente um protocolo que já funciona bem como deprecated e fazer com que apenas algum novo padrão de protocolo incompatível seja compatível.

[unsure4000]

4. Todos os registros MX2 devem incluir uma chave pública.
   Isso é meio estranho, porque parece que os provedores de serviço usariam para essa chave pública não a chave pública enviada pelo usuário, mas sim uma chave pública que eles mesmos criaram...

[iolothebard]

Então foi por isso que criamos o Ssapmail... (hã? não era isso...)

[xguru]

O sistema de e-mail é conveniente e bom, mas realmente acho que melhorias graduais no protocolo são necessárias.
Usar esse método assim mesmo daqui a algumas décadas é meio...

[GN⁺]

Opinião no Hacker News

Resumo da coletânea de comentários do Hacker News

• Complexidade e interoperabilidade do sistema de e-mail

  • Com base na experiência de operar serviços de e-mail na internet, o sistema de e-mail é complexo, mas amplamente adotado e altamente interoperável.
  • Introduzir um novo sistema é difícil, pois ele precisa competir com o enorme investimento em P&D do sistema existente.
  • Se alguém quiser propor um novo sistema de e-mail, seria melhor fazê-lo em lugares como a IETF ou a M3AAWG.

• Ambiguidade e problemas do e-mail

  • Pode haver confusão quando os cabeçalhos de e-mail têm valores duplicados ou conflitantes.
  • Existem vários problemas, como quando cabeçalhos que deveriam usar apenas ASCII incluem valores de 8 bits.
  • A forma de gerenciar threads de e-mail também não é padronizada, o que causa problemas.

• Problema de centralização do e-mail

  • A centralização do e-mail não é desejável. As empresas tendem a agir em direções que as favorecem, e não necessariamente no que é melhor para a humanidade.
  • Hospedar seu próprio e-mail não é difícil, e também é possível hospedá-lo facilmente por meio de um provedor confiável.

• Problemas do e-mail em HTML

  • E-mails em HTML podem causar problemas como phishing e fraudes.
  • Se o e-mail fosse redesenhado, houve a opinião de que seria melhor excluir HTML e usar um formato como Markdown.

• Necessidade de manter a natureza assíncrona do e-mail

  • O e-mail precisa continuar sendo assíncrono, e isso é a última linha técnica de defesa contra a jornada de trabalho de 24 horas.
  • Esse é um dos motivos pelos quais as pessoas não adotam sistemas melhores.

• Dificuldade de operar servidores de e-mail

  • Operar servidores de e-mail está ficando cada vez mais difícil, porque é necessário atender às exigências dos grandes provedores.
  • Servidores pequenos estão sendo eliminados pelos grandes provedores ou por remetentes de spam.

• Definição de e-mail legítimo

  • A definição de e-mail legítimo é subjetiva. O spam está estragando a internet, e é preciso algum método de impor custos para bloqueá-lo.

• Necessidade de melhorar o sistema de e-mail

  • Mesmo que o sistema de e-mail seja redesenhado, o ideal é mantê-lo e melhorá-lo sem abandonar o sistema atual.
  • É necessário adotar sistemas modernos de criptografia e de autenticação do remetente.

• Checklist de ideias anti-spam

  • São necessárias algumas mudanças de implementação para prevenção de spam.
  • Encaminhadores de e-mail e servidores SMTP devem encaminhar o mais rápido possível, e a filtragem de spam deve rejeitar mensagens no nível SMTP.

Checklist de ideias anti-spam