Email moderno pode ser construído a partir de partes emprestadas
Os esforços para redesenhar o email com base em padrões web modernos como HTTP reacendem debates antigos sobre controle de spam, identidade e consentimento do usuário. Os comentaristas exploram ideias como aprovação no primeiro contato, postagem opcional ou micropagamentos para tornar o envio em massa caro, e integração mais estreita com mensagens no estilo chat, ao mesmo tempo em que observam os enormes efeitos de rede que mantêm o SMTP em uso e o poder que grandes provedores exercem por meio de sistemas de reputação. Muitos continuam céticos de que qualquer substituto tecnicamente superior consiga ganhar tração sem amplo apoio da comunidade e da indústria, especialmente dada a consolidação do email e o fracasso de soluções “definitivas” contra spam no passado.
Consentimento no primeiro contato e caixa de entrada de “solicitações”
- Muitos gostam da ideia de remetentes desconhecidos irem para uma área de “solicitações” antes de chegarem à caixa de entrada, de forma semelhante aos apps modernos de chat.
- Outros observam que padrões parecidos já existem: greylisting em servidores, whitelisting manual, auto-respostas com links ou tokens de confirmação, e serviços como Hey/Spark.
- As reações dos usuários relatadas são mistas: alguns dizem que as pessoas “odeiam” etapas extras; outros dizem que quase ninguém reclama e que topam confirmar para conseguir falar com você.
- Críticos argumentam que isso só muda o problema de lugar: a pasta de “solicitações” pode virar a nova pasta de spam, com primeiros contatos legítimos enterrados.
Email vs mensagens diretas
- Alguns perguntam se uma especificação de email melhorada poderia substituir mensagens no estilo WhatsApp; DeltaChat é citado como exemplo de ponte entre email e chat.
- Outros enfatizam fluxos de trabalho diferentes: email como caixa de correio versus threads infinitas no estilo chat, com reclamações sobre a dificuldade de extrair threads por tópico para coisas como trabalho jurídico.
Spam, postagem e consentimento
- Várias propostas envolvem “postagem” ou custo por mensagem, idealmente muito barato em baixo volume, mas aumentando com a escala, para tornar o spam em massa antieconômico.
- Micropagamentos são amplamente vistos como impraticáveis; a troca frequente de identidade mina a precificação baseada em volume.
- Alternativas sugeridas: cabeçalhos explícitos “Automated: 0/1” com aplicação via reputação, consentimento obrigatório para email automatizado e pré-aprovação por remetente mais quarentena.
- Reputação e blacklisting em nível de domínio/IP são descritos como centrais para o antispam atual, com quem hospeda por conta própria frequentemente tendo dificuldades.
Protocolos, HTTP e compatibilidade
- Alguns gostam de construir em cima de HTTP e ferramentas existentes (MTA-STS, JMAP, Web Key Directory) com evolução incremental do SMTP em vez de substituição total.
- Outros não gostam de “email sobre HTTP”, preferindo DNS/MX/SRV e DANE, e alertando para problemas como mail com endereço baseado em conteúdo quebrando listas de discussão ou metadados não criptografados.
- É proposto um overlay híbrido “NewEmail” que faz upgrade automático da entrega quando ambos os lados dão suporte a isso (como iMessage vs SMS), com compatibilidade retroativa vista como essencial.
UX, acessibilidade e ceticismo mais amplo
- Vários argumentam que o problema real é UX e clientes, não o protocolo; outros acham que as GUIs existentes já são boas o suficiente e variadas.
- Questões de acessibilidade e a interface distrativa do site do artigo são criticadas.
- Vários comentários destacam a história: incontáveis esquemas para “consertar o email” e “resolver o spam” fracassaram; o email está entrincheirado, “capturado” por grandes provedores, e funciona bem o suficiente para que uma mudança radical seja improvável.