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. Escolhe-se a condição fiável mais restrita, pois host de origem, remetente e destinatário são alternativas, não uma condição AND conjunta. 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. Ativar apenas a condição adequada mais restrita em Sources or hosts, Sender addresses ou Recipient addresses.
5. Testar positivamente uma mensagem equivalente e negativamente pelo menos uma variante fora do âmbito.
6. Em Email > Mail logs, comparar resultado e Reason antes e depois; testar separadamente as restantes proteções com casos inofensivos.
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.

Esta exceção pertence ao MTA mode. Uma política SMTP route and scan reúne encaminhamento e ações de spam, malware, ficheiros e dados. Em legacy mode, o SFOS funciona como proxy transparente e usa políticas SMTP malware scan e SMTP spam scan separadas; o objeto de exceção MTA não é o controlo adequado. Ver Configurar o Mail Protection do Sophos Firewall no modo MTA e Configurar o Mail Protection no modo legacy.

Encryption refere-se aqui à encriptação de email da política MTA, por exemplo SPX Email Encryption, não à encriptação de transporte SMTP. Require TLS negotiation, validação do certificado e Skip TLS negotiation são configurados separadamente em Email > General settings > SMTP TLS configuration. Uma exceção de email não corrige, portanto, uma negociação TLS, encaminhamento, relay ou regras de firewall.

Compreender a correspondência antes de guardar

Os três grupos não formam uma condição AND. A API oficial do SFOS 22.0 denomina-os ForTheseSourceHost, ORTheseSenderAddresses e ORTheseRecipientAddresses. Com vários grupos ativos basta corresponder ao host de origem ou remetente ou destinatário. IP, domínio do parceiro e caixa piloto criam três vias de correspondência, não uma combinação mais restrita.

Este objeto não oferece AND entre grupos; duas exceções também ampliariam o âmbito. Se forem necessários dois critérios simultâneos, corrigir a causa ou separar o fluxo com uma política ou caminho de gateway adequado.

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 um objeto de origem publicado e realmente observado no próprio fluxo de email. Se outros clientes partilharem os IPs do fornecedor, mesmo esse objeto pode ser demasiado abrangente. Não se exclui uma verificação de segurança apenas com base nessa rede.

Remetente e destinatário

Para Sender addresses e Recipient addresses, é permitido um endereço como sender@example.net ou uma wildcard como *@example.net. Um segundo grupo não é uma âncora mais restrita, pois liga-se com OR. Um remetente não é prova independente de confiança ao excluir SPF ou DKIM; uma exceção de destinatário aplica-se a mensagens correspondentes de todos os remetentes.

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 da gateway dedicada de um parceiro. 203.0.113.25 é um endereço de documentação a substituir pelo IP público observado em Mail logs. Só é adequado se o IP pertencer exclusivamente à gateway fiável; num relay cloud partilhado o bypass seria demasiado abrangente.

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. Deixar Sender addresses e Recipient addresses desativados ou vazios; acrescentariam correspondências OR.
6. Guardar sem adicionar mais hosts ou verificações.

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

O parceiro volta a enviar a mesma mensagem controlada, que já não deve falhar pelo Reason SPF. Em Email > Mail logs, filtrar por período, remetente, destinatário ou assunto e por Result e Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification e BATV têm filtros Reason. Para aprofundar, usar smtpd_main.log e, em rejeições, smtpd_reject.log; Serviços e logs do Sophos Firewall explica a sua função.

Depois realiza-se um teste negativo por um caminho SMTP controlado não excluído. Não deve ignorar a verificação documentada devido a esta exceção. Numa exceção só de host, outros remetentes ou destinatários pelo mesmo IP não são testes negativos: correspondem ao mesmo ramo OR. Um ficheiro inofensivo pode testar Malware e File Protection separadamente; não se usa malware real.

Uma entrega bem-sucedida não comprova o âmbito. A documentação oficial de Mail logs descreve Reasons e estado de entrega, mas não um campo “matched exception” nem uma lista das verificações ignoradas. Avaliar em conjunto Reason antes/depois, configuração e casos positivos e negativos separados. A entrega não deve ser apresentada como prova de que todas as restantes proteções foram executadas.

Reconhecer exceções de risco

Uma única wildcard de domínio abrangente ou uma grande rede de origem pode remover a proteção de uma parte considerável do fluxo de email. Introduzir ambas não restringe o âmbito, mas acrescenta correspondências OR. Sobretudo as exceções para Malware, Zero-Day Protection, Data protection e File protection exigem uma decisão de risco documentada e um âmbito muito reduzido e fiável por si só. 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

Comparar separadamente os três grupos com o fluxo real. Cada grupo OR ativo aumenta as correspondências. Reduzir a exceção a um grupo fiável com o mínimo de valores e repetir o teste negativo.

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 SMTP 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. Perante um erro TLS, verificar o certificado, Require TLS negotiation e o outro extremo; Encryption na exceção e um âmbito mais amplo não o resolvem.

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.

Antes da alteração, registar nome, verificações, valores do âmbito e Reason anterior. Para preservar o estado, eliminar apenas a nova exceção e deixar políticas e outras exceções intactas. Testar novamente o erro original e uma mensagem de controlo; se a causa persistir, planear primeiro uma janela ou correção 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.
• Preferir um único grupo adequado; grupos adicionais ampliam a correspondência por OR.
• 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, juntamente com os Reasons antes e depois, confirmam o efeito pretendido.
• 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