Um sistema de validação está algures entre o facilmente acessível (nomeadamente para spammers) e o nada acessível (que afasta os utilizadores legítimos).
Os serviços de email actuais andarão num meio termo, implementando alguns mecanismos de validação, mas sem comprometer a massificação do serviço. Adicionalmente, funcionam sem mecanismo de validação centralizado, o que mais uma vez é importante para a massificação do serviço, mas limita a possibilidade de implementar validações robustas. Era trivial implementar uma validação de entidades baseada em certificados digitais (toda a infraestrutura já está montada), mas isso mataria o email enquanto método "universal" para comunicação.
A questão da massificação é essencial, pois qualquer alternativa que surja, por mais perfeita que seja, ou atinge um nível de massificação semelhante ao email, ou continua toda a gente a ter que usar email, com todos os custos associados, aos quais acrescem depois os custos da alternativa.
Seria interessante também começares a estimar os custos da validação das entidades (e já agora, de aumentar a capacidade dos servidores de envio de email, por exemplo), para saberes quanto custa combater o spam com o teu sistema.
Temos ainda o problema de privacidade que representa a validação.
Ainda não indicaste nada em concreto que permita concluir que não vai haver aumento do spam através de notificações com a remoção dos sistemas anti-spam.
Resumindo, há a hipótese de nunca saberes quando é que podes eliminar uma mensagem.
Um outro problema das notificações e dos pedidos das mensagens está ao nível da privacidade. Ou abres as mensagens todas (e nesse caso lá se vai a poupança no tráfego), ou o remetente fica sempre a saber quais as mensagens que abriste.
O ViaCTT tem muitos problemas. Um dos que mais afecta a massificação do serviço é precisamente um dos que mais contribui para não haver spam: a necessidade de validar a identificação da entidade a quem pertence a conta. Usar este sistema a nível global é simplesmente impensável. E mesmo a nível nacional, nem com o "empurrão" do estado se consegue impor.
Como já referi, sem massificação é só mais um sistema, para além do email.
Para te dar um exemplo simples, a abertura de uma página web é suposto ser também instantânea. Ainda assim, vários browsers hoje em dia têm a funcionalidade de carregar páginas em background antes de as abrires. Por que o fazem se podiam carregar a página "instantaneamente" depois do utilizador clicar no link? Também estão só a desperdiçar tráfego?
Adicionalmente, sabes que os servidores SMTP usam habitualmente filas para gerir a carga, certo? Isto para além de alguns serviços definirem quotas para o software cliente. Assim podes dimensionar o teu servidor para a carga média (ou um pouco mais). Agora muda o cenário para o teu sistema, em que tens um servidor de envio de newsletters, que passa a ter que lidar com picos de pessoal que chega ao trabalho de manhã, começa a processar os emails, e ficas com o servidor a ter que enviar naquele momento os emails todos que podiam ter sido enviados algures durante a noite. Junta a isto o facto de teres que guardar os emails numa "base de dados" indexada (em vez de teres simples filas), dos sistemas não escalarem linearmente com aumentos de concorrência e de teres que melhorar a tolerância a falhas (para não teres utilizadores que receberam notificações mas não conseguem abrir o email), e pensa em quantas vezes terias que aumentar a dimensão dos sistemas para que os emails não demorassem mais do dobro do tempo a abrir do que demoram actualmente (vamos esquecer o abrir instantaneamente, pois só num sistema que faça pre-fetch dos emails -- como por exemplo o Gmail e IMAP/POP -- e talvez com servidores locais é que consegues a aparência de abertura instantânea, ou sequer de abrir no mesmo tempo que abrem agora, pois há mais uma comunicação remota a fazer, com um componente que tem tudo para ser o bottleneck do sistema).
E já agora não sei se a tua proposta contempla uma alternativa ao protocolo SMTP, mas se não contempla era capaz de ser boa ideia pensares numa... É que o SMTP é tudo menos um protocolo para trocas de mensagens "instantâneas".
↧