Criar e testar exceções de email do Sophos Firewall em segurança

Uma exceção de email no Sophos Firewall não se limita a permitir um remetente. Ela ignora verificações de segurança selecionadas para um caminho SMTP definido. É precisamente por isso que pode resolver de forma precisa um falso positivo confirmado, mas também pode desativar silenciosamente o SPF, a análise de malware, o Zero-Day Protection ou as verificações DKIM.

⚠️ Uma exceção só é criada depois de reproduzir um falso positivo. Ignora-se apenas a verificação afetada e o âmbito contém a combinação fiável mais pequena de IP de origem, remetente e destinatário. All checks e wildcards abrangentes não são uma solução rápida padrão.

Criar a exceção em sete passos

1. Registar a hora do teste, o IP de origem SMTP, o remetente do envelope, o destinatário, o assunto, o Message-ID e o motivo exato da rejeição.
2. Verificar se o problema é causado por DNS, encaminhamento, relay, TLS ou pela própria política de email, e não por uma verificação de segurança.
3. Em Email > Policies and exceptions > Add an exception, selecionar apenas a verificação comprovadamente afetada.
4. Definir Sources or hosts, Sender addresses e Recipient addresses da forma mais restrita possível.
5. Testar positivamente uma mensagem equivalente e negativamente pelo menos duas variantes fora do âmbito.
6. Confirmar em Mail logs e nos logs do MTA que apenas a verificação prevista foi ignorada e que as restantes funções de proteção continuam ativas.
7. Documentar o responsável, a justificação e a data de revisão; remover a exceção depois de corrigir a causa.

O que uma exceção realmente ignora

O SFOS agrupa as verificações que podem ser ignoradas pelo seu efeito. Em Spam protection encontram-se RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF e BATV. Malware protection inclui Malware e Zero-day protection. Em Other encontram-se Data protection, File protection, Encryption, Banner addition, DKIM signing e DKIM verification.

Esta seleção não é uma lista de conveniência. Uma exceção para SPF, por exemplo, mantém ativo o restante caminho antispam e antimalware. Uma exceção para Malware ou Zero-day protection, pelo contrário, remove uma verificação de conteúdo central para todas as mensagens que correspondam ao âmbito. Encryption, DKIM signing ou DKIM verification também alteram a confidencialidade e a validação da integridade do fluxo de email de saída ou de entrada.

O caminho geral do MTA continua documentado em Configurar o Mail Protection do Sophos Firewall no modo MTA. Para o proxy transparente, aplica-se Configurar o Mail Protection no modo legacy. Em nenhum dos modos uma exceção substitui encaminhamento, relay, uma regra de firewall ou uma política de análise adequada.

Compreender o âmbito antes de guardar

Sources or hosts

O SFOS aceita como origem endereços IP, intervalos IP, listas IP, redes ou FQDNs. FQDNs com wildcard não são suportados para exceções de hosts de email. Por isso, *.example.net não é um substituto válido para o endereço de origem SMTP observado. Não é necessária uma exceção para localhost, porque o SFOS não analisa emails locais por predefinição.

Em serviços de email na cloud ou gateways distribuídos, um único IP pode ser demasiado restrito, enquanto toda uma rede do fornecedor pode ser demasiado abrangente. Utiliza-se apenas o objeto de origem publicado e realmente observado no próprio fluxo de email. Se o fornecedor alterar as suas redes, a exceção não é expandida cegamente para Any; volta a ser comparada com os logs e as informações do fabricante.

Remetente e destinatário

Para Sender addresses e Recipient addresses, é permitido um endereço individual como sender@example.net ou uma wildcard de domínio como *@example.net. Uma wildcard de domínio abrange todos os remetentes ou destinatários desse domínio e, por isso, precisa de uma âncora oposta mais restrita, como um IP de origem confirmado e um destinatário piloto.

O BATV tem uma regra especial invulgar: para ignorar a verificação BATV dos emails de um remetente, o endereço deve ser introduzido tanto em Sender addresses como em Recipient addresses. Se faltar um dos campos, a exceção está incompleta para esse caso BATV.

Criar uma exceção restrita

O exemplo trata um falso positivo SPF confirmado de um parceiro. 203.0.113.25 é um endereço de documentação e deve ser substituído pelo IP público de origem realmente observado no log SMTP. partner.example e pilot@example.com também são valores de exemplo.

1. Abrir Email > Policies and exceptions > Add an exception.
2. Introduzir um nome rastreável como FP-SPF-partner-example-review-2026-09-30.
3. Selecionar exclusivamente SPF entre as verificações a ignorar.
4. Em Sources or hosts, introduzir o host 203.0.113.25.
5. Em Sender addresses, introduzir *@partner.example e, em Recipient addresses, inicialmente apenas pilot@example.com.
6. Guardar a exceção sem a expandir ainda a outros destinatários.

O nome inclui deliberadamente a causa e a data de revisão. Contudo, não substitui a documentação na alteração ou no ticket. O nome não impõe tecnicamente uma data de expiração; o responsável tem de realizar efetivamente a revisão.

Realizar testes positivos e negativos

Primeiro, o parceiro volta a enviar a mesma mensagem controlada para a caixa de correio piloto. A mensagem tem de percorrer o fluxo de email previsto e deixar de falhar pelo motivo SPF confirmado. Mail logs, smtpd_main.log e, no caso de rejeições, smtpd_reject.log são correlacionados através do carimbo de data/hora, remetente, destinatário e Message-ID. Serviços e logs do Sophos Firewall explica o mapeamento dos logs.

Depois seguem-se dois testes negativos. Uma mensagem do mesmo remetente a partir de outro IP de origem e uma mensagem do IP confirmado para outro destinatário não podem receber a mesma exceção. Além disso, um ficheiro de teste inofensivo continua sujeito ao caminho normal de Malware e File Protection. Não se utiliza malware real.

Uma entrega bem-sucedida, por si só, não comprova o âmbito. O essencial é que a mensagem esperada seja entregue, as variantes fora do âmbito continuem a ser analisadas normalmente e nenhuma segunda verificação de segurança seja ignorada involuntariamente.

Reconhecer exceções de risco

Uma wildcard de domínio abrangente combinada com uma grande rede de origem pode remover a proteção de uma parte considerável do fluxo de email. Sobretudo as exceções para Malware, Zero-Day Protection, Data protection e File protection exigem uma decisão de risco documentada e um âmbito piloto muito reduzido. Perante um erro de análise ainda desconhecido, não se desativa preventivamente todo o grupo.

As opções aparentemente funcionais também são relevantes para a segurança. Ignorar Encryption pode enviar conteúdo confidencial sem proteção. Sem DKIM signing falta a assinatura de saída planeada; sem DKIM verification não é avaliada uma prova de identidade de entrada. Uma exceção de Banner pode remover textos ou marcações obrigatórios. Estas alterações são coordenadas com os responsáveis de email e conformidade.

Restringir erros por sintoma

A mensagem continua a ser rejeitada

Primeiro deve ser avaliada a nova entrada de log, e não a mensagem de teste antiga. O IP de origem real, o remetente do envelope, o destinatário e o Reason têm de corresponder ao âmbito e à verificação selecionada. Um FQDN com wildcard em Sources or hosts não funciona. Se a mensagem for rejeitada devido a RBL, IP reputation, RDNS/HELO ou outra verificação, uma exceção apenas para SPF não resolve esse motivo separado.

A exceção corresponde a demasiadas mensagens

As três camadas do âmbito são comparadas individualmente com o fluxo de email real. Muitas vezes, *@domain sem um IP de origem restrito ou com demasiados destinatários é o fator abrangente. A exceção não é corrigida ignorando mais verificações; é reduzida à combinação confirmada mais pequena e novamente submetida a testes negativos.

O email passa na verificação, mas não é entregue

Uma exceção controla verificações de segurança, não MX, o caminho interno, relay, TLS ou o servidor de email de destino. Mail logs e o spool mostram se, depois da análise, a mensagem ainda falha devido a DNS, encaminhamento, política ou entrega. A exceção não é expandida quando o erro ocorre depois da verificação de segurança.

A exceção BATV não se aplica

Verificar se o mesmo endereço do remetente aparece em Sender addresses e Recipient addresses. Depois, voltar a comparar o Reason BATV específico e os restantes campos do âmbito. Uma segunda exceção mais abrangente não substitui o campo BATV em falta.

Operação e reversão

Cada exceção tem um responsável, um motivo de falso positivo comprovado e uma data de revisão. As alterações são comparadas com o audit trail; Acompanhar alterações de configuração no Sophos Firewall descreve a prova adequada. O fluxo de email real permanece adicionalmente visível em Mail logs e nos ficheiros MTA.

Para a reversão, remove-se a exceção ou restaura-se o estado anterior documentado. Depois, voltam a ser testados o cenário de erro original e uma mensagem de controlo permitida. Se a causa do fabricante ou do DNS ainda não tiver sido corrigida, a reversão não pode causar silenciosamente perda de email de produção; primeiro deve ser planeada uma janela de manutenção ou uma correção alternativa mais restrita.

Lista de verificação

• Estão disponíveis um falso positivo reproduzível e o Reason exato.
• IP de origem, remetente do envelope, destinatário e Message-ID estão documentados.
• Apenas a verificação afetada é ignorada.
• Sources or hosts, Sender e Recipient formam o menor âmbito significativo.
• FQDNs com wildcard não são utilizados como exceções de host.
• Uma exceção BATV contém o endereço do remetente em ambos os campos de endereço.
• Testes positivos e negativos confirmam correspondência e não correspondência.
• As restantes verificações de spam, malware, ficheiros, dados e DKIM permanecem ativas.
• Responsável, justificação, data de revisão e reversão estão documentados.

FAQ