Pegue uma mensagem. Uma loja inventada, a Bright Parcel, acaba de ver um visitante se cadastrar com o endereço quietfox42@veylax.com, e o sistema dela aperta o equivalente a Enviar em um e-mail de confirmação. Pouco depois essa mensagem está na tela do visitante e, um dia depois, ela já não existe em lugar nenhum do serviço de caixa de entrada. Este artigo a acompanha por todo o caminho.
Então, como o temp mail funciona? Ele usa a engrenagem comum do e-mail da internet com uma diferença: o lado que recebe aceita mensagens para qualquer nome de usuário nos seus domínios e as guarda só por pouco tempo. O servidor do remetente consulta o registro MX do domínio no DNS, conecta-se ao host indicado por SMTP na porta 25 e entrega a mensagem. O sistema de temp mail então a analisa, mostra em uma caixa de entrada e a exclui num prazo programado. No VookMail, os registros MX dos domínios apontam para um provedor de entrega de e-mail, que recebe a sessão SMTP e repassa cada mensagem ao VookMail por HTTPS.
Etapa 1: saindo do remetente
O aplicativo da Bright Parcel monta a mensagem. Uma mensagem é um texto estruturado, organizado conforme o Internet Message Format (RFC 5322): cabeçalhos como From, To e Subject, depois uma linha em branco, depois o corpo. O aplicativo em geral não a entrega diretamente. Ele a passa a um serviço de envio de e-mail, por uma conexão SMTP autenticada na porta 587 (ou 465, com TLS desde o início) ou pela API web da empresa de envio.
O primeiro atraso pode acontecer logo aqui. Muitos aplicativos colocam as mensagens de saída em uma fila de tarefas e as processam em lotes, em especial as plataformas de marketing. Assim, o momento em que um site diz «verifique seu e-mail» pode estar bem à frente do momento em que a mensagem sai. No nosso exemplo, digamos que a fila leve vinte segundos. Nada chegou ainda ao lado do destinatário, e nenhum serviço de temp mail consegue ver isso nem acelerar.
Etapa 2: descobrindo onde o veylax.com recebe suas mensagens
O servidor de saída lê a parte depois do @, neste caso veylax.com, e pergunta ao DNS pelos registros MX desse domínio. Um registro MX (mail exchanger) indica um servidor que aceita mensagens do domínio. Em notação de arquivo de zona, os registros de um domínio poderiam ser assim. Os nomes são inventados, só para ilustrar:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
O 3600 é o TTL (time to live), o número de segundos em que um resolvedor pode guardar essa resposta em cache. O 10 e o 20 são preferências: os remetentes tentam primeiro o menor número e recorrem ao maior se não conseguem alcançá-lo. O nome do host precisa ter seu próprio registro A (IPv4) ou AAAA (IPv6). Um registro MX deve apontar para um nome de host, e não diretamente para um endereço IP nem para um apelido CNAME.
Você mesmo pode fazer essa consulta para qualquer domínio:
| Sistema | Comando |
|---|---|
| Prompt de Comando do Windows | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS e Linux | dig MX example.com +short |
Sistemas antiabuso usam essa mesma consulta para identificar domínios que encaminham mensagens para infraestrutura descartável conhecida. Esse é um dos motivos pelos quais alguns sites reconhecem domínios de temp mail mesmo quando o domínio em si é novo.
Dois casos extremos no DNS
Um domínio sem registro MX não é automaticamente inalcançável. A RFC 5321, o padrão do SMTP, define uma alternativa: o remetente pode tratar o próprio registro A ou AAAA do domínio como um host de e-mail implícito. Um domínio que não quer receber mensagem nenhuma pode dizer isso com um null MX (RFC 7505), que é um registro MX com preferência 0 e um único ponto como host. Os domínios de temp mail publicam registros MX normais, claro, já que receber é todo o propósito deles.
O cache também pode atrapalhar quando um serviço adiciona um domínio. Resolvedores que receberam há pouco uma resposta «registro inexistente» podem guardá-la até o fim do tempo de cache negativo, controlado pelo registro SOA do domínio (RFC 2308). Um domínio novinho em folha pode, por isso, demorar um pouco para receber de forma confiável de todos os remetentes.
Etapa 3: a conversa entre dois servidores
O servidor de saída da Bright Parcel agora abre uma conexão TCP com o host MX preferido na porta 25. O SMTP é um protocolo de texto: o cliente envia comandos e o servidor responde com códigos numerados. Veja uma sessão simplificada para a nossa mensagem, em que S: é o receptor e C: é o remetente. Os hosts e o valor de tamanho pertencem a este exemplo inventado.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(handshake TLS, depois EHLO de novo)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (cabeçalhos, linha em branco, corpo, depois uma linha com um único ponto)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Comando | Finalidade | O que significa para o temp mail |
|---|---|---|
EHLO | Identifica o remetente e pergunta o que o servidor aceita | A resposta lista extensões como STARTTLS e o SIZE máximo |
STARTTLS | Eleva a conexão para TLS (RFC 3207) | Protege só esse salto. Não é criptografia de ponta a ponta |
MAIL FROM | Define o remetente do envelope, para onde vão as devoluções | Muitas vezes difere da linha From visível, em especial para remetentes de envio em massa |
RCPT TO | Indica um destinatário | Um receptor catch-all responde 250 para qualquer nome de usuário nos seus domínios |
DATA | Inicia o conteúdo da mensagem | Termina com um único ponto em uma linha só |
QUIT | Encerra a sessão | A entrega já foi decidida pelo 250 depois do DATA |
O momento em que a responsabilidade muda de mãos
Esse 250 final é a linha mais importante da sessão. Até ali, a mensagem pertence ao servidor da Bright Parcel, que tenta de novo se a conexão cair. Depois dele, o receptor assumiu a responsabilidade. O painel do remetente passará a dizer, em geral, «entregue», o que só significa que esse salto deu certo. Não significa que uma pessoa viu alguma coisa.
Os códigos de resposta explicam boa parte do comportamento que as pessoas observam:
- 2xx é sucesso, e
250significa aceito. - 3xx é uma etapa intermediária, e
354manda o remetente transmitir a mensagem. - 4xx é uma falha temporária, por exemplo
421ou451. O remetente mantém a mensagem na fila e tenta de novo. - 5xx é uma falha permanente, por exemplo
550(caixa indisponível ou rejeitada) ou552(grande demais). O remetente desiste e em geral gera uma mensagem de devolução.
A diferença entre 4xx e 5xx explica a maior parte das mensagens «lentas». Se o receptor tivesse respondido 451 neste ponto, talvez por causa de greylisting (RFC 6647), nossa mensagem estaria parada na fila da Bright Parcel, nem perdida nem entregue. A RFC 5321 recomenda um intervalo de nova tentativa geralmente de pelo menos 30 minutos e um prazo de desistência de pelo menos quatro a cinco dias, embora os sistemas reais definam seus próprios calendários, e muitos tentem antes. É por isso que uma confirmação pode aparecer depois de alguns segundos e a seguinte depois de vinte minutos, sem que nada esteja errado em nenhum dos casos.
Dois conjuntos de endereços
O SMTP tem duas camadas de endereçamento. O envelope, MAIL FROM e RCPT TO, é o que os servidores usam para o roteamento. Os cabeçalhos, From:, To: e Subject:, fazem parte do conteúdo da mensagem e são o que você vê na tela. Eles podem ser diferentes. Uma newsletter pode exibir To: subscribers embora o destinatário do envelope fosse o seu endereço temporário. Por isso um sistema receptor arquiva as mensagens pelo destinatário do envelope, o valor confiável. É também por isso que o cabeçalho Return-Path, acrescentado na entrega final, registra o remetente do envelope e não o endereço From visível.
Etapa 4: por que o quietfox42 não precisava existir
No RCPT TO, um servidor de e-mail normal verifica se a caixa existe e responde 550 se não existir. Um domínio de temp mail funciona ao contrário. Ele atua como receptor catch-all, ou curinga: toda parte local (o trecho antes do @) é aceita.
Essa única escolha é o que torna possíveis os endereços instantâneos. Quando o VookMail mostra um endereço aleatório, nada precisou ser criado em servidor de e-mail algum. Quando você aperta Novo, digita seu próprio nome de usuário, escolhe um domínio e aperta a seta, esse nome já «existe», porque o domínio aceita todos os nomes. O aplicativo só precisa mostrar as mensagens cujo destinatário corresponde ao endereço que está na sua tela.
Duas regras pequenas valem para esses nomes. O padrão diz que uma parte local pode diferenciar maiúsculas de minúsculas, mas quase todos os sistemas reais tratam Test@ e test@ como uma só caixa, então um sistema de temp mail sensato normaliza a caixa para impedir que a capitalização do remetente divida uma caixa de entrada em duas. E a RFC 5321 limita a parte local a 64 octetos, com um limite prático de 254 caracteres para um endereço inteiro, então os nomes gerados devem ficar bem dentro disso.
Etapa 5: do protocolo de e-mail à requisição web
Nossa mensagem agora foi aceita por uma máquina que fala SMTP. O site que mostra a caixa de entrada é um aplicativo web. Algo precisa ligar os dois.
Manter um servidor de e-mail voltado para toda a internet dá trabalho de verdade: TLS, enxurradas de conexões, filas, malware e a manutenção de uma boa reputação. Por isso muitos aplicativos modernos entregam o lado SMTP a um provedor de recebimento especializado e recebem as mensagens como requisições web, um padrão muitas vezes chamado de inbound parse webhook. O VookMail usa esse modelo. Funciona assim:
- Os hosts MX do provedor aceitam a mensagem do servidor do remetente, como na sessão acima.
- O provedor a empacota, como código-fonte MIME bruto ou como campos já analisados, tais como remetente, destinatários, assunto, texto, HTML e anexos.
- Ele envia esse pacote em um HTTPS POST para um endpoint operado pelo aplicativo de temp mail, o que criptografa o conteúdo entre esses dois pontos.
- O aplicativo responde com um status de sucesso. Se estiver inacessível ou devolver um erro, um provedor bem-comportado tenta de novo conforme a sua própria política.
- O aplicativo valida a requisição, associa o destinatário a um endereço e guarda a mensagem temporariamente.
| Ponto de atenção | Receptor SMTP próprio | Provedor de recebimento mais HTTPS |
|---|---|---|
| Exposição | Porta 25 aberta para todos os hosts da internet | O provedor recebe o tráfego SMTP, e o aplicativo vê apenas requisições HTTPS |
| Picos de tráfego | O operador precisa dimensionar a capacidade | A infraestrutura do provedor absorve os picos |
| Análise de MIME | O operador escreve ou mantém um analisador | Muitas vezes feita pelo provedor, embora o código-fonte bruto ainda possa ser usado |
| Encaixe com um aplicativo web | Precisa de uma ponte entre a fila de e-mail e o aplicativo | A mensagem chega como qualquer requisição de API |
| Dependência | Menos terceiros envolvidos | Depende da disponibilidade e da configuração do provedor |
A última linha é um custo real. Se um provedor de recebimento tem uma queda ou um problema de configuração, a entrega para todos os domínios que dependem dele pode parar até que seja resolvido, mesmo com o site de temp mail funcionando normalmente. As mensagens recusadas com erro temporário nesse período ainda podem passar quando os remetentes originais tentarem de novo, dependendo de quanto tempo as filas deles as mantêm.
Protegendo o endpoint
Um endpoint de webhook é uma URL pública, então qualquer pessoa poderia tentar enviar uma mensagem falsificada para ele. Implementações cuidadosas costumam combinar várias defesas:
- Verificação de assinatura, em que o provedor assina cada requisição e o aplicativo rejeita as que não conferem.
- Um caminho secreto ou token conhecido apenas pelo provedor e pelo aplicativo.
- Restringir as requisições às faixas de endereços publicadas pelo provedor, onde elas existem.
- Limites de tamanho, que rejeitam cargas grandes demais logo no início para proteger a memória e o armazenamento.
- Idempotência. Os provedores tentam de novo, então a mesma mensagem pode chegar duas vezes, e um Message-ID ou um ID de evento do provedor evita duplicatas.
Etapa 6: desmontando a mensagem
O que chega ainda não é algo que uma pessoa consiga ler com conforto. O MIME (Multipurpose Internet Mail Extensions, RFC 2045 em diante) permite que uma mensagem carregue várias partes em formatos diferentes. Nosso e-mail de confirmação poderia estar organizado assim, com uma fatura adicionada como exemplo:
| Parte | O que contém |
|---|---|
multipart/mixed | O contêiner externo quando há anexos |
multipart/alternative | O mesmo conteúdo duas vezes, como text/plain e text/html. O leitor mostra a forma mais rica que aceita |
multipart/related | O HTML agrupado com imagens embutidas, referenciadas por identificadores cid: |
| Parte de anexo | Um cabeçalho Content-Disposition: attachment e um nome de arquivo, depois os dados codificados do arquivo |
Acima delas ficam os cabeçalhos, incluindo Message-ID, Date e as linhas de rastreio Received, que registram todos os servidores por onde a mensagem passou. Se um dia você quiser saber onde houve um atraso, os carimbos de hora das linhas Received são o lugar para olhar.
Um analisador também precisa reverter várias codificações. O Base64 carrega anexos binários e os infla em cerca de um terço, de modo que um arquivo de 10 MB vira uma mensagem de aproximadamente 13 a 14 MB. O quoted-printable trata texto quase todo ASCII escrevendo caracteres especiais como =XX. O valor de charset= diz como o texto está codificado, em geral UTF-8, o que importa muito para um serviço usado em muitos idiomas. E os assuntos com caracteres não ASCII usam a sintaxe =?UTF-8?B?...?= ou =?UTF-8?Q?...?= da RFC 2047.
Tornando o HTML seguro para exibir
O HTML de e-mail é escrito por desconhecidos, então um visualizador não pode deixá-lo executar código no contexto do site. Implementações cuidadosas costumam remover scripts, atributos de manipuladores de eventos e esquemas de URL perigosos, e exibir a mensagem em um quadro isolado, para que seus estilos e conteúdo não afetem a página ao redor.
As imagens remotas também exigem cuidado. Carregar uma delas avisa o remetente de que a mensagem foi aberta, e é assim que funcionam os pixels de rastreamento. O VookMail remove os pixels de rastreamento ocultos e mantém as imagens desligadas até você permitir.
Um visualizador também pode fazer algo útil com o texto analisado. Para a nossa mensagem de confirmação, o VookMail mostra o código de verificação ou o link de confirmação acima da mensagem, para que ninguém precise rolar um modelo longo para encontrá-lo.
Anexos
Os anexos são decodificados e guardados temporariamente para poderem ser baixados. No VookMail, tipos comuns de programa como .exe, .bat e .apk são recusados, arquivos compactados como .zip mostram um aviso, e há tamanhos máximos. Os anexos são excluídos junto com as mensagens. Lembre que a segurança de um arquivo não tem a ver com onde ele foi guardado: um documento com macros é tão perigoso baixado de uma caixa temporária quanto de qualquer outra.
Etapa 7: chegando à tela
Nossa mensagem agora está guardada, mas o navegador que mostra quietfox42@veylax.com ainda não sabe disso. Os aplicativos web têm várias maneiras de descobrir:
| Técnica | Como funciona | Vantagens e desvantagens |
|---|---|---|
| Short polling | A página pergunta ao servidor a cada poucos segundos | Simples e confiável, mas faz requisições repetidas |
| Long polling | Uma requisição fica aberta até haver novidade ou o tempo esgotar | Menos respostas vazias, mais conexões abertas |
| Server-Sent Events | Um único fluxo de longa duração do servidor para o navegador | Eficiente em uma direção, reconecta sozinho |
| WebSockets | Uma conexão persistente de mão dupla | Totalmente interativo, precisa de infraestrutura dedicada |
A caixa de entrada do VookMail procura mensagens a cada poucos segundos, e o botão Atualizar faz a verificação manual, por exemplo depois que seu dispositivo ficou em repouso ou sua rede caiu. Esses poucos segundos costumam ser o trecho mais curto da viagem. Se a mensagem parece lenta, o tempo quase sempre foi gasto antes, na fila do remetente ou em uma nova tentativa.
Criar um endereço também passa por uma pequena proteção contra robôs: um cálculo curto no navegador do visitante, conhecido como proof of work. Para um visitante normal custa quase nada, e torna mais caro criar endereços em massa.
O endereço também pode ser aberto em outro lugar. Como o próprio endereço identifica a caixa de entrada, passá-la para outro dispositivo só exige repassar o endereço. O botão QR do VookMail mostra o endereço como um código que um celular pode escanear, para que a mesma caixa seja aberta ali, e os aplicativos para Android e Huawei mostram as mensagens do mesmo jeito. Isso é cômodo, e também mostra por que essas caixas têm pouca privacidade: qualquer pessoa que conheça ou adivinhe um endereço pode abrir aquela caixa. Um endereço aleatório é a escolha mais segura, porque é muito mais difícil de adivinhar do que um nome curto.
Etapa 8: exclusão
Cerca de um dia depois de a nossa confirmação chegar, ela vai embora. A retenção em um sistema de temp mail costuma ser implementada com um carimbo de hora em cada mensagem guardada e uma tarefa programada que remove tudo o que passou do limite. Os anexos guardados como arquivos separados saem ao mesmo tempo. Outros projetos usam expiração no próprio armazenamento, em que o banco de dados remove os registros antigos por uma configuração de time-to-live. As tarefas em lote são um dos motivos pelos quais os serviços tendem a descrever a expiração como «cerca de» um dia, já que o momento exato depende de quando a tarefa roda. No VookMail, mensagens, anexos e endereços são excluídos em cerca de 24 horas, e o botão Excluir permite remover as coisas antes.
A retenção curta serve a dois propósitos ao mesmo tempo. Protege a privacidade e também é uma necessidade de capacidade: as caixas descartáveis recebem muito e-mail de marketing, e guardá-lo por muito tempo não serviria a ninguém. Nossa política de privacidade e a página de metodologia tratam do manuseio de dados com mais detalhes.
Repare no que a exclusão não alcança. A Bright Parcel ainda tem o endereço na sua tabela de clientes, e seus registros ainda mostram que a mensagem foi «entregue». O que se foi é só a cópia do lado da caixa de entrada.
O caminho inteiro em uma tabela
| Etapa | Componente | Protocolo ou mecanismo | Porta ou formato típico |
|---|---|---|---|
| Composição | Aplicativo ou cliente de e-mail | Mensagem RFC 5322, MIME | Texto com cabeçalhos e partes |
| Submissão | Serviço de e-mail do remetente | Submissão SMTP ou API de envio | 587 ou 465 |
| Consulta de roteamento | Resolvedor DNS | Consultas MX, depois A ou AAAA | DNS, porta 53 |
| Retransmissão | Do servidor do remetente ao MX do destinatário | SMTP com STARTTLS oportunista | 25 |
| Recepção | Provedor de entrega de e-mail | Aceitação catch-all para os domínios | Respostas 250, 4xx, 5xx |
| Repasse | Do provedor ao VookMail | Requisição HTTPS | 443 |
| Processamento | Aplicativo de temp mail | Análise de MIME, limpeza, armazenamento | Banco de dados e armazenamento de arquivos |
| Exibição | Navegador ou aplicativo móvel | Verificação a cada poucos segundos, mais Atualizar manual | HTTPS |
| Expiração | Limpeza programada | Regra de retenção | Cerca de um dia no VookMail |
Onde entram SPF, DKIM e DMARC
Esses três são mencionados em quase toda discussão sobre e-mail, então ajuda ser preciso sobre onde ficam neste caminho. Todos dizem respeito a provar quem enviou uma mensagem. Nenhum deles decide se um endereço temporário pode recebê-la.
O SPF (RFC 7208) é um registro TXT no DNS que lista os servidores autorizados a enviar usando um domínio no remetente do envelope, e os receptores comparam o IP que se conecta com essa lista. O DKIM (RFC 6376) é uma assinatura criptográfica que o domínio remetente acrescenta a cabeçalhos selecionados e ao corpo, verificada com uma chave pública no DNS. O DMARC (RFC 7489) é uma política que diz aos receptores o que fazer quando uma mensagem falha no alinhamento de SPF e DKIM com o domínio do From visível, e para onde enviar relatórios.
Para a nossa mensagem, essas verificações acontecem por volta da Etapa 3. O servidor da Bright Parcel foi conferido com o registro SPF, e a assinatura DKIM pode ser verificada com a chave publicada. O provedor receptor pode usar esses resultados para sinalizar falsificação. O encaminhamento complica um pouco as coisas: uma assinatura DKIM sobrevive enquanto a mensagem não for modificada, enquanto um resultado de SPF diz respeito só ao último servidor que se conectou. Quando a mensagem é retransmitida, o ARC (Authenticated Received Chain, RFC 8617) pode registrar os resultados anteriores. No fim, porém, é o registro MX e a aceitação do receptor que fazem a mensagem ser entregue.
Quando uma mensagem nunca aparece
Cada etapa acima é um lugar onde uma mensagem pode parar. Trabalhar a partir do lado do remetente costuma achar o problema mais rápido.
| Etapa | O que deu errado | O que você vê ou faz |
|---|---|---|
| Antes do envio | Um erro de digitação no endereço | A mensagem foi para outro lugar ou voltou. Use o botão Copiar |
| Saída do remetente | A mensagem está em fila, ou os lotes são lentos | Um ou dois minutos é normal em alguns serviços. Espere |
| Saída do remetente | O site ignora em silêncio os domínios descartáveis | Nada chega. Respeite isso e use um endereço permanente ou um alias ali |
| SMTP | Uma resposta 4xx e uma nova tentativa depois | A mensagem chega após um atraso que pode ser de minutos ou mais |
| SMTP | A mensagem excede o limite de tamanho | Uma rejeição 552 e uma devolução ao remetente |
| Provedor de recebimento | Uma queda ou um problema de DNS | A entrega a todos os domínios pode parar até a resolução |
| Caixa de entrada | O prazo passou, ou o endereço foi excluído | A mensagem chega tarde demais para ser vista |
Lendo uma falha quando você é dono do lado que envia
Se você está testando seu próprio aplicativo, pode ver muito mais do que um usuário, e nosso guia sobre e-mail temporário para desenvolvedores vai além no desenho de testes. Uma ordem sensata de verificações:
- Abra os registros de e-mail do seu aplicativo ou o painel do seu provedor de envio. A mensagem foi aceita, e qual status final ela mostra?
- Procure devoluções ou eventos de webhook que relatem um 5xx do lado do destinatário. O texto depois do código muitas vezes diz o motivo.
- Resolva os registros MX do domínio do destinatário a partir da rede do seu servidor, usando os comandos acima. Um problema de resolvedor ali pode não aparecer em nenhum outro lugar.
- Confirme que o seu domínio de envio tem SPF, DKIM e DMARC configurados, porque alguns receptores tratam com desconfiança as mensagens sem autenticação.
- Envie uma mensagem pequena em texto simples para descartar filtragem por tamanho ou conteúdo.
- Use um nome de usuário distinto por teste, para saber qual execução gerou qual mensagem.
Se uma mensagem chega tarde à caixa de entrada, leia os cabeçalhos Received de baixo para cima. Um intervalo longo entre dois carimbos de hora mostra qual salto a segurou, levando em conta qualquer diferença entre os relógios desses servidores.
Por que ter tantos domínios?
O VookMail deixa você escolher entre mais de 30 domínios. Há razões práticas para isso. Os testadores podem separar projetos ou conjuntos de testes por domínio. Se um domínio tem um problema de DNS ou de entrega, os outros podem continuar funcionando. E há menos dependência de um único nome, o que ajuda quando os sistemas de envio julgam os domínios dos destinatários além dos remetentes.
Vários domínios não são uma ferramenta para driblar sites que recusam endereços descartáveis de propósito. Se um serviço rejeita um domínio de temp mail, ele está sinalizando que quer um contato permanente, e a escolha certa é seu endereço real ou um alias permanente para esse serviço. A recusa pode vir no formulário, por uma lista de domínios ou uma consulta MX como a da Etapa 2, ou mais tarde, quando o remetente se recusa a enviar.
O que o caminho diz sobre segurança
Depois de acompanhar a mensagem, dá para ver exatamente até onde cada proteção alcança.
A criptografia é aplicada salto a salto. O STARTTLS protege cada trecho entre servidores quando os dois lados o aceitam, e muitas vezes é oportunista, de modo que uma conexão pode recuar para texto simples, a menos que uma política como o MTA-STS (RFC 8461) exija o contrário. O HTTPS protege os trechos de repasse e de visualização. Nada disso é criptografia de ponta a ponta: todo sistema que lida com a mensagem pode lê-la.
O acesso é a outra metade. Sem senha, conhecer o endereço é o que dá entrada, então nunca deixe que nada confidencial seja enviado para lá. A retenção curta limita o estrago de qualquer exposição, mas também significa que a caixa não serve como registro. E como o conteúdo não é confiável, phishing e malware podem chegar a esta caixa como a qualquer outra. Uma caixa temporária protege seu endereço real e faz pouco pelo seu dispositivo se você abrir um arquivo ruim. Os usos adequados são privacidade, controle de spam e testes, como definem nossos termos e condições, e as contas importantes pertencem a outro lugar.
Como isso aparece no VookMail
Toda a engrenagem acima já está de pé antes de você chegar. Quando você abre o VookMail, um endereço está pronto. Você pode apertar Novo para digitar um nome de usuário e escolher um domínio, ou usar o botão amarelo «Aleatório» descrito em nosso guia sobre como usar o VookMail. Não há nada para registrar, porque o domínio já aceita todos os nomes. Quando um remetente entrega uma mensagem, o provedor por trás dos registros MX a recebe por SMTP e a repassa por HTTPS, e ela aparece na sua caixa de entrada, com os anexos, na próxima vez que a página verificar. Cerca de um dia depois, ela se foi.
O serviço também está disponível como aplicativo no Google Play e na Huawei AppGallery.
Mais algumas perguntas técnicas
Que porta o e-mail recebido usa?
A entrega entre servidores de e-mail usa SMTP na porta TCP 25. As portas 587 e 465 servem para enviar mensagens ao seu próprio provedor, por isso aparecem na Etapa 1 e não na Etapa 3. É também por isso que uma conexão doméstica que bloqueia a porta 25 em geral ainda consegue enviar pelo seu provedor.
Um serviço de temp mail consegue ver minhas mensagens?
Tecnicamente, sim. A mensagem chega ao serviço de forma legível, porque é assim que ele consegue mostrá-la a você, e o mesmo vale para o provedor de entrega que a trata no caminho. Isso vale também para o e-mail hospedado comum, a menos que o conteúdo seja criptografado de ponta a ponta. É mais um motivo para manter qualquer coisa sensível fora de uma caixa temporária.
Por que o remetente pode achar que uma mensagem foi entregue quando eu não vejo nada?
Porque «entregue» no painel de um remetente se refere à resposta 250 do servidor receptor. Os eventos depois desse ponto, como a etapa de repasse ou uma chegada tardia depois que a caixa foi limpa, são invisíveis para o remetente.
Um remetente poderia perceber que meu endereço é catch-all?
Muitas vezes. Uma ferramenta de verificação pode testar um nome de usuário inventado no domínio e, se o servidor o aceita, o domínio provavelmente é catch-all. Isso por si só não prova que o domínio é descartável, já que muitos domínios comuns de empresas são configurados do mesmo jeito, então essas ferramentas costumam combinar isso com outros sinais.
As respostas à mensagem funcionam?
Respostas do seu lado não são o objetivo do projeto, já que a caixa serve principalmente para receber. Se você precisa de uma troca de mão dupla, uma caixa de entrada comum ou um serviço de alias que aceite respostas é a melhor escolha.
Para saber mais sobre o produto em si, veja nossas Perguntas frequentes. O VookMail faz parte da rede de ferramentas gratuitas PAYATE.