Grande processadora de pagamentos da Europa não consegue enviar e-mails a usuários do Google Workspace

• A grande empresa europeia de pagamentos Viva.com enviou e-mails de autenticação sem o cabeçalho Message-ID, e os servidores do Google Workspace os rejeitaram
• A RFC 5322, estabelecida em 2008, define Message-ID como um cabeçalho de nível obrigatório, e o Google aplica isso com rigor
• Os e-mails foram recebidos em endereços pessoais do Gmail, revelando a diferença de tratamento entre Google Workspace e Gmail
• O suporte ao cliente da Viva.com não reconheceu o problema técnico e apenas confirmou o resultado do desvio feito pelo usuário, mostrando uma resposta pouco profissional
• O caso, em que nem mesmo a conformidade básica com a RFC foi respeitada, expõe problemas de qualidade e perda de competitividade da infraestrutura fintech europeia

---

Problema: o e-mail de autenticação não chegava

• Durante o processo de criação de conta na Viva.com, o e-mail de autenticação simplesmente não chegava
  • Foi usado um e-mail de domínio personalizado baseado em Google Workspace, e não havia mensagem nem na pasta de spam
• Nos resultados do Email Log Search do Google Workspace, o status aparecia como “Bounced”
  • O motivo da rejeição era “Messages missing a valid Message-ID header are not accepted”
  • O Google rejeitou o e-mail por violar a RFC 5322
• O e-mail enviado pela Viva.com não incluía o cabeçalho Message-ID, um item exigido desde 2008

Solução temporária

• Ao trocar para um endereço pessoal @gmail.com, o e-mail de autenticação foi recebido normalmente
  • Isso sugere que a infraestrutura de recebimento do Gmail é mais tolerante ou processa a mensagem por outro caminho
• Ainda assim, foi apontado como problemático o fato de ser necessário usar um e-mail pessoal para se cadastrar em uma plataforma de pagamentos para empresas

Resposta do suporte

• Foram enviados ao suporte da Viva.com uma captura de tela dos logs do Google Workspace e uma explicação do problema
• A equipe respondeu: “sua conta já possui um e-mail autenticado, portanto não há problema”
  • Não houve sinal de entendimento do problema técnico nem encaminhamento à equipe de engenharia
  • Ou seja, trataram como inexistente um problema que o próprio usuário precisou contornar

A essência do problema

• Message-ID é um cabeçalho básico que todo sistema de e-mail normalmente gera por padrão
  • Para que ele esteja ausente, o pipeline de envio de e-mails precisa estar seriamente mal configurado
• Na RFC 5322, Message-ID é definido como “SHOULD”, mas o Google o trata na prática como obrigatório (MUST)
• Como a Viva.com não segue isso, os e-mails não chegam aos usuários do Google Workspace
• O fato de uma empresa que processa pagamentos em toda a Europa não cumprir uma especificação básica da RFC levanta dúvidas sobre sua confiabilidade técnica

Problema estrutural da infraestrutura fintech europeia

• Em APIs e serviços corporativos europeus, há recorrência de documentação incompleta, tratamento inadequado de erros e suporte pouco profissional
• Isso é apontado não como um problema de capacidade dos engenheiros, mas de falta de concorrência no mercado e de prioridades
• Embora a Stripe tenha elevado o padrão de experiência para desenvolvedores, ela não oferece suporte completo a redes de pagamento regionais europeias (como IRIS), o que reduz as alternativas
• Sem o surgimento de um concorrente no nível da Stripe, é provável que esse tipo de problema de qualidade continue

Proposta de correção técnica

• A Viva.com deve adicionar o cabeçalho Message-ID aos e-mails enviados
  • Exemplo: Message-ID: <[e-mail]>
  • A maioria das bibliotecas de e-mail gera isso automaticamente, e o problema pode ser resolvido com uma alteração de uma linha
• É necessária uma correção imediata para que usuários do Google Workspace possam receber normalmente os e-mails de autenticação

Diferença entre os termos da RFC e a política do Google

• Segundo a RFC 2119:
  • MUST: requisito absoluto
  • SHOULD: só pode ser omitido por um motivo especial
  • MAY: totalmente opcional
• O motivo de Message-ID ser SHOULD é que alguns clientes delegam isso ao servidor
• Para evitar spam, o Google aplica isso como exigência obrigatória, funcionando na prática como um padrão mais rígido que a própria RFC
• Se a Viva.com omitiu isso intencionalmente, deveria ao menos exibir um aviso de “incompatível com o Google Workspace”
  • Operar sem qualquer aviso também contraria o espírito da regra SHOULD

[GN⁺]

Comentários do Hacker News

• Foi apontado como problema o fato de os e-mails de autenticação da Viva.com não terem o cabeçalho Message-ID
  Segundo a seção 3.6 da RFC 5322, “every message SHOULD have a Message-ID field”, mas foi levantada a dúvida se isso pode mesmo ser visto como um “requisito”, já que SHOULD não é MUST

  • Foi explicado que SHOULD é, na prática, um requisito obrigatório
    Deve ser seguido salvo motivo especial, e simplesmente “dar preguiça” não pode ser exceção
    No passado, isso era expresso como SHOULD porque, se um MUA enviasse um e-mail sem Message-ID, o servidor o adicionava automaticamente
    Isso está especificado na seção 8.3 da RFC 6409
  • Segundo a RFC 2119, SHOULD significa que “pode ser ignorado em situações específicas, mas é preciso entender plenamente as consequências e julgar com cuidado”
    Disseram não saber como o Google interpretou isso
  • Como postmaster de uma empresa de hospedagem, um comentarista enfatizou que, em ambiente real de operação, Message-ID é indispensável
    Talvez não em e-mails de teste, mas em e-mails de produção sua ausência causa problemas, como em filtragem de spam
    A falta de Message-ID normalmente é sinal de um sistema de envio customizado mal feito
  • Message-ID não é obrigatório, mas houve reclamação de serviços como o Amazon SES, que sobrescrevem o Message-ID existente
  • Tecnicamente ele pode não existir, mas, para ser classificado como e-mail legítimo, é praticamente essencial
    Disseram que é especialmente absurdo um serviço de pagamentos nem sequer ter testado isso em um grande serviço de e-mail como o Google Workspace

• Uma pessoa com experiência trabalhando em um ESP (Email Service Provider) disse que a maioria dos softwares de servidor rejeitava e-mails sem Message-ID
  Acrescentou que é difícil imaginar ignorar um bounce vindo de um grande destinatário como o Google

  • Na prática, disseram que evitar problemas para o usuário é mais importante do que o padrão em si
    Mesmo que o sistema do outro lado seja irracional, é melhor se adaptar para evitar transtornos ao usuário
  • Para enviar e-mail ao Google Workspace, Message-ID é na prática um MUST
    Se não quiser incluí-lo, então deveria deixar explícito: “não oferecemos suporte a usuários do Google Workspace”
  • Mas a maioria das empresas não liga para esses detalhes técnicos e tem a postura de “só precisa funcionar logo”
    Consideraram que tanto a Viva quanto o Google são grandes demais para se importar com problemas de parte dos clientes
  • Foi apontado que, por ser uma empresa mais focada na Europa, talvez a fatia de usuários do Google Workspace não seja tão grande

• Também surgiram reclamações sobre serviços que enviam a parte alternativa text/plain de forma desleixada
  Há casos em que mandam uma versão em texto sem links ou só conteúdo inútil como “este é um e-mail em texto puro”

  • Disseram que a versão em plain text que só mostra uma “frase bonitinha” na notificação é a mais irritante
    Houve até uma piada de que clientes de e-mail precisariam de IA para resumir HTML
  • Um serviço chegou a incluir, no plain text, informações de reserva de outro cliente (caso da Avis)
  • Alguém comentou que já viu implementação que gera text/plain despejando o HTML no navegador Lynx, e se perguntou se isso realmente tem valor
  • Também disseram já ter visto casos em que colocam o próprio código HTML ou CSS no text/plain

• Houve também comentários ironizando a incompetência técnica de instituições financeiras
  Disseram que “Major European Payment Processor” na verdade significa “Major European Incompetence Center”

  • Outro usuário respondeu que parece exagero, mas que, na prática, o nível de segurança de instituições financeiras já foi horrível
    Como exemplo, citaram a Harland Financial Systems, que usava criptografia XOR de 2 bytes e enviava a chave em texto puro no começo da conexão
  • Outro comentou mencionando casos de corrupção em instituições financeiras dos EUA (aprovações indevidas, abertura não autorizada de contas etc.) e perguntou se na Europa seria parecido

• Um usuário que migrou do Gmail para o Fastmail disse concordar em certa medida com a filtragem rígida de spam do Google
  No Fastmail, entram mais mensagens de spam e phishing

  • Outro usuário afirmou que Message-ID é padrão de fato do setor para e-mails automáticos, então a medida do Google não seria exagerada
    Disseram que há startups que usam o template padrão sem ajustes e acabam sendo confundidas com phishing
  • Também aconselharam que, com o tempo, o filtro de spam do Fastmail aprende e melhora
  • Um usuário antigo do Fastmail brincou que, às vezes, algum spam passa, mas que só os e-mails do LinkedIn sempre conseguem passar
  • Disseram que o Fastmail às vezes demora a reagir a ondas de spam, mas, no geral, estão satisfeitos

• Houve opiniões de que, pelas RFCs, a Viva.com está errada, mas que o Google também estaria agindo de forma inadequada ao rejeitar e-mails por causa de um item SHOULD
  Disseram que, se a probabilidade de spam é alta, deveria ir para a caixa de spam, e não ser rejeitado

  • Também criticaram a realidade de equipes de suporte ao cliente que não repassam o problema ao time técnico e só repetem respostas protocolares
  • Foi compartilhado até um relato interno de que, do ponto de vista do atendente, reconhecer o problema pode prejudicar sua avaliação de desempenho, então ele acaba não tendo escolha
  • Também apareceu uma visão cínica de que os padrões de e-mail não funcionam perfeitamente na prática e que, no fim, todas as regras são quase “SHOULD”

• Foi apontado que o mais grave é a Viva.com nem sequer ter testado o problema de envio de e-mails com o Google Workspace

  • Alguém ironizou dizendo que, na prática, estão fazendo “teste em tempo real” por meio de falhas no cadastro de usuários
    Disseram que a mudança pode até ter vindo do lado do Google, mas o problema maior é a falta de monitoramento
  • Também houve a réplica de que “nem todas as empresas do mundo usam Google Workspace”

• Levantaram a dúvida de há quanto tempo a Viva.com não percebe esse problema
  Disseram que, com um software de e-mail comum, isso provavelmente não teria acontecido, e mencionaram a possibilidade de misconfiguration
  SHOULD não é MAY, e quem não implementa isso precisa aceitar as consequências
  Avaliaram como positivo o fato de o Google ao menos informar a causa na mensagem de erro

• Foi explicado que o Message-ID é originalmente um campo obrigatório herdado da Usenet e que
  ele é necessário para encadeamento de conversas, respostas e arquivamento de e-mails
  Disseram que a ausência de Message-ID passa a impressão de “não quero resposta nem quero deixar registro”, o que parece comportamento suspeito

• Sobre o texto original que criticava a qualidade das APIs de empresas europeias,
  disseram que esse fenômeno não é regional, mas sim um padrão comum a startups e instituições financeiras do mundo todo
  Grandes empresas muitas vezes tratam API como negócio secundário ou a mantêm de forma forçada apenas para cumprir exigências regulatórias
  Em contraste, empresas como a Stripe têm APIs de alta qualidade porque isso é sua linha de vida
  Acrescentaram que startups, por falta de recursos, muitas vezes não têm opção além de priorizar “uma API que funcione” em vez de “uma API boa de usar”