Módulo 3 · 3.3

Apelidos, encaminhamento e captura de erros: úteis, mas com riscos

Módulo 3: Gerir a sua caixa de correio · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Após esta lição, saberá escolher entre uma caixa de correio, um apelido, um encaminhamento e uma captura de erros (catch-all), e explicar porque o encaminhamento para um endereço externo e a captura de erros podem prejudicar a entrega do seu email.

Conceitos-chave: caixa de correio, apelido, forwarder (encaminhamento), encaminhamento interno e externo, SPF quebra com encaminhamento, SRS (Sender Rewriting Scheme), DKIM em encaminhamento, ARC (RFC 8617), captura de erros (catch-all), ataque de dicionário, backscatter, envio em nome de outro endereço

Quatro formas de fazer um endereço funcionar

Se quiser que offerte@example.com funcione, tem quatro opções:

Opção	O que é	Quando é útil
Caixa de correio	Um local de armazenamento próprio com palavra-passe própria. Pode iniciar sessão nele.	Alguém tem de trabalhar diretamente com ele, ou o correio tem de ser guardado à parte.
Apelido	Um segundo nome para uma caixa de correio existente. O correio para `offerte@` chega à caixa de correio de `info@`.	Uma pessoa com vários endereços.
Forwarder (encaminhamento)	O correio para esse endereço é encaminhado para um ou mais outros endereços. Não fica nada guardado.	Um endereço que deve chegar a vários colegas; um endereço antigo que tem de continuar a funcionar.
Catch-all (captura de erros)	Todo o correio para endereços que não existem chega a um único endereço.	Quase nunca (ver abaixo).

Nalguns painéis, um apelido é tecnicamente igual a um encaminhamento para um endereço no mesmo servidor. A diferença que importa é esta: o correio fica no mesmo servidor, ou sai para fora?

Encaminhar dentro do seu próprio domínio: sem problemas

Se encaminhar offerte@example.com para info@example.com, e ambos estiverem no mesmo servidor, o servidor entrega o correio simplesmente na caixa de correio de info@. Nada passa pela internet, nada é verificado de novo. Isto é seguro e fiável.

Encaminhar para fora: onde corre mal

A situação muda quando encaminha para um endereço noutro fornecedor, por exemplo um endereço pessoal no Gmail ou no Outlook.com. Nesse caso, o seu servidor envia o correio novamente, agora para o Gmail. E o Gmail verifica o correio como se viesse do seu servidor.

Suponha que klant@example.net envia um email para info@example.com. O seu servidor encaminha-o para o Gmail. O que vê o Gmail?

Remetente (From): klant@example.net.
Remetente do envelope: continua a ser klant@example.net, a menos que o seu servidor o reescreva.
Servidor de envio: o seu servidor, por exemplo 192.0.2.25.

O Gmail verifica o registo SPF de example.net. O seu servidor, obviamente, não consta lá. O SPF falha. Se example.net tiver uma política DMARC p=reject, e a mensagem não tiver uma assinatura DKIM válida, o Gmail recusa a mensagem. O seu servidor recebe de volta um bounce, que vai para... o remetente original, que agora recebe uma mensagem de erro do seu servidor.

Há três mecanismos que atenuam isto:

1. O DKIM sobrevive (normalmente)

Uma assinatura DKIM (lição 4.3) está incluída na própria mensagem. Se o seu servidor encaminhar a mensagem sem alterações, a assinatura de example.net continua válida. O DMARC passa então pelo DKIM, mesmo que o SPF falhe. É por isso que o DKIM é tão importante: é o único mecanismo que sobrevive ao encaminhamento.

Mas as coisas correm mal se o servidor de encaminhamento alterar a mensagem: acrescentar um texto no fim ("encaminhado por..."), alterar o assunto ([SPAM] antes dele) ou converter a formatação. Nesse caso, a assinatura deixa de corresponder.

2. O SRS reescreve o remetente do envelope

Com o SRS (Sender Rewriting Scheme), o servidor de encaminhamento altera o remetente do envelope para um endereço no seu próprio domínio, por exemplo:

SRS0=HHH=TT=example.net=klant@example.com

Agora o Gmail verifica o registo SPF de example.com, e aí o seu servidor consta de facto. O SPF passa. Se houver um bounce, o seu servidor pode converter o endereço de volta e enviar o bounce para o remetente real.

Atenção: o SRS resolve o SPF, mas não o DMARC. O alinhamento (lição 4.4) compara o domínio do remetente do envelope com o endereço From. Agora temos example.com versus example.net: não alinhados. O DMARC tem, portanto, de continuar a passar pelo DKIM.

3. ARC: uma declaração do intermediário

ARC (Authenticated Received Chain, RFC 8617, experimental) permite que um intermediário registe o que viu: "quando esta mensagem chegou até mim, o SPF, o DKIM e o DMARC passaram". O servidor de encaminhamento assina essa declaração. O destinatário final pode decidir confiar nessa declaração se confiar no intermediário. Grandes destinatários como o Gmail e a Microsoft utilizam o ARC, mas não pode contar com isso: é um favor, não um direito.

E o spam?

Há ainda um problema, e é muitas vezes o maior. O seu filtro de spam não retém tudo. Todo o spam que passa é agora encaminhado pelo seu servidor para o Gmail. Para o Gmail, parece que é o seu servidor que envia spam. Isso prejudica a reputação do seu servidor (e, no caso de alojamento partilhado, a de todos os clientes nesse servidor). Depois, o Gmail passa também a colocar o seu correio verdadeiro mais depressa no spam.

O que é melhor?

Quer ler o seu correio profissional na aplicação Gmail ou Outlook? Adicione a caixa de correio como conta IMAP (módulo 2). A aplicação vai buscar o correio diretamente ao seu servidor. Nada é encaminhado, nada falha, e não sai spam para fora. Se, ainda assim, tiver de encaminhar, configure o filtro de spam de forma rigorosa antes do encaminhamento.

Catch-all: porque quase nunca

Um catch-all (captura de erros) recolhe todo o correio para endereços que não existem. Um erro de digitação como inof@example.com chega assim na mesma. Isto parece prático, mas:

Spam. Os spammers enviam em massa correio para endereços inventados em domínios existentes (a.jansen@, sales2@, xkq7@). Isto chama-se um ataque de dicionário. Sem catch-all, o seu servidor recusa tudo isso de imediato. Com catch-all, tudo chega, muitas vezes centenas por dia.
Deixa de haver mensagem de erro. Quem se enganar no endereço não recebe um bounce e pensa que a mensagem chegou. Sem catch-all, sabe de imediato que o endereço está errado.
O encaminhamento piora a situação. Um catch-all que encaminha para o Gmail envia todo esse spam para o Gmail.
Backscatter. Um servidor que aceita tudo à partida e só depois descobre que um endereço não existe envia um bounce para o remetente (falsificado). Isto chama-se backscatter: mensagens de erro enviadas a pessoas inocentes, e um motivo para entrar numa lista de bloqueio.

Quer apanhar alguns endereços extra, como um erro de digitação frequente ou um endereço antigo? Crie apelidos ou encaminhamentos individuais para isso. Utiliza um endereço próprio por site ou loja online (webshop-x@), para ver quem revende o seu endereço? Crie esse endereço como apelido no momento em que o utilizar.

Enviar a partir de um apelido

Um apelido também pode ser um remetente. Por exemplo, quer responder como offerte@example.com enquanto está autenticado como info@. Isso é possível, mas:

Muitos servidores de correio verificam atualmente qual o endereço de remetente que corresponde a qual sessão. Só pode enviar a partir do seu próprio endereço e dos apelidos ou encaminhamentos que apontam para a sua caixa de correio. Um endereço qualquer diferente é recusado ("account can not send emails from ..."). Isto protege contra utilização indevida.
No seu programa de correio, adicione o apelido como identidade adicional (Thunderbird: Gerir identidades; Apple Mail: endereços adicionais na conta, separados por vírgulas; Outlook: mostrar o campo De e introduzir o endereço).
O SPF, o DKIM e o DMARC funcionam normalmente, desde que o apelido esteja no mesmo domínio e envie através do seu próprio servidor.

Na prática: como se apresenta num painel

No DirectAdmin, cria encaminhamentos em Gerenciamento de e-mail, Encaminhamentos. A captura de erros encontra-se em Recursos Avançados, Capturar e-mails incorretos; aí, "desativar catch-all" é a opção recomendada (o correio para endereços inexistentes é recusado). Se tiver apenas um nome de domínio sem pacote, os encaminhamentos encontram-se em O meu WebOké, em Os meus domínios, Encaminhamentos. Outros painéis (cPanel, Plesk, Microsoft 365, Google Workspace) têm secções semelhantes, por vezes com nomes como "apelidos", "encaminhamento" ou "grupos".

Resumo

Um apelido ou encaminhamento dentro do mesmo servidor é seguro.
Encaminhar para fora quebra o SPF. O SRS restabelece o SPF, mas não o alinhamento do DMARC; apenas uma assinatura DKIM intacta salva a mensagem, e o ARC pode ajudar.
O spam encaminhado prejudica a reputação do seu servidor. É preferível ler o correio externo via IMAP na aplicação.
Um catch-all atrai spam, esconde erros de digitação e pode causar backscatter. Utilize apelidos individuais.
Enviar a partir de um apelido é possível, dentro das regras do seu servidor.

Quiz

Exercício

Exercício O3.3: Inventário dos seus endereços. Elabore uma lista de todos os endereços no seu domínio: caixas de correio, apelidos, encaminhamentos e se há um catch-all ativo. Indique, para cada encaminhamento, se permanece dentro do seu próprio domínio ou se sai para fora (Gmail, Outlook.com, outra empresa). Depois responda: qual o encaminhamento para fora que pode substituir por uma conta IMAP na aplicação, e há algum catch-all ativo que possa ser desativado? Preencha a lista de verificação.

Exercício O3.3: Inventário dos seus endereços

Este exercício faz você mesmo; ninguém o verifica. Assinale o que já fez e marque o exercício como concluído.

Sem catch-all, ou um motivo consciente registado.
Cada redirecionamento externo tem um motivo, ou foi substituído por IMAP na aplicação.
O filtro de spam está ativado antes de qualquer redirecionamento externo.
Os endereços a partir dos quais envio (aliases) estão configurados como identidade no meu programa.

Que endereços tem (caixa de correio, alias, redirecionamento, catch-all) e para onde vão?

Que redirecionamento externo substitui por uma conta IMAP na aplicação? Há um catch-all ativo e pode desligá-lo?

As suas marcações e notas ficam apenas neste navegador; não as enviamos para lado nenhum. Se tiver sessão iniciada, guardamos em Os meus cursos apenas que concluiu o exercício.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores o funcionamento é semelhante.

Cookies na WebOké

Definições de cookies

Necessários

Marketing