Catch-all do domínio: roteamento, revisão e riscos

Você ativa um catch-all do domínio para receber contatos mesmo quando alguém digita saels@ em vez de sales@. Faz sentido. Mas, no conjunto de endereços coberto pelo catch-all, o servidor deixa de rejeitar destinatários desconhecidos e passa a aceitar mensagens para endereços arbitrários, inclusive sondagens automatizadas. Backscatter, loops de respostas automáticas e falhas de entrega no encaminhamento externo são consequências possíveis de uma configuração inadequada. São riscos, não resultados inevitáveis de toda regra catch-all.

Muitos guias param em “ative o catch-all e envie para uma caixa”. É aí que o planejamento começa. Este guia aborda caixas de revisão separadas, roteamento por regex no Postfix, prevenção de loops e problemas de autenticação no encaminhamento. Leia primeiro o guia de configuração do encaminhamento de e-mail se precisar da base. Aqui, o foco é o catch-all do domínio.

O que é um catch-all do domínio?

Um catch-all é uma regra do MTA que aceita mensagens para endereços do domínio que não correspondem a um destinatário conhecido. Essa identificação deve considerar não apenas caixas, mas também aliases, grupos e outros destinatários válidos. Em vez de 550 User Unknown, o servidor pode responder 250 OK à verificação do destinatário e direcionar a mensagem para uma caixa alternativa. A aceitação do destinatário é diferente da aceitação final após DATA. O catch-all altera a rota do destinatário no envelope SMTP, não a autenticação por si só; encaminhamentos adicionais e notificações posteriores podem criar outros riscos.

Envelope e cabeçalho: por que distinguir os dois

Separar duas camadas de e-mail definidas nos padrões ajuda a configurar o catch-all. Isso não explica todo problema, mas evita pressupostos incorretos ao investigar falhas de roteamento e entrega. Uma correção de dois minutos depois de identificar a causa é um exemplo, não um prazo prometido para o diagnóstico.

A RFC 5321 define o envelope SMTP, com os comandos RCPT TO e MAIL FROM trocados durante a transmissão. A RFC 5322 define os cabeçalhos da mensagem, incluindo To: e From:, exibidos pelo cliente de e-mail.

O catch-all associa um destinatário desconhecido do envelope a um destino alternativo e pode manter os cabeçalhos inalterados. O To visível não determina necessariamente o destinatário do envelope. Essa associação não quebra a autenticação por si só. O SPF verifica o IP de envio com base no domínio MAIL FROM ou, quando aplicável, HELO; o DKIM verifica criptograficamente as partes assinadas dos cabeçalhos e do corpo. O DMARC exige pelo menos uma autenticação SPF ou DKIM válida e alinhada com o From visível. Um encaminhamento externo pode afetar o SPF, e alterações nas partes assinadas podem invalidar o DKIM.

A falha no encaminhamento externo

Encaminhar mensagens do catch-all para Gmail ou Outlook.com cria uma nova etapa SMTP. Uma mensagem antes autenticada pode falhar em uma verificação posterior:

1. Remetente original: client@bank.com (IP: 1.2.3.4)
2. Seu servidor aceita typo@yourdomain.com e encaminha para you@gmail.com
3. O Gmail vê uma conexão do IP do seu servidor, com bank.com como domínio do remetente do envelope
4. O SPF falha no exemplo porque o registro SPF de bank.com não autoriza seu IP
5. Se bank.com usar DMARC p=reject e também não houver DKIM válido e alinhado, o destinatário pode rejeitar. Pode haver um erro SMTP ou aviso de falha na entrega

O encaminhamento adicional precisa de verificação própria. SRS (Sender Rewriting Scheme) reescreve o remetente do envelope; o SPF do domínio usado deve autorizar o IP do intermediário. Isso não alinha automaticamente o domínio com o From original. Uma assinatura DKIM válida e alinhada que sobreviva ao encaminhamento pode bastar para o DMARC. O encaminhamento por alias da TrekMail descrito pode gerenciar a reescrita conforme os recursos e as rotas atualmente disponíveis. No modelo Nano descrito, todo envio, inclusive respostas, exige SMTP externo próprio; o envio gerenciado dos planos pagos depende das permissões do plano e da configuração compatível do cliente.

Três riscos de um catch-all do domínio

Entre os riscos importantes estão backscatter com efeitos na reputação, loops de respostas automáticas e falhas de entrega por SPF ou DMARC no encaminhamento externo. Verifique os três antes de alterar a configuração. Resolver apenas um ponto pode criar problemas em outro: uma tarefa prevista para cinco minutos pode levar a uma semana de correções, como exemplo de retrabalho, não como duração inevitável.

1. Backscatter: um risco para a reputação

O backscatter pode ocorrer quando o servidor aceita definitivamente uma mensagem do catch-all com 250 OK, mas o filtro de spam só a considera problemática depois do encerramento da sessão SMTP. Se o servidor gerar um aviso de falha na entrega para MAIL FROM, pode atingir o endereço falsificado de alguém sem relação com a mensagem. Você passa a enviar notificações indesejadas a quem nunca escreveu para você. Isso pode prejudicar a reputação do IP e contribuir para listas de bloqueio; uma inclusão em poucos dias não é inevitável.

Quando possível, rejeite destinatários não aceitos durante a conexão SMTP, antes de aceitar definitivamente a mensagem com 250 OK. Mensagens de catch-all aceitas deliberadamente podem ser isoladas para revisão. Evite avisos não solicitados a remetentes possivelmente falsificados. Isso não significa desativar todas as notificações legítimas de falha nem descartar silenciosamente mensagens legítimas.

2. Loops de respostas (erro Exchange 5.4.14)

O catch-all direciona destinatários desconhecidos para uma caixa alternativa com resposta de ausência ativada. Um spammer escreve para random@yourdomain.com, e a mensagem chega à caixa. A resposta automática vai para um remetente falsificado e retorna. Se ela voltar a random@yourdomain.com e for processada novamente, pode surgir um loop, dependendo das rotas e proteções. O Exchange pode então informar 550 5.4.14 Hop count exceeded - possible mail loop.

Revise a supressão de respostas automáticas para mensagens do catch-all. X-Auto-Response-Suppress: All é um controle relevante sobretudo no Exchange, não uma garantia universal. O efeito sobre respostas de ausência, confirmações de entrega e confirmações de leitura depende do software que recebe a mensagem. Teste a prevenção de loops e o comportamento real das respostas.

3. Ataques de coleta de endereços (DHA)

Se todo endereço do domínio responde 250 OK, atacantes podem testar automaticamente milhares de combinações, como admin@, hr@, ceo@ e invoice@. Um catch-all global confirma a aceitação SMTP desses endereços, não a existência de caixas reais. Isso pode aumentar o spam e favorecer listas de destinatários apenas aceitos pelo servidor; envios direcionados poderiam continuar por anos, sem que essa duração seja inevitável.

Padrões específicos de endereço, em vez de um catch-all global, podem limitar o conjunto de mensagens aceitas. A Estratégia 2 explica essa abordagem.

Estratégia 1: uma caixa separada para revisão

Se precisar de catch-all, use uma caixa separada para revisar mensagens de destinatários desconhecidos. Essa separação não cria um ambiente isolado de segurança. Restrinja os acessos, mantenha os filtros e desative encaminhamentos, respostas de ausência e outras ações automáticas não autorizadas. Confira as opções da caixa e as regras do servidor: o cabeçalho de supressão não substitui esses controles. Planeje também a capacidade e a retenção.

A lógica da configuração:

1. Aceitar: o servidor aceita *@domain.com no conjunto previsto pelo catch-all
2. Identificar: o destinatário não corresponde a uma caixa, alias, grupo ou outro destinatário válido
3. Separar: direcionar para uma caixa compartilhada específica, como catchall_sink@domain.com
4. Suprimir respostas: em um ambiente Microsoft adequado, avaliar se é apropriado solicitar com Spam Confidence Level 9 o tratamento de spam de alta probabilidade e aplicar X-Auto-Response-Suppress: All quando compatível; verificar as ações efetivas

Revise a caixa, por exemplo, semanalmente. Após a análise, mensagens legítimas são movidas para o destino correto; as demais ficam isoladas conforme sua política de revisão e retenção. Planeje limites de armazenamento, responsabilidade e frequência de revisão. Essa é uma arquitetura possível para reduzir riscos, não a única configuração aceitável nem uma proteção incondicional de reputação.

Regra de transporte no Microsoft 365 / Exchange Online

A configuração abaixo é um exemplo conceitual, não uma mudança padrão para todo tenant M365. O tipo Internal Relay desativa o Directory Based Edge Blocking (DBEB), mas não implementa um catch-all por si só nem é adequado quando todos os destinatários estão no serviço em nuvem. Para os demais, é necessário um conector verificado para um servidor de e-mail próprio autorizado. Um administrador autorizado deve conferir destinos e prevenção de loops. A associação a um grupo não substitui um inventário completo de caixas, aliases e outros destinatários válidos. Uma possível regra de transporte considera:

Planeje e teste a regra de transporte antes de mudar para Internal Relay. Ordem, validade e comportamento de aceitação dependem da configuração concreta. Garanta que rotas e controles permaneçam ativos durante a mudança, em vez de relaxar a validação sem revisão.

Estratégia 2: padrões específicos com Postfix PCRE

Padrões específicos capturam determinados endereços sem abrir o domínio para qualquer destinatário. Você define expressões regulares para as variantes esperadas. A rejeição efetiva dos endereços que não correspondem aos padrões também depende da validação de destinatários, da classe do domínio e de outros mapas. A abordagem pode reduzir os endereços aceitos nas sondagens, mas não garante bloquear uma proporção específica dos ataques.

No Postfix, você pode usar um mapa de aliases virtuais com PCRE (Perl Compatible Regular Expression). Antes de recarregar, confirme que o suporte a PCRE está instalado e teste o mapa com correspondências desejadas e indesejadas. Os comentários do exemplo não garantem rejeição SMTP nem cobertura de todas as grafias mencionadas:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

A integração é definida em /etc/postfix/main.cf. Atenção: substituir a configuração pela atribuição abaixo pode remover mapas de aliases existentes. Faça backup, combine o novo mapa com os anteriores e verifique ordem, padrões e validação de destinatários:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Depois de uma mudança autorizada e da validação da configuração, você pode recarregar: postfix reload

Para ampliar a cobertura, adicione padrões conservadores para endereços comuns em vez de um catch-all global:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

Assim, você captura variantes selecionadas e limita a aceitação de endereços arbitrários, desde que os demais controles de validação de destinatários estejam configurados de forma adequada.

Quando um catch-all do domínio faz sentido

O catch-all serve a tarefas específicas e bem delimitadas. Os três exemplos abaixo costumam ser temporários; também existem outros usos justificados com controles adequados. Já um catch-all permanente e sem planejamento não é uma boa solução padrão.

Usos adequados:

• Endereços de campanhas de curta duração: você usa promo-jan@, promo-feb@ e promo-mar@ e não quer criar cada endereço manualmente
• Entrada de novos clientes: receber mensagens antes de concluir a configuração formal dos endereços
• Migração de sistema legado: a lista completa de endereços ativos ainda não está disponível, e você quer reduzir perdas durante a mudança

Nesses três exemplos, o catch-all deve ter duração limitada. Ao conhecer os endereços válidos, crie caixas ou aliases adequados e avalie se pode desativá-lo. Se precisa escolher entre alias e caixa completa, leia a comparação entre alias do domínio e caixa de e-mail. As diferenças operacionais importam.

Justificativa inadequada: usar catch-all apenas porque você não quer pagar $6 por usuário ao mês por três aliases. Aliases, porém, não exigem licenças próprias de usuário em todo provedor. Verifique primeiro as condições reais do plano. Esconder um problema de preço com roteamento desnecessariamente complexo pode gerar mais trabalho do que benefício após seis meses.

TrekMail: configuração planejada em vez de improvisos

A cobrança por usuário pode influenciar a escolha de um catch-all. O modelo TrekMail descrito usa armazenamento compartilhado no nível da conta, sujeito também aos limites aplicáveis a cada caixa, e planos de preço fixo. Isso não equivale a uma cobrança universal por domínio. Verifique preços, cotas e recursos atuais. Um plano adequado pode reduzir o incentivo financeiro para usar catch-all como substituto de aliases explícitos.

O plano TrekMail Starter descrito começa em $3.50 por mês. Verifique preços, limites e recursos atuais antes de criar os endereços de que precisa, em vez de separar todas as mensagens por catch-all. Se precisar de catch-all e o plano oferecer suporte, configure-o nas opções do domínio e combine com destinatários reais para os endereços usados ativamente. Está começando do zero? O guia de configuração de e-mail no seu domínio aborda DNS, SPF, DKIM, DMARC e caixas em uma sequência adequada.

Lista de verificação antes de ativar o catch-all

Antes da ativação, confira todos os itens. Lacunas podem gerar retrabalho; o impacto depende da configuração e das mensagens recebidas:

1. Validação SMTP de destinatários ativa: rejeitar endereços desconhecidos fora dos padrões catch-all aceitos deliberadamente durante a conexão SMTP. Evitar notificações não solicitadas a remetentes possivelmente falsificados.
2. Respostas automáticas controladas: aplicar X-Auto-Response-Suppress: All às mensagens adequadas quando houver suporte. Testar respostas de ausência e prevenção de loops; o cabeçalho sozinho não é garantia.
3. Caixa de revisão pronta: caixa própria para catch-all, separada da rotina, com limites de capacidade e uma pessoa responsável.
4. Classificação de spam revisada: classificar destinatários desconhecidos com cautela e revisar deliberadamente conforme a política. Não descartar silenciosamente mensagens legítimas por padrão.
5. SPF e DMARC verificados: no encaminhamento, conferir SRS e a autorização do IP real de envio para o domínio reescrito. O DMARC precisa de pelo menos uma autenticação SPF ou DKIM válida e alinhada; as políticas do destinatário também devem ser consideradas.
6. Padrões PCRE específicos preferidos: usar padrões parciais quando o MTA suportar regex. Não aceitar endereços arbitrários sem necessidade comercial; testar os demais controles de destinatários.
7. Avisos de falha na entrega controlados: impedir backscatter para remetentes falsificados sem desativar todas as notificações legítimas. Tratar mensagens aceitas conforme a política de revisão e retenção.

Conclusão

Um catch-all do domínio é uma ferramenta legítima quando o roteamento, a caixa de revisão, a validação SMTP, as respostas e as notificações são planejados. Ativá-lo sem controles pode criar backscatter, loops e problemas de autenticação no encaminhamento externo. Esses riscos podem ser verificados, mas nem todo uso falha inevitavelmente em poucas semanas. Configure o catch-all de forma deliberada ou não o ative.

Se usa catch-all apenas para evitar cobrança por usuário, revise primeiro o modelo de custo. A hospedagem de preço fixo TrekMail descrita pode permitir as caixas e aliases necessários dentro dos limites do plano. O catch-all passa a ser uma escolha consciente, não um improviso. Inicie uma avaliação gratuita, confira as condições atuais e planeje sua configuração com cuidado desde o início.