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.

Enquadrar as exceções de e-mail através da XML API

Na automatização, o objeto de exceção MTA chama-se ExceptionPolicy. Antes de efetuar uma alteração, guardar o nome existente, as verificações ignoradas e todos os valores de âmbito. O acesso, a operação de escrita explícita, a avaliação da resposta XML e as repetições seguras são explicados em Proteger o acesso à Sophos Firewall XML API. O enquadramento seguinte descreve o contrato documentado para SFOS 22/23, não um pedido de escrita testado.

Tratar separadamente os parâmetros de omissão e as listas de correspondências

Os campos de verificação em MalwareProtection, SpamProtection e Other selecionam o que é ignorado; não ativam a proteção geral de e-mail. Por exemplo, Malware no objeto de exceção é uma seleção de omissão, não uma ativação do analisador de malware. A referência indica Enable/Disable para a maioria destes campos. Separadamente, os parâmetros também escalares ForTheseSourceHost, ORTheseSenderAddresses e ORTheseRecipientAddresses ativam os grupos de âmbito que são utilizados. Os seus valores também são Enable/Disable, não listas de IP ou de endereços.

No exemplo de objeto documentado, os valores associados encontram-se separados e aninhados:

• SourceHostList/SourceHost: vários valores de cadeia de caracteres para hosts de origem; o texto do parâmetro menciona IP/FQDN.
• SenderAddressesList/Address: vários endereços de remetente, com suporte para carateres universais em endereços de e-mail.
• RecipientAddresses/Address: vários endereços de destinatário, também com suporte para carateres universais em endereços de e-mail.

Os dois campos Address têm o mesmo nome, mas não são intercambiáveis: só o contentor superior determina se se trata do remetente ou do destinatário. Um contentor preenchido não substitui a verificação do parâmetro de âmbito associado. As entradas adicionais nas listas não constituem uma condição E adicional; cada grupo adicional ativado cria a via de correspondência OU descrita acima. Em particular, uma lista adicional de destinatários permitiria que a omissão baseada no host de origem também se aplicasse a mensagens de outras origens. Por isso, comparar sempre os parâmetros e as listas guardadas em conjunto com o âmbito aprovado. A regra especial de BATV e a restrição relativa a FQDNs com carateres universais continuam a aplicar-se.

Segundo a referência, Name é obrigatório e tem um comprimento máximo de 100 carateres. Por outro lado, os campos opcionais e as colunas de valores predefinidos vazias não demonstram que os valores omitidos num Update sejam mantidos ou definidos como Disable. Não copiar o exemplo abrangente do fabricante para uma exceção de produção: este ativa vários campos de omissão e os três grupos de âmbito em simultâneo.

Antes de um pedido de escrita, consultar a API help local: O exemplo apresenta CheckForSPF com Disable, enquanto a tabela de parâmetros indica CheckforSPF com os valores não resolvidos $EMAILPROTECTION{SMTP_CHECK_SPF_ENABLE} e $EMAILPROTECTION{SMTP_CHECK_SPF_DISABLE}. RBL e RDNSAndHelo constam da tabela, mas estão ausentes do exemplo de objeto; a seleção do banner está aí escrita como BanerAddition. Não corrigir estas grafias por iniciativa própria, não adivinhar os valores dos tokens nem deduzir a localização no XML a partir de campos ausentes. Se as etiquetas exatas, os valores permitidos ou a operação concreta para a compilação instalada continuarem por esclarecer, interromper a operação de escrita e esclarecer a questão com o suporte; por esse motivo, esta secção não contém um modelo XML de escrita executável.

Distinguir as respostas e verificar o estado guardado

O mapeamento da referência deve ser lido em conjunto com a operação. Os valores são códigos de estado XML, não códigos de estado HTTP; Message.* são símbolos de documentação não resolvidos, não textos de execução comprovados nem causas de erro que possam ser deduzidas apenas a partir do nome.

Add e Update designam aqui Exception Policy Add e Exception Policy Update, respetivamente. Embora a página também mencione Exception Policy Delete no título, a sua tabela de estados não contém qualquer mapeamento para Delete. Não aplicar a Delete um código de sucesso de Add/Update nem inventar uma regra de validação concreta a partir do nome de um símbolo.

Após cada tentativa de escrita, mesmo com 200, voltar a abrir a exceção em Email > Policies and exceptions e comparar o nome efetivamente guardado, todas as seleções de omissão, os três parâmetros de âmbito e cada lista de hosts/endereços com o estado pretendido. Ao eliminar, verificar a ausência precisamente do objeto previsto e confirmar que o estado das outras exceções permanece inalterado. Guardar o Audit Trail e a resposta completa da API, devidamente expurgada de dados sensíveis. Só depois os testes positivos/negativos descritos acima confirmam o efeito no fluxo de e-mail.

Em caso de 502, erro, tempo limite excedido ou resposta pouco clara, consultar o estado real antes de cada nova tentativa: um nome existente pode já designar outra exceção ou resultar da primeira tentativa. Não duplicar com um novo nome, não acrescentar grupos OU adicionais nem ignorar mais verificações apenas para contornar o erro. Para 541–545, verificar em conjunto a operação, o código, o texto real da resposta e a configuração guardada; uma designação simbólica não resolvida não justifica um pedido de reparação baseado em suposições.

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