Configurar Sophos Firewall Mail Protection em modo MTA

Em MTA mode, a Sophos Firewall aceita os emails, analisa-os e entrega-os ao servidor de correio interno ou ao mail hop seguinte. O mailflow só funciona quando o registo MX, a regra MTA automática, a SMTP route and scan Policy, o relay, TLS e a verificação de destinatários estão coordenados.

A configuração tem seis passos: definir o mailflow e o caminho de fallback, ativar MTA mode, adicionar o domínio, criar a route and scan Policy, proteger o relay e alterar o registo MX. Depois, validam-se os fluxos de entrada e saída com comandos externos, quarentena, spool e logs.

Quando utilizar MTA mode

Mail Protection na firewall é sobretudo adequada a ambientes on-premises e híbridos planeados, nos quais é necessário proteger um Exchange local ou outro servidor de correio. Para Microsoft 365, Google Workspace e muitos ambientes exclusivamente cloud, Sophos Email ou outro gateway de email cloud é normalmente uma arquitetura mais clara. Dois gateways em sequência complicam quarentena, headers, TLS, SPF/DKIM/DMARC e troubleshooting.

Se o Exchange Online tiver de utilizar deliberadamente o MTA da firewall, Configurar o Sophos Firewall MTA com o Microsoft 365 explica todo o caminho EOP, relay, conector, MX e SPF.

É necessário distinguir três funções da Sophos Firewall:

• MTA mode: a firewall aceita, analisa e encaminha o email.
• Legacy mode: processamento proxy transparente de um caminho SMTP existente. Configurar o Mail Protection em Legacy mode explica NAT, regras, políticas de análise e validação.
• SMTP Relay em Device Access: controla as zonas a partir das quais o MTA está acessível. O email recebido da Internet requer WAN; o relay de saída é ainda limitado a servidores internos específicos.

A receção de mensagens existentes através de POP3 ou IMAP é uma tarefa separada. Analisar e testar POP3 e IMAP na Sophos Firewall aborda confiança TLS, política opcional, regra de firewall e teste de aceitação.

São necessários uma licença Email Protection válida, routing e DNS funcionais, um IP público conhecido, o servidor interno com a porta de destino e estratégias definidas de TLS, quarentena e fallback. Segundo a visão geral atual da Sophos, MTA mode não está disponível em XGS 87/87w e XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation e SXL2 Live Protection requerem acesso à Internet. Routing de email, análise de malware, filtragem MIME e SPX podem continuar a funcionar com a licença adequada num ambiente airgap, mas um MTA ativo não significa que todos os controlos de proteção estejam disponíveis.

Configurar MTA mode de ponta a ponta

1. Definir o mailflow e o caminho de fallback

No fluxo de entrada, o registo MX público aponta para o endereço em que a Sophos Firewall aceita TCP 25. A firewall analisa a mensagem e entrega-a ao servidor interno. Uma regra DNAT antiga não pode deixar esse servidor diretamente acessível da Internet sem análise, pois permitiria contornar o MTA. Publicar um servidor com DNAT explica a lógica geral de DNAT.

No fluxo de saída, apenas o servidor previsto envia através da firewall. O caminho, smarthost, PTR/rDNS, HELO, SPF, DKIM e DMARC devem corresponder à identidade pública do remetente. Uma regra geral LAN to WAN é demasiado ampla; a base de regras deve identificar claramente o remetente SMTP autorizado. Compreender as regras da Sophos Firewall aborda a ordem das regras.

Antes da migração, documentar:

• registo MX atual, prioridade e TTL;
• novo endereço público da firewall e servidor de destino interno;
• regras DNAT e SMTP existentes e conectores do servidor;
• remetentes de teste de entrada e saída;
• MX ou caminho de correio anterior como fallback;
• monitorização da fila do servidor, spool da firewall e quarentena.

Reduzir o TTL antecipadamente se puder ser necessário um rollback rápido. As alterações ao MX de produção pertencem a uma janela de manutenção.

2. Configurar MTA mode e as definições SMTP básicas

Em Email > General settings, selecionar Switch to MTA mode se necessário. A Sophos Firewall cria a regra Any-to-Any Auto added firewall policy for MTA para SMTP e SMTPS. Não editar esta regra e mantê-la no topo da lista. A mudança para Legacy mode elimina-a; o regresso a MTA mode volta a criá-la.

Configurar as definições básicas:

1. Em SMTP hostname, introduzir o domínio, por exemplo example.com, e não o hostname do servidor interno. O valor aparece em HELO e no banner SMTP das notificações geradas pelo sistema.

   Verificar a resposta da API XML: A documentação do SFOS 23 indica o estado 506 com Message.AVGeneralConfInvalidSmtpNtfyHostname para a operação Email Configuration da API XML. Trata-se de um estado da operação, não de um código de estado HTTP. A chave não está resolvida e não constitui uma mensagem de erro em inglês; não permite deduzir regras de validação específicas. Se surgir esta resposta, verificar o valor do hostname enviado para as notificações, a resposta real da operação e a configuração guardada antes de considerar a alteração bem-sucedida. A linha adicional na documentação não prova que este comportamento em execução tenha sido introduzido pela primeira vez no SFOS 23.

2. Ativar Reject based on IP reputation para rejeitar remetentes com má reputação.

3. Em SMTP TLS configuration, escolher um certificado publicamente fidedigno e permitir Allow invalid certificate apenas em exceções documentadas.

4. Ativar Disable legacy TLS protocols, salvo necessidade documentada de sistemas antigos. A opção desativa protocolos anteriores a TLS 1.1, mas não impõe automaticamente apenas versões TLS atuais.

5. Ativar Scan outgoing mails se as mensagens de saída também forem analisadas.

Utilizar Require TLS negotiation com cuidado: se o SFOS não conseguir estabelecer o TLS exigido, elimina email para o destino afetado ou proveniente do domínio remetente configurado. A ajuda do SFOS 22/23 avisa que a ligação e validação SMTP TLS utilizam o IP do domínio em vez do nome; vários domínios no mesmo IP podem causar erros de certificado. É um aviso documental, não uma prova do algoritmo de correspondência de certificados no build implementado.

Skip TLS negotiation seleciona hosts de correio remotos ou redes para ligações SMTP não encriptadas; o limite documentado é de 512 entradas de host. Não é uma solução para um certificado incorreto. Allow invalid certificate é uma exceção à validação do par TLS, não uma mudança para texto simples. Não presumir precedência se as listas Require e Skip se sobrepuserem, nem fallback para texto simples após falhar o TLS obrigatório. Limitar e documentar as exceções e verificar o resultado real da ligação e do certificado no build implementado antes de as alterar.

Definir os limites SMTP globais antes das políticas

As definições em Email > General settings aplicam-se a todos os emails e são processadas antes das políticas SMTP e POP-IMAP. Por isso, Reject based on IP reputation não é uma ação de uma política individual: o SFOS verifica o IP do remetente antes das verificações de spam da política SMTP. Blocked senders também é global, mas só bloqueia emails recebidos.

Em SMTP settings, Don’t scan emails greater than define o tamanho máximo das mensagens para a análise SMTP global. 0 significa 51,200 KB, e não ilimitado. Para mensagens maiores estão disponíveis Accept, Reject e Drop. Accept entrega sem analisar, Reject recusa e informa o remetente e Drop elimina sem notificação. Esta escolha é documentada como uma lacuna de análise ou decisão de entrega deliberada e testada com uma mensagem imediatamente acima e abaixo do limite.

Os SMTP DoS settings limitam ligações simultâneas, emails por ligação, destinatários por email e taxas de emails e ligações. O SFOS define as ligações máximas com base na RAM e no processador. Os valores predefinidos documentados são 1000 emails por ligação e 100 destinatários por mensagem. Os valores próprios são derivados do volume real de email; um limite demasiado baixo pode tratar listas de distribuição ou scanners legítimos como um ataque.

Em Advanced SMTP settings, o SFOS pode rejeitar um HELO inválido ou RDNS em falta e, com Do strict RDNS checks, um nome de host que não resolva de volta para o IP de origem. Estas verificações não são introduzidas juntamente com uma exceção abrangente. Primeiro registam-se no log os caminhos reais de parceiros, newsletters e aplicações e depois testam-se individualmente.

Um banner de saída pode usar Inline, no conversion, a opção MIME part ou Off. A análise SMTP ou SMTPS deve estar ativa na regra de firewall correspondente. Como um banner altera o body e pode invalidar uma assinatura DKIM existente, a assinatura é aplicada depois desta alteração ou confirma-se expressamente no destinatário que a assinatura planeada continua válida.

Antes de uma atualização, registar também os limites de taxa SMTP. Os intervalos documentados são 1–1000 emails por ligação, 1–512 destinatários por email, 1–1000 emails por host por minuto e 1–100 ligações por host por segundo. As taxas predefinidas são, respetivamente, 1000 e 100. Durante a migração, o SFOS mantém as taxas de email e ligações suportadas, mas repõe o valor predefinido quando excedem o máximo. Comparar os valores guardados após a atualização, não apenas a antiga configuração exportada.

3. Adicionar o domínio como Address Group

1. Abrir Email > Address group > Add.
2. Definir Group type como Email address/domain e Type como Manual.
3. Adicionar o domínio protegido, por exemplo example.com.
4. Guardar o grupo.

Ao criar o grupo, introduzir também um Name claro antes de guardar. Para um grupo existente, utilizar Edit em Email > Address group; iniciar a importação de um ficheiro com Import. RBL (IPv4) aceita endereços IPv4 e RBL (IPv6) endereços IPv6. Email address/domain suporta entradas manuais ou importação CSV/texto. A correspondência RBL utiliza o IP de ligação e a ação especificada na policy SMTP; o comportamento de rejeição SPF/RBL documentado separadamente continua a aplicar-se. Manter os nomes predefinidos Premium RBL services e Standard RBL services, salvo alteração explicitamente planeada.

As Address Groups não se limitam a domínios de email. Group type pode ser Email address/domain, RBL IPv4 ou RBL IPv6. O mesmo endereço pode pertencer a vários grupos, permitindo criar destinos de policy separados sem copiar ou renomear a entrada.

Para listas maiores, o SFOS pode importar um ficheiro CSV ou de texto com até 400 endereços ou domínios. As entradas inválidas e duplicadas são ignoradas. Após a importação, verificar o número de entradas e alguns exemplos antes de atribuir o grupo a uma policy de produção.

As novas SMTP route and scan Policies são planeadas para domínios, não para endereços individuais. Endereços migrados podem continuar ativos, mas não podem ser adicionados ou editados nas policies atuais.

4. Criar uma SMTP route and scan Policy

Abrir Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Introduzir um nome claro, por exemplo Inbound example.com to Exchange.
2. Em Protected domain, selecionar a Address Group.
3. Escolher Route by:
   • Static host: IP fixo do servidor interno; em caso de falha, a firewall tenta o host seguinte.
   • DNS host: nome DNS como mailserver.example.com; vários registos A são usados entre entregas e servidores indisponíveis são ignorados.
   • MX: entrega baseada num registo MX.
4. Para Static host, selecionar o servidor em Host list. Se necessário, criar o IP host em Hosts and services > IP host.
5. Definir Global action como Accept para os domínios que se pretende proteger. Reject rejeitaria todas as mensagens de entrada e saída relacionadas com esses domínios e informaria o remetente.
6. Ativar Spam protection e Malware protection conforme o conceito operacional.
7. Ativar File protection e Data protection apenas depois de compreender o impacto em anexos, mensagens grandes, SPX e DKIM.
8. Guardar a policy.

Para uma política SMTP route and scan existente, abrir Email > Policies and exceptions, selecionar Edit na política em causa, alterar as definições necessárias e guardar a política. Em seguida, voltar a verificar a correspondência da política e a entrega com uma mensagem controlada.

Com Route by MX, o MX resolvido pela firewall não pode apontar para a mesma firewall, caso contrário cria um loop de routing. A firewall tem de resolver corretamente destinos internos; para split DNS são úteis as DNS Request Routes.

Route inbound mail through gateway só é necessária em designs especiais, como servidores na zona WAN, aplicação da regra original a destinos LAN/DMZ ou escolha de gateway com várias ligações. Não a ativar sem uma necessidade concreta de routing.

5. Proteger o acesso de entrada e o relay de saída

Em Administration > Device access, permitir SMTP Relay de todas as zonas que precisam de alcançar o MTA. O email da Internet requer WAN; o email de saída requer também a zona do servidor interno, normalmente LAN ou DMZ. Depois, em Email > Relay settings > Host-based relay, limitar o acesso a servidores, scanners ou aplicações específicos.

Permissões amplas de hosts ou redes criam risco de open relay. Impressoras e aplicações que enviam email devem ser documentadas como host objects específicos. Proteger o acesso à Sophos Firewall explica Device Access.

As listas Allow e Block não seguem o princípio de que Block tem sempre prioridade. Se o mesmo host ou a mesma rede aparecer em ambas as listas de Host-based relay ou Upstream host, o SFOS permite o relay. Estas sobreposições são removidas antes da ativação e é executado um teste negativo a partir de uma origem não autorizada.

Um host permitido também não contorna a análise de email. Se o SFOS não conseguir analisar um IP de origem autorizado para host-based relay, rejeita-o. Uma autorização de relay não comprova, portanto, nem a análise correta do conteúdo nem a entrega; ambas são verificadas com uma mensagem real e os logs MTA.

A SMTP route and scan Policy não suporta SMTP AUTH. Para dispositivos, Host-based relay é portanto a opção fiável. Existem Authenticated relay settings separados para utilizadores e grupos; a Sophos indica, porém, que não suportam um standard SMTP Authentication conforme às RFC, pelo que a compatibilidade do cliente deve ser testada. Isto difere da autenticação da firewall num upstream smarthost, para a qual o SFOS suporta PLAIN e LOGIN. Nunca utilizar um IP de interface da própria firewall como smarthost, pois cria um loop de routing.

Se o correio de saída utiliza um smarthost, configurar Email > General settings > Smarthost settings: selecionar Hostname, definir Port (predefinido 25) e, apenas se o servidor o exigir, ativar Authenticate device with smarthost e introduzir as credenciais de forma segura. Isto encaminha o correio de saída através de um MTA intermédio; não autoriza os clientes a utilizar relay pela firewall. Manter os requisitos TLS e a identidade pública final do remetente coerentes com esse salto adicional e registar as definições anteriores para reversão.

Relay upstream e servidores alojados na cloud

Upstream host, em Email > Relay settings, controla que origens SMTP a montante podem entregar correio de entrada; Host-based relay controla os hosts autorizados a utilizar relay de saída. Configurar estes âmbitos separadamente. Se outro gateway recebe primeiro o correio público, incluir as suas redes de origem reais na lista upstream, não o endereço do servidor de destino. Em ambas as secções, as permissões correspondentes prevalecem sobre bloqueios sobrepostos.

Para um servidor alojado na cloud, ativar SMTP Relay na sua zona de origem, normalmente WAN, e limitar o relay de saída baseado em hosts aos endereços de origem reais do servidor. O servidor cloud também deve permitir a ligação de relay prevista com a firewall. Separar o MX público que aponta para a firewall do destino de entrega resolvido pelo SFOS: o procedimento cloud menciona ambos os destinos MX sem explicar a separação DNS. Utilizar um host DNS distinto, um destino estático ou um DNS dividido mantido deliberadamente; Route by MX nunca deve devolver o correio à firewall.

O procedimento cloud também recomenda mudar para Legacy e regressar quando falta a regra automática. Isto elimina e recria a regra e altera o processamento de correio ativo. Não utilizar como reparação improvisada: registar primeiro as policies, filas e caminho de fallback, e investigar com o suporte a regra em falta. Qualquer mudança de modo aprovada deve ocorrer numa janela de manutenção, repetindo os testes de entrada, saída e rejeição de relay.

Os exemplos antigos de cloud e dados financeiros indicam o nome do servidor de saída como SMTP hostname, enquanto a configuração MTA mais recente exige o domínio, não o hostname do servidor. Seguir a indicação mais recente para notificações do sistema; esta definição não estabelece a identidade de todas as mensagens retransmitidas. Da mesma forma, a verificação DKIM de entrada utiliza a chave pública DNS do remetente e não exige criar uma chave de assinatura de saída apenas porque a descrição MTA menciona assinatura e verificação em conjunto.

Várias interfaces WAN ou endereços IP alias

O MTA cria a própria ligação SMTP de saída. Quando existem vários endereços públicos possíveis, uma regra normal de cliente não é suficiente. A Sophos distingue três casos: com uma interface WAN e vários endereços IP alias, cria-se uma regra SNAT com a Translated source pública pretendida. Com várias interfaces WAN e sem alias, cria-se uma rota SD-WAN para SMTP, SMTP(S) e SMTPS_465. Se existirem várias interfaces WAN e endereços alias, combinam-se SNAT e a rota SD-WAN.

A regra SNAT mantém destino e serviço inalterados, utiliza como interface de saída a ligação WAN planeada e traduz para MASQ ou para o IP alias pretendido. A rota SD-WAN utiliza como destino o grupo Internet, os três serviços SMTP e o gateway primário previsto, além de um backup opcional. O backup só é útil se TCP 25 de saída estiver realmente permitido e se esse endereço público também estiver incluído no registo SPF do domínio de email.

Para este procedimento multi-WAN oficial, a Sophos exige a precedência static, vpn, sdwan_policyroute e ativa SD-WAN para tráfego gerado pelo sistema. Executar estes comandos na Device Console (opção 4 do menu CLI), não na Advanced Shell. Ler primeiro ambos os valores iniciais, aplicar as alterações e voltar a verificá-los:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

A route precedence é global e não um interruptor isolado de email. Antes da alteração, documentar todos os percursos static, VPN e SD-WAN sobrepostos e os dois valores lidos. Para reverter, restaurar a ordem anterior completa com system route_precedence set ... e repor system-generate-traffic no estado inicial enable ou disable. Depois, verificar não só os contadores SMTP, mas também o IP de origem realmente utilizado, a entrega, o resultado SPF e a falha do gateway primário. Verificar o routing SD-WAN para tráfego gerado pelo sistema descreve o procedimento geral de segurança e reversão.

Na rota SD-WAN, Route only through specified gateways impede deliberadamente o recurso a outros gateways: se os selecionados estiverem inacessíveis, a firewall descarta o tráfego. Decidir se isto é preferível a um IP de remetente imprevisto e testar essa falha. Selecionar objetos IPv4 ou IPv6 adequados ao caminho de correio realmente publicado; não copiar um grupo Internet IPv4 para um desenho IPv6.

6. Alterar o registo MX

Alterar o MX público para o endereço da firewall apenas quando regra MTA, domínio, policy, relay e caminho interno estiverem prontos. Enviar imediatamente uma mensagem externa de teste e confirmar que aparece em Log Viewer ou Mail logs, é entregue ao servidor interno e chega à caixa de correio.

Se remetentes externos não alcançarem a firewall ou mensagens legítimas forem rejeitadas em massa, restaurar o caminho anterior documentado. As caches DNS impedem que a reversão tenha efeito imediato em todo o lado. Por isso, manter os caminhos antigo e novo operacionais em paralelo e monitorizá-los pelo menos até expirar o TTL anterior mais longo. Se a firewall aceitar mas não entregar, verificar primeiro routing, DNS, TLS, recipient verification e logs do servidor.

Escolher conscientemente as proteções

Ações para spam, malware e dados sensíveis

Para spam de entrada, spam provável e correio em massa, escolher explicitamente a ação: None entrega sem alterações, Warn acrescenta o prefixo de assunto configurado, Quarantine retém a mensagem e Drop descarta sem avisar o remetente. Definir os prefixos de assunto para spam e correio em massa conforme necessário. Estas escolhas não substituem a rejeição separada SPF/RBL.

Para malware, Selected antivirus action oferece None, Drop e Quarantine; configurar Notify sender separadamente. Quarantine unscannable content abrange conteúdo que não pode ser inspecionado, incluindo ficheiros corrompidos, cifrados ou comprimidos, mensagens demasiado grandes e erros internos de análise. Uma entrega concluída não prova que todos os anexos foram analisados. Zero-Day Protection tem o seu próprio tamanho máximo de análise: ficheiros maiores não são analisados por esse serviço. Testar este limite separadamente do tamanho SMTP global e dos limites de descarte de File protection.

Em Data protection, selecionar a Data control list exata, a sua ação e, se aplicável, o SPX template: Accept entrega, Accept with SPX cifra e entrega e Drop descarta sem notificação. Notify sender é uma escolha separada. Uma atribuição SPX ao nível do domínio cifra todo o correio de saída correspondente; utilizar um acionador Data Control se apenas as correspondências com dados financeiros devem ser cifradas. O exemplo de palavra-passe do destinatário utiliza Specified by recipient e retém a mensagem até ao registo da palavra-passe. Configurar conjuntamente template, Reply Portal e registo no runbook SPX ligado, depois testar uma mensagem correspondente e outra não correspondente, em vez de apenas ativar Data protection.

Utilizar tipos de ficheiro próprios e Data Control Lists

No MTA mode, cria-se um tipo de ficheiro próprio em Email > Policies and exceptions > File type > Add a partir de um modelo, de extensões ou de tipos MIME. As extensões são introduzidas sem ponto inicial. Apenas os tipos próprios podem ser editados. Um novo tipo também não é adicionado automaticamente às policies existentes: é necessário abrir a SMTP route and scan Policy específica, adicioná-lo em File protection e voltar a guardar a policy. Um teste positivo com anexo e um teste negativo semelhante confirmam o match melhor do que apenas o nome do objeto.

Em File protection > Block file types, All bloqueia emails com anexos; não significa analisar todos os anexos. None permite anexos nesta definição de filtro de ficheiros, mas não contorna verificações antimalware, antispam, Data Protection ou outras. A ajuda das policies indica que os cabeçalhos MIME selecionados preenchem a MIME whitelist, permitindo esses tipos e bloqueando os restantes. Cabeçalhos MIME e extensões não provam conteúdo inofensivo. Verificar anexos permitidos e bloqueados no build implementado antes de aplicar uma configuração precisa de whitelist.

Uma Data Control List é composta por Content Control Lists, ou CCLs, para tipos de conteúdo definidos, como dados financeiros ou pessoais. Ao criar em Email > Data control list > Add, filtrar as CCLs por Type e Region e selecionar apenas as entradas realmente necessárias. A ação é definida apenas na policy associada. Um match controlado e conteúdo semelhante sem match permitem confirmar que correspondência e ação funcionam em conjunto sem falsos positivos desnecessários.

Spam protection é mais do que a ação aplicada ao spam. Falhas SPF e RBL são rejeitadas diretamente e não seguem as ações normais para spam ou probable spam. Greylisting rejeita temporariamente uma mensagem de forma intencional e exige nova tentativa do servidor remetente.

Para Reject based on BATV, é necessário configurar primeiro um BATV secret comum em Email > General settings > Advanced SMTP settings. Em vários sistemas MX da organização utiliza-se o mesmo secret. O SFOS combina-o com o carimbo de data/hora e o endereço do remetente para criar a assinatura Return-Path, que expira após sete dias. Por isso, um erro BATV é comparado com o secret, a hora do sistema, o caminho do remetente e a idade da assinatura, em vez de ser ocultado com uma exceção abrangente sem prazo.

Recipient verification impede mensagens para destinatários desconhecidos:

• With callout: consulta o servidor de destino. Se estiver temporariamente indisponível, o SFOS aceita destinatários após um período definido em vez de bloquear permanentemente todo o mailflow.
• In Active Directory: verifica por Simple, SSL ou STARTTLS com timeout de 30 segundos. Indicar o servidor AD, Bind DN e Base DN. Bind DN é o nome distinto completo, incluindo o CN da identidade de bind configurada; Base DN é o ponto de partida das pesquisas no diretório. Utilizar valores adequados ao diretório próprio. O exemplo de administrador da ajuda não estabelece a necessidade de privilégios Domain Admin. Escolher um transporte conforme à política de confiança e segurança implementada; a etiqueta SSL ou STARTTLS, por si só, não prova uma validação de certificado bem-sucedida.

Malware Protection pode usar análise antivírus simples ou dupla. Para Zero-Day Protection com análise simples, a Sophos deve ser o motor primário. Sophos Firewall Zero-Day Protection explica limites e decisões de libertação.

Segundo a ajuda das policies SFOS 22/23, Single antivirus seleciona o motor primário apenas para correio de entrada; o de saída utiliza ambos os motores. Dual antivirus analisa primeiro com o motor primário e depois com o secundário. O motor primário, Sophos ou Avira, seleciona-se globalmente em Email > General settings. Escolher Avira desativa Zero-day protection nas policies SMTP com análise antivírus simples; Sophos tem de ser primário para utilizar Zero-Day Protection com uma análise. A ajuda das definições gerais descreve a análise simples como utilizando apenas o motor primário, sem a distinção de direção da tabela de policies. Esta diferença documental não prova quais os motores realmente utilizados: verificar build, policy, direção do correio e estado de proteção antes e depois de uma alteração. Registar as definições anteriores; restaurar a escolha do motor não demonstra a reativação de Zero-day protection.

O limite da política Drop message greater than em File protection não equivale ao comportamento global para mensagens demasiado grandes: neste ponto, as mensagens maiores são eliminadas. O SFOS também verifica conteúdo visível e conteúdo de formatos empacotados como docx, xlsx, pptx, odt, ods, odp e odg. Um teste positivo apenas com um ficheiro de texto não empacotado não comprova, por isso, como a mesma informação é tratada num documento Office.

Com DKIM verification ativado, o SFOS distingue uma divergência de hash, uma assinatura inválida ou uma chave pública indisponível e uma assinatura DKIM em falta. Para cada resultado podem selecionar-se Accept, Quarantine ou Reject. Segundo a Sophos, as mensagens assinadas com DKIM que utilizem RSA-SHA1 ou uma chave fora do intervalo de 1024 a 4096 bits são colocadas em quarentena. Esta verificação de entrada é testada separadamente da assinatura de saída.

Nas mensagens de saída, a ordem de processamento é importante. Encriptação SPX, prefixos do assunto, File ou Data Protection e banners podem alterar header ou body depois de aplicada uma assinatura DKIM. A validação DKIM falha então no destinatário. Deve decidir-se se assina o servidor interno, a Sophos Firewall ou um gateway posterior.

Assinar mensagens enviadas com DKIM na firewall

Se a Sophos Firewall deve assinar as mensagens, adicionar uma assinatura para cada domínio remetente em Email > General settings > DKIM signing > Add. Domain é o FQDN do domínio de email; Key selector é exatamente o seletor que será depois publicado no DNS público. Um nome como fw01 ou zurich facilita a compreensão de futuras rotações de chaves, mas não é uma função de segurança.

O SFOS requer uma chave RSA privada entre 1024 e 2048 bits, colocada entre -----BEGIN RSA PRIVATE KEY----- e -----END RSA PRIVATE KEY-----. Para novas configurações, 2048 bits é a escolha adequada. Não utilizar RSA-SHA1. Segundo a Sophos, a firewall não aceita uma chave de 1024 bits gerada com PuTTYgen, pelo que também aí se devem escolher 2048 bits. A chave privada pertence exclusivamente à firewall e nunca deve aparecer no DNS, em tickets ou em documentação pública.

Depois de guardar, publicar no fornecedor DNS autoritativo o registo TXT DKIM do seletor com a chave pública. Só depois de este registo ser resolvido externamente se envia uma nova mensagem de teste pelo percurso MTA de saída previsto. O header recebido deve conter o seletor e o domínio esperados, e a verificação DKIM no destinatário deve ter sucesso. Se faltar a assinatura, verificar o domínio remetente, a correspondência da policy e Scan outgoing mails. Se a verificação falhar, comparar primeiro o registo DNS, o seletor, a chave utilizada e as alterações posteriores por SPX, banners, File Protection ou Data Protection.

Configurar e testar a encriptação de email SPX explica como o modelo, a prioridade dos acionadores, o modelo de palavra-passe e o Reply Portal funcionam em conjunto.

Automatizar as definições MTA em segurança através da API XML

Nas automações, as definições globais, as Address Groups e as políticas SMTP continuam a ser alvos distintos. Ler primeiro o build, o modo de correio ativo, os valores guardados e as políticas dependentes; preparar uma cópia de segurança e um caminho de reversão específico. Enviar o pedido confirmado, com uma operação explícita, apenas para o alvo necessário. Depois, comparar a resposta da operação, o estado novamente consultado e o teste de mailflow adequado. Mesmo após um erro ou timeout, consultar primeiro se já foi guardada alguma alteração, em vez de repetir cegamente o pedido de escrita. Proteger o acesso à API XML explica o acesso, o armazenamento de secrets e a avaliação das respostas.

As referências de objetos do SFOS 22/23 não são payloads prontos para produção. Os exemplos XML, as tabelas de parâmetros e a ajuda do WebAdmin podem indicar grafias, valores ou predefinições diferentes. Células de predefinição vazias ou Any não confirmam um valor vazio seguro nem o comportamento dos campos omitidos. As constantes $EMAILPROTECTION{…} não resolvidas não são valores literais confirmados da API. Se a sintaxe, a operação ou o efeito não estiverem esclarecidos, parar antes de escrever e consultar a API help do build instalado ou obter um esclarecimento oficial. As diferenças de documentação, por si só, não comprovam uma alteração do produto.

Distinguir as definições globais de SMTP, TLS e relay

Em EmailConfiguration, o limite de análise SMTP e os valores DoS pertencem a SMTPSSettings, e os valores POP/IMAP separados pertencem a POPIMAPSettings. O campo com o mesmo nome, DontScanEmailsGreaterThan, não deve ser associado ao protocolo errado. RecipientHeaders, com elementos Header repetidos, diz respeito à identificação de destinatários POP/IMAP, não ao routing SMTP. Os banners encontram-se em GeneralSettings. Da mesma forma, SMTPTLSConfiguration e POPSIMAPTLSConfiguration são contextos próprios: TLSCertificate, AllowInvalidCertificate e DisableTLS1 não podem ser identificados inequivocamente através de um único nome de campo sem qualificação. Uma exceção SMTP não deve flexibilizar também POP/IMAP inadvertidamente. Depois de guardar, consultar novamente ambos os contextos em separado e testar apenas o percurso de correio previsto.

Segundo a tabela da API, BypassSpamCheck, em SMTPSSettings, permite contornar a análise de spam para tráfego autenticado. A tabela indica a predefinição Disable, mas o exemplo XML define Enable. Não adotar o exemplo como uma configuração predefinida segura: antes de uma alteração, esclarecer que tráfego é considerado autenticado no build em causa e que verificação de spam é contornada. Limitar estritamente o âmbito de uma exceção intencional e verificar o seu efeito em mensagens correspondentes e não correspondentes; não considerar que outras áreas de análise ficam automaticamente excluídas.

A origem dos valores SMTP é importante: a tabela da API indica, para DontScanEmailsGreaterThan, 1024 KB, para MaximumConnections, 5000 no intervalo 1–20000, e para MaximumConnectionsHost, 100 no intervalo 1–10000. Para MaximumEmailsConnection, indica a predefinição 100, mas o exemplo XML apresenta 1000; a ajuda do WebAdmin também indica 1000. MaximumRecepientsEmail é a grafia utilizada na fonte, com a predefinição 100 e o intervalo 1–512. Para EmailsRate e ConnectionsRate, a tabela da API indica as predefinições 1000 e 100, ambas com o intervalo 1–20000; em contrapartida, a ajuda do WebAdmin limita as taxas a 1–1000 por minuto e 1–100 por segundo, respetivamente, e determina os máximos de ligações com base no hardware. Por isso, não adotar os máximos da tabela como limites atuais da interface nem os valores dos exemplos como predefinições. Os limites do WebAdmin descritos acima e a verificação de atualização continuam a ser determinantes para este procedimento; as automações devem comparar os valores efetivamente guardados no build.

Outros conflitos de sintaxe impedem a importação cega dos exemplos: VerifySendersIPReputation apresenta Enable no exemplo XML, mas a tabela da API indica on/off, com a predefinição Disable; nessa tabela, SMTPSDosSettings é descrito como um inteiro com a predefinição Disable, enquanto o exemplo apresenta Enable. Para o banner, os textos do exemplo contrastam com os valores da tabela inline_plain, mimepart, off. Não «corrigir» estas indicações por iniciativa própria; confirmar a grafia e os valores válidos antes de enviar um pedido. Ter em conta, separadamente, a nota existente sobre Email Configuration, estado 506.

AdvancedSMTPSetting também é global. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks e ScanOutboundEmails controlam as verificações HELO/RDNS e de saída explicadas acima. FirewallRelateInboundMails diz respeito ao percurso separado de gateway/regra de firewall; o exemplo indica Disable, e a tabela Turn on/Turn off. Para o secret BATV, o exemplo apresenta BATVSecret, mas a tabela apresenta BATVsecret. Confirmar as maiúsculas/minúsculas e os valores válidos antes de escrever; não apresentar nenhuma destas variantes como um payload testado. Utilizar o secret comum a partir de armazenamento protegido; não copiar o secret do exemplo nem colocar o secret num ticket, repositório ou log de pedidos. Planear a mudança de secret em todos os sistemas MX afetados e verificar depois o BATV e o envio normal.

Em RelaySettings, HostBased e UpstreamHost têm, cada um, listas próprias AllowRelay e BlockRelay. Dentro destas encontram-se HostsOrNetworks e entradas HostsOrNetwork repetidas. Por isso, o mesmo nome de elemento terminal não significa o mesmo âmbito de relay. AuthenticatedRelaySettings contém, separadamente, AuthenticatedRelay e UsersOrGroups com UsersOrGroup. Os grupos abertos ou de convidados apresentados no exemplo do fabricante não são uma escolha segura. Utilizar apenas as identidades e os objetos de host planeados, eliminar sobreposições entre as listas e verificar depois o envio permitido e o relay não autorizado a partir de uma origem separada.

Em SmarthostSettings, UseSmarthost ativa o salto intermédio de saída; SmarthostList, com elementos Hostname repetidos, seleciona os destinos, e Port a porta de destino. A tabela da API indica 1–65535, mas não uma porta predefinida; 25 aparece no exemplo e como predefinição na ajuda do WebAdmin. AuthenticateDevicewithSmarthost é separado: fornecer Username e Password de forma segura apenas quando for necessária autenticação. A tabela da API indica Disable como predefinição para ambos os controlos de ativação, enquanto o exemplo ativa ambos. passwordform="encrypt" é a sintaxe de palavra-passe do exemplo, não uma autorização para reutilizar valores cifrados de outra firewall. Se a origem ou os requisitos de importação não estiverem esclarecidos, interromper o pedido. Em seguida, verificar o destino, TLS, a autenticação e a entrega através deste salto, não apenas a autorização de relay.

Alterar Address Groups e políticas SMTP de forma seletiva

Para o MTA, está previsto o objeto de exemplo MTAAddressGroup, não o objeto de nome semelhante AVASAddressGroup do outro contexto de correio. Name identifica o grupo. GroupType determina a lista adequada: a tabela da API distingue RBLIPv4, RBLIPv6, IPAddress e EmailAddressOrDomain, bem como os campos de entrada RBLName, IPAddressNetwork e EmailAddressDomain. O exemplo de domínio de correio utiliza EmailAddressList, com elementos EmailAddressDomain repetidos e EmailImportType definido como Manual. Para Import e EmailAddressFile, esclarecer o método de upload de ficheiro adequado ao build: o texto descritivo associa contraditoriamente o campo de ficheiro à importação manual. Um sucesso HTTP não confirma todas as entradas importadas nem a composição final do grupo. Consultar o número de entradas, as entradas omitidas e os valores concretos dos domínios antes de uma política utilizar o grupo.

Para Delete Address Group, as páginas do SFOS 22/23 apresentam linhas de estado, mas não uma definição de parâmetros nem um exemplo de eliminação. Estas informações não permitem deduzir a identidade exata do objeto para Remove nem um pedido funcional. Não inserir simplesmente Name ou o objeto de criação num payload Remove. Verificar primeiro as utilizações nas configurações de correio, spam e arquivo; obter a operação exata e o seu pedido completo na API help instalada ou através de esclarecimento oficial. Até lá, não executar eliminações automáticas. Após uma eliminação aprovada, verificar novamente se foi removido exatamente o grupo pretendido e se as referências necessárias e o mailflow permanecem intactos.

Em SMTPPolicy, Name é a identidade da política; DomainList, com DomainName, associa os domínios protegidos. RouteBy, DNSHostName e RouteList, com HostName, routingid e routingorder, descrevem diferentes percursos de entrega, não nomes de domínio adicionais. A tabela da API indica MX como predefinição de routing, mas o exemplo contém textos de rotas alternativas em vez de um único valor. Verificar previamente o routing face à resolução DNS real, para evitar um loop de retorno à firewall.

As secções aninhadas SpamProtection, MalwareProtection, FiletypeFilter e DataProtection têm campos de estado independentes. A tabela da API indica OFF como predefinição, embora o exemplo os defina como ON. Por isso, uma ação global Accept não ativa automaticamente todas as verificações. Da mesma forma, o campo SPX do domínio SPXEncryption e o campo relativo a correspondências DataProtectionSPXTemplate não são intercambiáveis; DataProtectionPolicy tem de referenciar uma Data Control List existente e adequada. Verificar previamente os requisitos dos motores, de Zero-Day e de BATV, bem como o modelo de palavra-passe SPX. A tabela descreve a verificação de destinatários como sendo de saída, e a ajuda do WebAdmin como sendo de entrada; não deduzir daí uma nova direção de verificação. Os testes positivos/negativos por direção e os valores guardados da política determinam se o conceito de proteção planeado está implementado.

Para a Data Control List, o exemplo XML apresenta MTADataControlList, contendo Name e Signatures, com elementos Signature repetidos. As etiquetas da tabela name e signaturename não constituem uma instrução confirmada para as serializar como tags XML em minúsculas. Confirmar previamente MTA Mode, consultar as assinaturas disponíveis e selecionar apenas CCLs adequadas. A lista, por si só, não cria uma ação de proteção: só a associação através de DataProtectionPolicy e a ação na política SMTP implementam o conceito. Em seguida, consultar novamente a lista e a associação e testar uma correspondência controlada e um caso semelhante sem correspondência.

Não confundir DKIM e exceções com routing

Em DKIMVerification, o campo VerifactionStatus, escrito efetivamente assim no exemplo, controla a ativação. ActionForVerifactionFail é um seletor diferente de ActionForSignatureInvalid ou ActionForSignatureNotFound: o primeiro diz respeito a erros de verificação de hash/assinatura, o segundo a uma chave pública DNS em falta ou sintaticamente inválida, e o terceiro a uma assinatura em falta. Não corrigir silenciosamente os erros ortográficos das duas primeiras tags. O exemplo XML indica Pass, enquanto a tabela de parâmetros e a ajuda do WebAdmin indicam Accept, além de Quarantine e Reject. Isto não confirma que os valores da API sejam intercambiáveis; esclarecer o contrato do build antes de enviar um pedido e testar separadamente os três casos de entrada.

Em DKIMSigning, Domain identifica o domínio de assinatura, não Name; a referência de eliminação também exige Domain. Na criação e na alteração, KeySelector e PrivateRSAKey são campos obrigatórios. Segundo a ajuda do WebAdmin, um domínio pode ter várias assinaturas, enquanto a referência de eliminação apenas indica o domínio: se existirem vários seletores, esclarecer previamente o âmbito exato da eliminação, sem concluir que esta se limita a um seletor. Guardar as chaves privadas e as credenciais da API de forma protegida e removê-las das respostas e dos logs; depois, verificar o DNS e a nova assinatura recebida conforme descrito acima.

A lista global de entrada utiliza MtaBlockedSenders, com BlockedEmailAddresses e elementos EmailAddress repetidos; a tabela da API permite endereços individuais ou domínios com wildcard, como *@example.com. Esta lista não substitui uma política antispam completa e, no contexto MTA aqui descrito, aplica-se apenas a mensagens de entrada. Antes de uma alteração, consultar o âmbito e as entradas existentes; depois, testar um remetente correspondente e outro não correspondente.

Separadamente, a API descreve AntiSpamTrustedDomain, com DomainList e elementos DomainName repetidos, como uma exceção para contornar a análise de correio de domínios de confiança. Esta fonte não especifica exatamente quais os scanners contornados. Por isso, não inventar um percurso na interface gráfica, não garantir que «todas as análises ficam desativadas» nem confundir Trusted Domains com domínios protegidos de routing. Antes de criar ou remover, esclarecer a lista exata de domínios, a exceção necessária e o efeito sobre a análise no build instalado; limitar estritamente o âmbito e validar com uma data de revisão e mensagens correspondentes e não correspondentes.

Para Delete Trusted Domain, a tabela de parâmetros indica DomainName como um array obrigatório que pode conter vários valores, mas não fornece um exemplo de eliminação. Por isso, não reutilizar a estrutura aninhada do exemplo Add como pedido de eliminação sem a verificar; confirmar previamente os valores de destino e a estrutura completa do pedido na API help instalada ou através de esclarecimento oficial.

O seletor global de motor é MalwareProtection, com PrimaryAntiVirusEngine, cuja predefinição na tabela da API é Sophos. Não é o elemento aninhado da política com o mesmo nome e não ativa, por si só, as áreas de análise. Verificar os efeitos sobre a análise simples/dupla e Zero-Day Protection nas políticas afetadas, antes e depois de uma alteração, conforme descrito acima.

Respostas específicas dos objetos como apoio ao diagnóstico

As correspondências seguintes provêm das linhas de estado do SFOS 22/23. Os números são códigos de operações XML, não códigos HTTP; Message.* são chaves da fonte não resolvidas, não textos de mensagens confirmados nem causas de erro inequívocas. A segurança geral da API descrita acima também se aplica aqui: comparar a resposta real e o estado guardado antes de cada nova tentativa, não remover dependências com base em suposições e parar se o estado parcial não estiver esclarecido.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. As últimas três linhas tornam especialmente importante a validação da importação; não presumir que o ficheiro inteiro foi rejeitado ou aceite. Nestas fontes, Edit Address Group apenas apresenta 200 → Message.AddrGrpUpdateSuccess e 500 → Message.AddrGrpUpdateFail; não apresentar os códigos Add como respostas Edit documentadas.
• Delete Address Group: 504, 505 e 506 remetem, cada um, para Message.AddrGrpForeignKeyExists; 507 remete para Message.AddrGrpEmailArcKeyExists. A mesma correspondência simbólica não determina qual a referência afetada. Verificar as utilizações e os grupos efetivamente existentes; estas respostas não substituem o contrato de eliminação em falta.
• Add Data Control List e Update Data Control List: em ambos os casos, 502 → Message.DLPAddSameName e 545 → Message.MTAModeDisableCheck. A chave de Update também contém «Add»; não a renomear. Verificar os nomes, o modo e a lista guardada, sem determinar uma causa apenas com base na chave.
• Add SMTP Policy e Edit SMTP Policy: em ambos os casos, 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck e 545 → Message.MTAModeDisableCheck. Apenas Add SMTP Policy apresenta 502 → Message.SMTPProfileduplicateName. Para 543, a fonte distingue Message.SMTPProfileSenderGenSPXAdd para Add e Message.SMTPProfileSenderGenSPXEdit para Edit. Verificar as associações de domínios, os nomes, o modo e as dependências SPX face ao estado real; não desencadear renomeações automáticas nem flexibilizações da proteção.
• Email Configuration: 505 → Message.ASConfigSubOperationFail consta de ambas as versões. Antes de uma nova tentativa, consultar novamente todas as subsecções SMTP, POP/IMAP e TLS afetadas, sem presumir sucesso completo ou rollback completo. A linha adicional do SFOS 23, 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname, mantém as qualificações indicadas acima.

Validar o mailflow

Executar os seguintes comandos num sistema fora da rede:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Substituir example.com e mail.example.com pelos valores reais. Os comandos testam DNS, TCP 25 e STARTTLS, mas não autorização de relay nem entrega completa. openssl s_client permanece interativo após o handshake; terminar com Ctrl+C.

Testar pelo menos:

• mensagem externa para destinatário válido;
• com Recipient verification ativa, mensagem externa para destinatário inválido;
• mensagem de saída pelo servidor previsto;
• teste de spam ou malware adequado à policy;
• STARTTLS e cadeia de certificados apresentada;
• ação de quarentena e entrega após libertação;
• tentativa de relay bloqueada a partir de origem não autorizada;
• inexistência de entrega direta que contorne o MTA através de DNAT antigo.

Registar apenas resultados de aceitação observados: a mensagem de teste válida deve aparecer como Delivered em Mail logs e ser rastreável pelo Message-ID até à caixa de correio de destino. Esperar a rejeição do destinatário inválido apenas quando a verificação de destinatários estiver ativa, o método de verificação selecionado funcionar através de um percurso de verificação autoritativo acessível e a rejeição estiver configurada. Para With callout, distinguir este teste negativo da exceção documentada: o SFOS aceita destinatários quando o servidor de correio de destino está inacessível durante um período definido. A documentação não especifica esse período; não assumir a mesma exceção para In Active Directory. Com a verificação desativada, uma rejeição não é o resultado esperado deste teste negativo. A tentativa de relay não autorizada não deve criar qualquer mensagem e a libertação da quarentena deve mostrar a entrega posterior do mesmo Message-ID.

Para a primeira verificação utilizar Email > Mail logs, Email > Mail spool, Email > SMTP quarantine e Log Viewer. Para análise aprofundada, anotar hora do teste, remetente, destinatário, assunto, IP de origem e Message-ID e correlacionar:

• MTA: smtpd_main.log
• rejeições: smtpd_reject.log
• erros de análise: smtpd_error.log
• erros MTA internos: smtpd_panic.log
• anti-spam: sasi.log
• proxy SMTP legacy: awarrensmtp.log
• proxy POP/IMAP: warren.log

Serviços e logs da Sophos Firewall explica a correspondência e o acesso por Advanced Shell.

Em Mail logs, Result identifica o estado de entrega, enquanto Reason descreve o motivo de análise ou de policy. Rejected significa que o SFOS eliminou a mensagem e informou o remetente. Dropped elimina-a sem notificação; Bounced aparece após várias tentativas de entrega sem sucesso. Estes estados não são equivalentes, pois produzem respostas e caminhos de diagnóstico diferentes. Outros resultados incluem Delivered, Quarantined e Deleted manualmente; os motivos podem ser filtrados, entre outros, por Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM e BATV.

Operar a quarentena e o Mail spool

Em Email > SMTP quarantine, filtrar por período, remetente, destinatário, assunto e motivo:

• Release: entregar a mensagem.
• Delete: eliminar a mensagem.
• Release and report: libertar e comunicar à SophosLabs apenas falsos positivos classificados como Spam ou Probable spam.

Mensagens com vírus ou classificadas como maliciosas por Zero-Day Protection não podem ser libertadas. A eliminação de entradas Zero-Day Protection exige permissão de escrita no perfil de administrador. Quando a quarentena está cheia, são removidas mensagens antigas.

Só recebem resumos de quarentena os utilizadores autenticados pelo menos uma vez na firewall. Por predefinição, o SFOS não aplica as definições do resumo aos aliases; atribuí-los juntamente com o endereço principal em Email > Quarantine settings > Change user’s quarantine digest settings ou no objeto de utilizador. O resumo pode então incluir spam enviado para endereços principais e aliases. As mensagens para aliases continuam a não aparecer no próprio User Portal.

Configurar e testar o resumo de quarentena da Sophos Firewall explica a configuração, a atribuição de utilizadores, o link de libertação e o teste funcional completo.

Email > Mail spool contém mensagens ainda não entregues ou com falha. O SFOS tenta entregar durante três dias e elimina-as após mais quatro; continuam visíveis em Mail logs. Um spool crescente alerta para problemas de routing, DNS, TLS, policy ou servidor e não é motivo para repetir Retry sem diagnóstico.

O filtro de estado distingue Queued, Failed, SPX blocked, Zero-day protection e Error. SPX blocked aguarda que o destinatário crie uma palavra-passe; Zero-day protection aguarda a análise. Apenas as mensagens na error queue podem ser descarregadas ou eliminadas. Para eliminar ou reenviar mensagens Zero-Day Protection, o perfil de administrador necessita de permissões de leitura e escrita para Zero-Day Protection Activity. Se faltar um botão, verificar primeiro o estado e o perfil, em vez de contornar a limitação com um reinício do serviço.

Quarentena e spool usam armazenamento local. Monitorizar espaço livre, estado SSD e System Health; ver Limpar armazenamento e reports e Verificar SSD Health. Em HA, logs e reports são separados por node e não sincronizados; verificar ambos. Clusters HA da Sophos Firewall explica os fundamentos.

Troubleshooting

O email externo não chega

Verificar MX, A/AAAA, IP público, TCP 25 e SMTP Relay de WAN. Confirmar MTA mode, correspondência do domínio protegido com a policy e ausência de DNAT antigo ou regra prioritária que altere o caminho. Se smtpd_main.log não mostrar ligação, o problema está provavelmente antes de Mail Protection.

A firewall aceita mas não entrega

Verificar servidor interno, route, DNS, porta, TLS e recipient verification. Static host, DNS host e MX usam caminhos diferentes de resolução e failover. Correlacionar logs reject e error com os logs do servidor.

Muitas mensagens ficam no spool

Verificar primeiro Email > Mail spool e os logs MTA. Uma causa comum é uma regra acima da regra MTA automática que já faz match de SMTP. Em Rules and policies > Firewall rules, verificar regras novas na posição Top, regras IPsec ou hotspot automáticas e outras sobreposições. Não mover regras sem análise; o match SMTP real é decisivo.

Só depois de a nova regra sobreposta ser confirmada como a causa, movê-la para uma posição inferior em Rules and policies > Firewall rules, o suficiente para que a regra SMTP prevista volte a ser avaliada. Em seguida, voltar a verificar a entrega e o spool com uma mensagem controlada; as outras ligações necessárias devem continuar a utilizar as regras previstas.

O NC-177930 foi corrigido no SFOS 22.0 MR2: as mensagens ficavam no spool após um crash de mailpoller. Em versões anteriores, incluir o firmware no diagnóstico. Usar a verificação de atualização para o SFOS 22 para escolher a build de destino, preparar a alteração e voltar a testar o fluxo de correio.

Sophos Fusion apresenta Invalid API request

No SFOS 22.0 MR1, Release e Delete podiam falhar quando a firewall era aberta pelo Sophos Fusion (anteriormente Sophos Central). O sintoma Invalid API request é registado como NC-182056; NC-181904 identifica a correção da falha ao libertar pelo Sophos Fusion. O workaround seguro é iniciar sessão diretamente no WebAdmin local e executar a ação em Email > SMTP quarantine. O SFOS 22.0 MR2 Build 546 corrige o problema. Se persistir, verificar separadamente perfil de administrador, acesso ao Sophos Fusion e permissões locais. Para uma atualização, seguir o processo completo de aprovação, preparação, validação e troubleshooting em Atualização de firmware da Sophos Firewall: preparação e boas práticas.

Não é possível ativar Reject based on RBL

O NC-144563 é um caso específico da versão SFOS 20.0.2 MR2 Build 378: se os grupos RBL predefinidos em Email > Address group tiverem sido renomeados, não é possível ativar Reject based on RBL ao criar uma política SMTP route and scan. Numa política existente, a opção não pode voltar a ser ativada depois de ser desativada. Não está documentada uma versão corrigida.

Os grupos predefinidos chamam-se Premium RBL services e Standard RBL services. Primeiro, documentar o build exato e os nomes atuais dos grupos. Se ambas as condições se verificarem, restaurar os nomes originais das RBL predefinidas, reabrir a política e verificar a opção. Não confundir RBL personalizadas com estes dois grupos do sistema.

Noutros builds, ou quando os nomes predefinidos não foram alterados, uma opção a cinzento não comprova NC-144563. Verificar separadamente o tipo de política, Spam protection, a licença Email Protection e a restante configuração.

Um remetente legítimo é classificado como spam

Verificar domínio remetente, SPF/DKIM/DMARC, headers, reputação, policy match e destinatários. Só depois criar uma exceção restrita com data de revisão. Criar e testar exceções de email em segurança descreve todo o processo de âmbito, testes e reversão.

Sistemas internos não conseguem usar relay

Verificar zona de origem em Administration > Device access, host object em Email > Relay settings > Host-based relay e logs MTA. Se um scanner espera SMTP AUTH standard, Host-based relay é normalmente mais fiável. O Authenticated relay separado e não conforme às RFC deve ser testado com o cliente.

Checklist operacional

• Licença, suporte do modelo, DNS e serviços Internet necessários verificados.
• MX, TTL, caminhos público e interno e fallback documentados.
• Regra MTA automática inalterada e no topo.
• Nenhuma regra DNAT antiga contorna Mail Protection.
• Address Group, destino de routing e policy match testados.
• SMTP Relay de entrada de WAN e permissões de hosts de saída separados corretamente.
• Efeitos de SPF/RBL, recipient verification, TLS, DKIM, SPX e banners compreendidos.
• Testes externos positivos e negativos realizados.
• Quarentena, spool, armazenamento e logs monitorizados.
• Mailflow testado novamente após atualizações de firmware.

Para retenção e correlação mais longas, utilizar Central Firewall Reporting ou enviar logs da Sophos Firewall para um SIEM.

FAQ