Configurar o Mail Protection da Sophos Firewall no Legacy mode

No Legacy mode, a Sophos Firewall funciona como proxy de email transparente. O servidor de email interno continua a ser o endpoint SMTP real; a firewall encaminha o tráfego através das regras de firewall e NAT existentes e, simultaneamente, verifica spam, malware, tipos de ficheiro ou correspondências de Data Control.

Este funcionamento é fundamentalmente diferente do MTA mode. A firewall não se torna num Mail Transfer Agent, não assume a entrega de email através de domínios protegidos e não disponibiliza um MTA mail spool para este caminho. Um teste bem-sucedido à porta SMTP não comprova, portanto, nem a análise pelo proxy nem a aplicação da política correta.

⚠️ Alterar o SMTP Deployment Mode é uma mudança global do caminho de proteção de email. Antes da mudança, devem estar documentados o backup, as políticas existentes, as regras de firewall e NAT e um caminho de recuperação testado. Um problema no MTA não justifica mudar para o Legacy mode sem planeamento.

Legacy mode em nove passos

1. Documentar o caminho SMTP de entrada e de saída existente com endereços IP, portas, NAT e Firewall Rule IDs.
2. Verificar se o proxy transparente é realmente mais adequado do que o MTA mode.
3. Garantir um backup da configuração e um acesso de gestão independente.
4. Em Email > General settings, selecionar Switch to legacy mode.
5. Definir o SMTP hostname, os limites de tamanho, a ação para mensagens de tamanho excessivo, IP Reputation, os limites DoS, as portas e o comportamento TLS.
6. Criar apenas as políticas SMTP malware e SMTP spam necessárias ou verificar a sua ordem.
7. Restringir os caminhos DNAT de entrada e SNAT de saída ao servidor de email real.
8. Ativar Scan SMTP ou Scan SMTPS nas regras de firewall que efetivamente correspondem.
9. Validar as mensagens de teste de entrada e saída com Rule ID, resultado da política, certificado e logs do proxy Legacy.

Escolher entre Legacy mode e MTA mode

O Legacy mode é especialmente adequado para ambientes existentes onde o servidor de email interno já está publicado diretamente através de NAT e este caminho deve ser mantido. O SFOS posiciona-se de forma transparente entre o peer remoto e o servidor. O destino MX, a aceitação SMTP e a lógica de entrega continuam a fazer parte do design existente do servidor de email.

O MTA mode é a opção mais adequada quando a firewall deve aceitar as mensagens, encaminhá-las por domínio protegido, fazer relay e mantê-las num spool durante falhas temporárias de entrega. Mail logs e mail spool pertencem expressamente a este modelo de operação. A configuração completa está em Configurar o Mail Protection em MTA mode.

Segundo a ajuda do SFOS 22, o MTA mode não está disponível nos XGS 87/87w e XGS 88/88w. No entanto, isto não transforma automaticamente o Legacy mode numa boa arquitetura de email na cloud. Microsoft 365, Google Workspace e serviços alojados modernos utilizam requisitos próprios de TLS, autenticação e proteção contra abusos. O suporte de um proxy transparente deve ser confirmado previamente.

Em resumo: o MTA mode possui um fluxo de email próprio. O Legacy mode protege um caminho SMTP que já funciona. Misturar estes modelos leva a procurar no log errado, no destino NAT errado ou num spool que não existe.

Topologia de exemplo e caminho de recuperação

O exemplo seguinte utiliza valores de documentação e deve ser adaptado ao ambiente real antes da implementação:

• servidor de email interno 10.20.30.25 na zona DMZ
• endereço SMTP público 192.0.2.25 no caminho WAN
• serviço SMTP de entrada TCP 25
• SMTPS opcional em TCP 465, apenas se os peers e o servidor utilizarem realmente esta variante
• regras de firewall SMTP_In_Legacy e SMTP_Out_Legacy

192.0.2.25 pertence ao intervalo TEST-NET e não é um valor de produção. Antes da alteração, executam-se um teste externo de entrada e um teste de saída com timestamp. Guardam-se as Rule IDs que correspondem atualmente, o endereço de origem público utilizado pelo servidor de saída e a cadeia de certificados.

O caminho de recuperação não consiste apenas em voltar a mudar o modo. Também deve ser possível repor no estado anterior documentado as novas opções de análise, a ordem das políticas, o DNAT, as regras SNAT reflexive ou manuais e os testes temporários.

Definir as configurações globais de email

Onde MTA mode está disponível, a ajuda identifica-o como modo predefinido. Em Email > General settings, selecionar conscientemente Switch to legacy mode depois de assegurar o caminho de recuperação documentado. A mudança de modo por si só não cria um percurso de email Legacy validado.

Em Email > General settings, SMTP hostname aplica-se apenas às notificações geradas pelo sistema nas strings HELO e do banner SMTP; o valor predefinido é SMTP. Não substitui o FQDN do servidor de email de produção nem o respetivo DNS público. Após uma alteração, deve validar-se uma notificação SFOS e não apenas uma mensagem normal gerada pelo servidor.

Verificação da API XML: A documentação do SFOS 23 inclui o estado de operação 506 para Email Configuration, associado a Message.AVGeneralConfInvalidSmtpNtfyHostname. Trata-se de uma chave de mensagem não resolvida, e não de uma mensagem de erro em inglês ou de um código de estado HTTP. Se este estado aparecer na resposta real da API XML, verificar o nome de host enviado para as notificações, a resposta da operação e a configuração guardada antes de considerar a alteração bem-sucedida. A chave não permite deduzir regras de validação específicas. A entrada adicional na documentação não comprova que o comportamento tenha sido introduzido no SFOS 23 nem que se aplique a REST.

Limite de tamanho, ação para mensagens grandes e proteção DoS

Em Email > General settings > SMTP settings, Don’t scan emails greater than define o tamanho máximo das mensagens que são analisadas. No caminho SMTP, o valor 0 significa 51,200 KB segundo a ajuda do SFOS 22, e não ilimitado. Para mensagens maiores estão disponíveis Accept, Reject e Drop.

Accept entrega uma mensagem de tamanho excessivo sem a analisar. Reject recusa-a e informa o remetente, enquanto Drop a elimina sem notificação. Esta escolha é uma decisão consciente de risco e operação. Um Drop não testado dificulta o diagnóstico; um Accept não avaliado cria uma lacuna de análise que deve ser documentada.

Verify sender’s IP reputation verifica o IP do remetente antes dos critérios de spam da política SMTP e rejeita mensagens de endereços IP com má reputação. Os seis campos SMTP DoS aceitam estes intervalos no SFOS 22:

• Maximum connections: 1 a 20000 ligações ao servidor de email
• Maximum connections/host: 1 a 10000 ligações de um host
• Maximum emails/connection: 1 a 1000 mensagens por ligação
• Maximum recipients/email: 1 a 256 destinatários por mensagem
• Emails rate: 1 a 20000 mensagens de um host por minuto
• Connections rate: 1 a 20000 ligações de um host por segundo

Um valor aceite não é automaticamente adequado. Os limites de produção devem derivar do volume real e de uma baseline para que picos legítimos de envio não sejam tratados como DoS.

Bypass spam check for SMTP/S authenticated connections ignora globalmente a verificação de spam nas ligações que o servidor de email identifica como autenticadas. Isto só é aceitável depois de se validarem a autenticação, as origens permitidas e a proteção contra abusos neste caminho. Um início de sessão bem-sucedido não substitui a análise de malware nem um teste negativo com uma ligação não autenticada. Os domínios em Spam check exceptions também constituem um bypass global e não são utilizados como substituto rápido de uma exceção com âmbito restrito.

O banner global de email oferece Inline, no conversion, MIME part e Off. Inline, no conversion acrescenta texto diretamente às mensagens de saída; MIME part acrescenta uma parte MIME separada. Off não acrescenta banner. Introduzir apenas texto em Email banner, por exemplo um aviso breve de confidencialidade. O banner requer análise SMTP ou SMTPS na regra correspondente. Verificar no destinatário uma mensagem de texto simples e outra HTML quanto ao conteúdo, estrutura MIME e apresentação. Como alterar o corpo pode invalidar uma assinatura DKIM existente, verificar também os cabeçalhos no percurso de saída real.

Planear POP/IMAP e portas separadamente

POP/IMAP tem uma seleção própria da CA em TLS certificate, em POP and IMAP TLS configuration. Manter Allow invalid certificate desativado para rejeitar certificados de servidor inválidos; também aqui Disable legacy TLS protocols bloqueia apenas protocolos anteriores ao TLS 1.1. As definições SMTP não substituem esta configuração. O percurso completo de consulta está em Análise de email POP/IMAP, e a administração de CA e certificados em Gestão de certificados.

O Legacy mode também abrange a análise transparente de POP3/S e IMAP/S. Em POP/S and IMAP/S settings, 0 em Don’t scan emails greater than significa 10,240 KB. Recipient headers determina em que headers o SFOS procura os destinatários usados pelas políticas POP/IMAP; os valores predefinidos são Delivered-To, Received e X-RCPT-TO. Só devem ser alterados quando um header capturado do servidor utilizado o justificar.

As portas padrão documentadas são SMTP 25, SMTPS 465, POP3 com STARTTLS 110, POP3S 995, IMAP com STARTTLS 143 e IMAPS 993. O SFOS também pode analisar email noutras portas; a ajuda menciona expressamente a 587. Uma porta alternativa deve constar como serviço na regra de firewall correspondente e estar associada ao protocolo de análise realmente ativado. Alterar apenas a porta não transforma TLS implícito em STARTTLS nem o inverso.

Uma política POP-IMAP scan pode combinar grupos de remetentes e destinatários com critérios como a classificação de entrada, o endereço IP de origem, o tamanho da mensagem ou um header. As únicas ações disponíveis são Accept e Prefix subject. A política não ativa o proxy por si só: em Scan email content da regra de firewall correspondente, também deve selecionar-se o protocolo POP3, POP3S, IMAP ou IMAPS realmente utilizado.

Não sobrevalorizar o TLS por causa de uma caixa de seleção

Em SMTP TLS configuration, seleciona-se o certificado CA ou de servidor previsto para a análise. Allow invalid certificate permanece desativado. Segundo a ajuda, Disable legacy TLS protocols apenas desativa protocolos anteriores ao TLS 1.1 e não comprova uma sessão TLS 1.2 ou TLS 1.3 concreta.

A Sophos indica ainda uma limitação importante do Legacy mode: a firewall estabelece a ligação TLS através do endereço IP do domínio, em vez do nome de domínio. Se vários domínios partilharem um endereço IP, a validação do certificado pode falhar. Neste caso, a Sophos recomenda outro caminho de proteção, como o Sophos Email Security. A verificação não é contornada com Allow invalid certificate.

Require TLS negotiation impõe TLS aos Remote Hosts ou redes selecionados; Require sender email domains impõe-no aos domínios remetentes. Se a ligação TLS não puder ser estabelecida, o SFOS elimina as mensagens afetadas. Skip TLS negotiation permite intencionalmente ligações SMTP não cifradas aos peers selecionados e só deve ser usado em exceções documentadas. Segundo a ajuda, cada campo aceita até 512 entradas de host; antes de usar listas amplas devem excluir-se sobreposições entre as listas de imposição e bypass.

Utilizar as políticas de análise de forma consciente

Sem uma subscrição Email Protection válida, o tráfego de email pode continuar permitido, mas não recebe Email Protection. A acessibilidade não demonstra a licença nem a análise. As definições globais são processadas antes das políticas SMTP e POP-IMAP. Em Email > General settings > SMTP settings, ativar a reputação IP no Legacy mode com Verify sender’s IP reputation e guardar com Apply; o controlo MTA chama-se Reject based on IP reputation. O banner global de email de saída só suporta texto.

Depois de ativar a subscrição Email Protection, a Sophos Firewall aplica automaticamente a política predefinida default-smtp-av ao tráfego SMTP em Legacy mode. As políticas próprias são criadas em Email > Policies e processadas pela ordem da lista. Por isso, deve verificar-se primeiro qual política existente corresponde ao remetente e destinatário concretos.

Criar novas políticas SMTP no modo Legacy em Email > Policies > Add policy, selecionando SMTP malware scan ou SMTP spam scan. Para uma política existente, abrir Email > Policies, selecionar Edit na política em causa, alterar as definições necessárias e guardar a política. Em seguida, voltar a verificar a ordem das políticas e repetir os testes positivo e negativo.

Em Email > General settings > Malware protection, seleciona-se globalmente Sophos ou Avira como motor antivírus primário. Ao selecionar Avira, o SFOS desativa Zero-day Protection nas políticas SMTP com Single antivirus. Antes da mudança devem inventariar-se todas as políticas afetadas e, depois, validá-las novamente.

SMTP malware scan

Alterar a ordem das políticas arrastando as entradas na lista. Registar a posição anterior e repetir ambos os testes: uma política piloto restrita não deve ficar oculta atrás de outra mais abrangente que já corresponda.

Ao criar a política, indicar um nome claro e os grupos de endereços de email ou domínios dos remetentes e destinatários. Em Block file types, selecionar os anexos a bloquear; Ctrl+Shift permite escolher vários tipos. MIME whitelist permite os cabeçalhos MIME selecionados, enquanto os restantes tipos são bloqueados segundo a ajuda. Esta permissão de tipos de ficheiro não contorna o antivírus. Disable, pelo contrário, significa expressamente que os emails não são analisados.

Delivery option for recipient aplica-se a anexos infetados, protegidos e suspeitos:

• Don’t deliver: não envia ao destinatário nem o email nem uma notificação.
• Deliver original: envia o email original ao destinatário; não o limpa.
• Remove and deliver: remove o anexo infetado, notifica a remoção e entrega o email. Esta ação não se aplica aos tipos definidos em Block file types; isto não permite deduzir outra ação de entrega para os tipos bloqueados.

Os anexos protegidos não são analisados; por predefinição, o destinatário é notificado, salvo configuração em contrário. Guardar com Save e verificar os resultados reais de entrega e notificação com casos positivos e negativos inofensivos.

Uma política SMTP malware scan controla os tipos de ficheiro bloqueados, as exceções MIME, a análise antivírus e as ações de entrega. Com Single antivirus, segundo a ajuda, o motor selecionado só se aplica a mensagens de entrada; as mensagens de saída são analisadas por ambos os motores. Dual antivirus executa os motores primário e secundário sequencialmente.

A ação Quarantine é combinada com as ações para o destinatário e o administrador. Don’t deliver, Deliver original e Remove and deliver têm consequências muito diferentes. Um anexo protegido ou que não possa ser analisado não deve ser automaticamente equiparado a malware. Cada ação necessita, por isso, de uma mensagem de teste, de um estado esperado no destinatário e de um caminho de libertação documentado.

Quarantine não significa automaticamente que o destinatário não receba nenhuma mensagem; a Delivery option for recipient continua a ser decisiva. Segundo a Sophos, Notify sender só funciona em conjunto com Don’t deliver. Os anexos protegidos não são analisados, mas podem continuar a gerar uma notificação. Em Delivery option for administrator, Don’t deliver não notifica os administradores; Send original envia-lhes a mensagem original. Esta pode conter anexos perigosos ou não analisados e não substitui uma notificação segura. Verificar separadamente os resultados para remetente, destinatário, administrador e quarentena.

⚠️ Remove attachment em Delivery option for administrator está excluído deste guia: o rótulo indica uma ação de administrador, mas a descrição refere uma mensagem sem anexo para o destinatário e uma notificação de remoção aos administradores. Isto não estabelece uma correspondência de entrega segura. Não ativar esta opção como nova configuração em produção. Num piloto isolado de anexos infetados, usar Don’t deliver para destinatários e administradores, monitorizar a quarentena separadamente e verificar os resultados com padrões de teste inofensivos. Alterar uma configuração existente Remove attachment apenas depois de esclarecimento documentado com Sophos Support e verificação controlada; não assumir um resultado limpo nem limpeza automática.

Um piloto limitado em vez de uma política de exemplo não verificada

Para o servidor 10.20.30.25, limitar inicialmente uma política com nome claro a um grupo de destinatários de teste no domínio de exemplo example.net; substituir o domínio e o grupo por valores próprios controlados. Se o domínio não estiver no livro de endereços, adicioná-lo com Create new. Em Block file types, escolher por exemplo Executable files, selecionar Dual antivirus e Quarantine, e planear separadamente as ações para destinatário e administrador conforme acima. Adicionar uma permissão MIME apenas com necessidade justificada. Um anexo protegido continua por analisar; não copiar cegamente Send original para estes anexos de uma política de exemplo.

O limite de análise de exemplo 2048 KB pertence a Don’t scan emails greater than nas definições SMTP globais, não à política piloto nem a uma predefinição fixa do produto. Limita a análise a mensagens pequenas. Antes de o adotar, planear a ação para mensagens grandes e um teste ligeiramente acima do limite com base no volume real; caso contrário, Accept cria uma lacuna de análise, ou Reject e Drop causam problemas de entrega. Políticas próprias de spam SMTP e POP/IMAP são complementos opcionais conforme a necessidade, não requisitos para criar apenas o percurso NAT.

SMTP spam scan

Indicar um nome e os grupos de endereços de email ou domínios dos remetentes e destinatários. Escolher conscientemente uma correspondência exata ou por palavra-chave para esses grupos: a pesquisa por palavra-chave não deve alargar involuntariamente o âmbito. Não assumir sintaxe regex, caracteres universais nem regras AND/OR não documentadas.

• Inbound email is e Outbound email is: escolher a direção separadamente; os critérios são spam, probable spam, virus outbreak ou probable virus outbreak.
• Source IP/network address e Destination IP/network address: indicar o IP ou a rede necessária do remetente ou destinatário.
• Sender remote blacklist: selecionar o grupo RBL adequado para o remetente.
• Message size: definir um limite superior ou inferior; não confundir com o limite global de mensagens grandes.
• Message header: selecionar o cabeçalho; para Other, introduzir os detalhes, escolher correspondência exata ou por palavra-chave e indicar o valor da palavra-chave.

Reject rejeita o email e informa o remetente. Accept entrega-o. Prefix subject acrescenta um prefixo ao assunto e também entrega o email; por exemplo, Probable spam identifica um teste controlado. Drop descarta sem avisar o remetente; Quarantine conserva o email em quarentena. A seleção de modelo SPX está documentada para Accept e Prefix subject, exclusivamente para emails de saída. Isto não demonstra suporte SPX para outras ações nem a encriptação automática de todos os emails aceites. Guardar com Save e verificar a correspondência e a ação separadamente.

Uma política SMTP spam scan pode corresponder à classificação de spam, à origem ou destino, a uma RBL, ao tamanho da mensagem, aos headers ou a uma Data Control List. Dependendo do caminho, estão disponíveis as ações Reject, Accept, Change recipient, Prefix subject, Drop e Quarantine.

O critério Data control list e a atribuição SPX nesta política aplicam-se apenas a mensagens de saída. None, por outro lado, aplica a ação escolhida a todas as mensagens entre os grupos de remetentes e destinatários especificados. Change recipient não entrega também ao destinatário original, mas substitui-o pelo destino configurado. Estes três âmbitos são testados com um caso de destinatário positivo e outro negativo antes de se colocar a política na ordem de produção.

Preparar tipos de ficheiro próprios e Data Control

As categorias predefinidas de ficheiros de email são Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files e Web files. Classificam por extensão ou cabeçalho MIME, não garantem segurança. Por exemplo, Executable files inclui exe, cmd, bat e com; pdf aparece em Document files e Page layout files, e application/octet-stream aparece em várias categorias. Não considerar as categorias mutuamente exclusivas nem permitir de forma abrangente um cabeçalho MIME genérico para resolver um único anexo. A referência interna detalhada está em Web Protection; verificar os valores na instalação de destino antes de escolher um modelo ou definir um tipo próprio restrito.

As CCL podem detetar padrões como números de cartão de crédito ou de segurança social, endereços postais e endereços de email. Usar dados sintéticos na verificação piloto, nunca dados pessoais reais. Incluir apenas padrões adequados à finalidade e à região; uma correspondência não prova a autenticidade dos dados nem uma classificação jurídica.

Atribuir um nome ao tipo de ficheiro próprio e guardar o objeto com Save antes de alterar a política. O caminho de criação separado do MTA é Email > Policies and exceptions > File type > Add; não substitui o caminho Legacy. Os tipos de ficheiro também são utilizados nas políticas web; a configuração pertence a Web Protection. Dar também um nome claro à Data Control List e selecionar Save depois de escolher as CCL.

No Legacy mode, os tipos de ficheiro próprios são criados em Email > Policies > File type > Add a partir de um modelo, de extensões ou de tipos MIME. As extensões são introduzidas sem ponto inicial e apenas os tipos próprios podem ser editados. Um novo tipo não é adicionado automaticamente às policies existentes. É necessário abrir a scan policy afetada, adicionar o tipo e voltar a guardá-la. Um teste positivo com anexo e um teste negativo semelhante mostram se a ação prevista é realmente aplicada.

Uma Data Control List é criada em Email > Data control list > Add a partir das Content Control Lists necessárias. Os filtros Type e Region ajudam a selecionar apenas padrões adequados de dados financeiros, de identidade ou outros dados sensíveis. O match da lista ainda não define uma ação; esta é configurada na scan policy associada. Uma pequena lista piloto com um teste positivo e outro negativo é mais segura do que uma coleção ampla de CCLs não verificadas.

No Legacy mode, o SPX pode ser selecionado nesta política para mensagens de saída. Contudo, o modelo de palavra-passe, o portal e a validação constituem um processo de segurança separado; ver Configurar a encriptação de email SPX. Não se adiciona uma Data Control List nem uma atribuição SPX ao primeiro teste básico do proxy.

Uma classificação incorreta confirmada não se corrige desativando uma política abrangente. No modo Legacy, deve ajustar-se de forma específica a política SMTP malware scan ou SMTP spam scan adequada; um teste positivo e um teste negativo fora do âmbito previsto devem confirmar o efeito. Criar e testar exceções de email em segurança descreve, por outro lado, exclusivamente o objeto de exceção no modo MTA: a origem, o remetente ou o destinatário são critérios alternativos (OR), não uma condição AND que combine exatamente os três atributos. Este objeto de exceção MTA não é um controlo do modo Legacy.

Correspondências documentadas dos tipos de ficheiro

Esta referência conserva as correspondências das categorias de email; não é uma lista de permissões nem prova de malware. Verificar os valores na instalação de destino antes de alterar. Os tokens MIME técnicos mantêm-se, incluindo grafias documentadas invulgares como text/x-script.phyton; isto não demonstra conformidade com normas nem define uma nova regra MIME própria.

Audio files

• Extensões: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• Cabeçalhos MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

• Extensões: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Cabeçalhos MIME: application/octet-stream.

Compressed files

• Extensões: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Cabeçalhos MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensões: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Cabeçalhos MIME: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Extensões: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• Cabeçalhos MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensões: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
• Cabeçalhos MIME: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

• Extensões: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Cabeçalhos MIME: application/x-cdlink.

Document files

• Extensões: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
• Cabeçalhos MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

• Extensões: pl, jsp, asp, php, cgi, shtml.
• Cabeçalhos MIME: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Extensões: bin, enc, hex, hqx, mim, mime, uue.
• Cabeçalhos MIME: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensões: exe, cmd, bat, com.
• Cabeçalhos MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Extensões: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• Cabeçalhos MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

• Extensões: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Cabeçalhos MIME: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

• Extensões: 8bi, arx, crx, plugin, vst, xll.
• Cabeçalhos MIME: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

• Extensões: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
• Cabeçalhos MIME: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

• Extensões: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• Cabeçalhos MIME: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

• Extensões: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Cabeçalhos MIME: application/atom+xml.

Utilizar o email journaling opcional respeitando a proteção de dados

Dar um nome claro à entrada de journaling e guardar a seleção de destinatários e o destino do journal com Save antes dos testes seguintes.

Em Email > General settings > Email journaling > Add, o SFOS pode enviar cópias das mensagens SMTP/S recebidas para destinatários ou grupos de endereços selecionados para um endereço de journaling separado. A seleção Any inclui todas as mensagens recebidas. A função aplica-se apenas a SMTP/S e não regista tráfego POP ou IMAP.

O journaling cria uma cópia adicional do email. Não constitui automaticamente um arquivo inviolável nem comprova o cumprimento das obrigações legais de retenção. Antes da ativação definem-se a finalidade, os destinatários autorizados, o acesso à caixa de journaling, a encriptação, o período de retenção, o armazenamento necessário e o responsável.

Para o primeiro teste seleciona-se uma única caixa de teste em vez de Any. Uma mensagem recebida para essa caixa deve aparecer no destino normal e na caixa de journaling; uma mensagem para um destinatário não selecionado não deve gerar uma cópia. O endereço de journaling não pode iniciar um fluxo que devolva a cópia ao SFOS e crie um ciclo.

A seleção de destinatários só é ampliada após os testes positivo e negativo. Para o rollback, remove-se a entrada de journaling ou repõe-se o estado anterior documentado. As cópias já entregues permanecem na caixa de journaling e devem ser tratadas de acordo com as respetivas regras de retenção.

Identificar com segurança os objetos de email Legacy através da API XML

As referências da API XML para SFOS 22 e 23 descrevem objetos de email próprios do modo Legacy. Um caminho de menu do MTA Mode, uma tabela de parâmetros sem hierarquia ou um exemplo com alternativas separadas por barras não constitui um pedido pronto a copiar. O acesso à API, o transporte, o estado da operação, as chaves de mensagem não resolvidas e a verificação após a escrita são explicados em Proteger o acesso à API XML. As correspondências seguintes ajudam a ler uma configuração existente; não afirmam que tenha sido testada uma chamada de escrita e não se aplicam automaticamente a REST nem à Central API.

Antes de uma alteração, guardar um backup, o conteúdo atual do objeto, as políticas que o referenciam e a sua ordem. Esclarecer o pedido concreto e os valores de campo contraditórios com base na ajuda da API do build instalado ou com Sophos Support. Depois, verificar separadamente os objetos guardados e o efeito real no email. Um campo obrigatório na tabela não indica se a omissão de outros campos conserva os respetivos valores anteriores. Também não ficam demonstrados o esvaziamento, a substituição ou a combinação de listas, nem alterações atómicas.

EmailConfiguration: o protocolo e o contexto TLS fazem parte do campo

Em EmailConfiguration, os campos com o mesmo nome distinguem-se pelos respetivos elementos-pai:

• GeneralSettings/EmailSignature e GeneralSettings/EmailBannerMode dizem respeito ao banner de saída. A tabela da API indica os valores de modo inline_plain, mimepart e off; o exemplo, pelo contrário, contém alternativas próximas dos rótulos da UI. Não tratar estes textos como valores de API idênticos sem os verificar. EmailSignature é uma cadeia de caracteres com um máximo de 2000 caracteres, segundo a tabela da API.
• SMTPSSettings/DontScanEmailsGreaterThan é o limite de análise SMTP em KB; SMTPSSettings/ActionForOversizeEmails é a ação separada Accept, Reject ou Drop. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings e os seis limites DoS também se encontram em SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan é outro limite em KB, de tipo inteiro. POPIMAPSettings/RecipientHeaders/Header é uma lista de cadeias de caracteres de cabeçalhos para identificar destinatários, não uma lista de destinatários SMTP.
• SMTPTLSConfiguration e POPSIMAPTLSConfiguration contêm, cada um, os seus próprios TLSCertificate, AllowInvalidCertificate e DisableTLS1. O certificado SMTP não substitui o certificado POP/IMAP. RequireTLSWithHost, RequireTLSWithSenderDomain e SkipTLSHosts encontram-se no contexto TLS de SMTP; são listas separadas de cadeias de caracteres, não uma exceção comum de ativação/desativação. Não confundir o limite da UI de 512 entradas de host com a indicação da tabela da API de um máximo de 512 caracteres.

Manter separadas a tabela da API, o exemplo e a referência da UI: A tabela da API indica 1024 como valor predefinido para ambos os limites de análise. Para MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate e ConnectionsRate, indica, respetivamente, 5000, 100, 100, 100, 1000 e 100. O exemplo utiliza, pelo contrário, 1000 para MaximumEmailsConnection; por sua vez, o exemplo da UI de 2048 KB, explicado acima, não é um valor predefinido. O significado de 0 continua a ser o da referência da UI específica de cada protocolo descrita acima, não uma definição de tamanho ilimitado deduzida do exemplo da API.

A tabela da API permite 1 a 512 para MaximumRecepientsEmail, enquanto a referência da UI indica 1 a 256 para Maximum recipients/email. A grafia da API MaximumRecepientsEmail mantém-se inalterada; não deduzir daí um nome de campo corrigido nem que 512 seja seguramente válido na UI. Os outros cinco intervalos DoS coincidem com os intervalos da UI indicados acima. O estado guardado e a ajuda do build de destino continuam a ser determinantes.

Outros conflitos impedem a adoção cega do exemplo: para VerifySendersIPReputation, a tabela indica on/off e apresenta Disable como valor predefinido, enquanto o exemplo mostra Enable. Para SMTPSDosSettings, o tipo de dados INTEGER aparece ao lado do valor predefinido da tabela Disable e do valor do exemplo Enable. Segundo a tabela, BypassSpamCheck tem o valor predefinido Disable, mas o exemplo ativa-o. Ambos os contextos TLS permitem certificados inválidos no exemplo. Não adotar estas definições inseguras do exemplo nem construir, a partir das indicações contraditórias, um payload supostamente válido; mantém-se a decisão segura sobre TLS e bypass descrita acima.

Para a operação Email Configuration, estão documentados 200 com Message.AVGeneralConfUpdateSuccess, 500 com Message.AVGeneralConfUpdateFail e 505 com Message.ASConfigSubOperationFail. O SFOS 23 acrescenta a correspondência 506 com Message.AVGeneralConfInvalidSmtpNtfyHostname, já explicada acima. São estados de operação e chaves não resolvidas, não códigos HTTP nem textos confirmados em execução. Sobretudo após 505, voltar primeiro a ler as definições SMTP, POP/IMAP e TLS; não presumir nem um rollback completo nem uma gravação completa, e não repetir cegamente.

Malware SMTP: tratar destinatários e administradores de forma independente

O objeto chama-se AntiVirusMailSMTPScanningRules. Name identifica a política, e After/Name é a referência à política anterior apresentada no exemplo. SenderList/Sender e ReceiverList/Receiver são listas separadas; BlockFileTypes/FileType é a lista de tipos de ficheiro bloqueados. A tabela da API também apresenta WhiteList como lista MIME, mas não mostra a correspondente estrutura hierárquica no exemplo. Não inventar daí um nó-pai XML adicional.

Para Scanning, a tabela da API indica Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) e Disable, com o valor predefinido Disable. O exemplo Disable/Disable não é uma enumeração completa nem um valor utilizável para a análise antivírus pretendida. Quarantine e NotifySender são controlos independentes com Enable/Disable; segundo a tabela da API, o valor predefinido de ambos é Disable. Estes valores da tabela não substituem a política predefinida existente nem comprovam o estado atual da análise.

Para anexos infetados, suspeitos e protegidos, existem, em cada caso, duas ações escolhidas de forma independente:

• Destinatários: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment com Don'tDeliver, DeliverOriginal ou RemoveAndDeliver.
• Administradores: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment com Don'tDeliver, SendOriginal ou RemoveAttachment.

A tabela da API indica Don'tDeliver como valor predefinido para os seis campos de ação. Isto não equivale à descrição da UI de uma notificação predefinida para anexos protegidos e não comprova o estado atual da entrega. Os efeitos e limites explicados acima continuam a ser decisivos: DeliverOriginal ou SendOriginal podem transmitir anexos não analisados ou perigosos; a quarentena não comprova que a entrega ao destinatário tenha sido impedida. A opção de administrador não esclarecida RemoveAttachment continua excluída, mesmo que a API a apresente como valor. Verificar separadamente os resultados para remetente, destinatário, administrador e quarentena.

AntiSpamRules: não confundir correspondência, ordem e ação

Em AntiSpamRules, Name identifica a regra. After/Name é a referência apresentada no exemplo para a sua posição após outra regra. Antes de Add, Edit ou Order, guardar a ordem real e o nome da regra referenciada; esta documentação não descreve automaticamente uma sintaxe para a primeira posição nem para regras anteriores inexistentes.

RecipientList/Action com RecipientEmail e SenderEmailList/Action com SenderEmail controlam separadamente a correspondência do destinatário e do remetente. A tabela da API indica Equals ou Contains para ambas as ações de correspondência, com o valor predefinido de tabela Contains. Não são a ação de entrega. MarkSpamIf, por sua vez, contém Condition e os correspondentes OtherHeader, Operator e MatchIs. Um tamanho de mensagem exige uma comparação de tamanho; um cabeçalho, uma correspondência de texto; uma classificação, um valor de classificação. A linha da tabela sem hierarquia descreve MatchIs como um tamanho de mensagem inteiro, mas o exemplo utiliza Spam. Não concluir daí que todos os tipos de condição sejam numéricos. O valor de tabela 4 e os diferentes identificadores de condição no exemplo não constituem uma base para inventar uma correspondência de cabeçalho ou de enumeração.

SMTPAction/Action e SMTPAction/ActionParameter determinam a ação SMTP e o respetivo valor adicional; SMTPAction/Quarantine é separado destes. POPIMAPAction/Action e POPIMAPAction/ActionParameter pertencem ao caminho de consulta, cujo exemplo mostra apenas Accept e Prefix Subject. Não transferir uma ação SMTP para POP/IMAP. Para Change recipient, o parâmetro é o destino de entrega substituto, não um endereço de journaling adicional. Mantêm-se as restrições descritas acima para Data Control e SPX de saída.

Também aqui o exemplo e a tabela são contraditórios: para Quarantine, o exemplo mostra Enable/Disable, mas a tabela permite 0 e Enable. A tabela de ações SMTP também apresenta Accept With SPX; não deduzir esta grafia da API a partir do rótulo da UI ou de um Accept normal. Antes de uma chamada de escrita, esclarecer o valor concreto dependente da condição, em vez de enviar as alternativas do exemplo separadas por barras.

Para Order SMTP Scanning Policy, constam 200 com Message.SpamRuleUpdateRuleOrderSuccess e tanto 500 como 505 com Message.SpamRuleUpdateRuleOrderFail. A mesma chave identifica, portanto, duas linhas de estado; não explica a respetiva causa. Para Add SMTP Scanning Policy, está documentado 502 com Message.SpamRuleRecordExists. Antes de repetir Add ou Order, verificar o nome existente, o conteúdo e a ordem guardada; a verificação central de segurança da API e os testes positivo e negativo da política também se aplicam aqui.

DataControlList: as assinaturas ainda não são uma ação de entrega

O objeto Legacy DataControlList contém Name e Signatures/Signature, uma lista de nomes de assinaturas CCL. A tabela sem hierarquia utiliza para estes as designações name e signaturename; isto não justifica mudar silenciosamente o nome das tags XML apresentadas no exemplo. A tabela indica o nome como cadeia de caracteres obrigatória com um máximo de 255 caracteres e as assinaturas como lista opcional de cadeias de caracteres. Utilizar o nome real da assinatura da seleção de CCL disponível na própria instalação, não o copiar do exemplo de países. A ação continua a resultar apenas da política associada. Não utilizar o outro objeto MTADataControlList em vez deste objeto Legacy.

Para Add Data Control List e Update Data Control List, ambas as referências apresentam 502 com Message.DLPAddSameName e 545 com Message.MTAModeDisableCheck. 545 é uma correspondência documentada de estado/chave, não uma afirmação verificada de que o Legacy Mode proíbe esta função ou de que é necessária uma mudança de modo. Por isso, não mudar o modo para resolver o erro. Verificar a lista guardada e as suas referências antes de repetir Add ou Update e esclarecer a resposta real com a ajuda do build instalado ou com Sophos Support.

AVASAddressGroup: exatamente um ramo dependente do tipo

AVASAddressGroup é o grupo de endereços Legacy para estas regras de email, não um objeto cuja equivalência fique comprovada por um caminho de menu MTA. Name identifica o grupo; a tabela da API indica um máximo de 50 caracteres e, para a Description opcional, um máximo de 255. A tabela de GroupType indica RBLIPv4, RBLIPv6, IPAddress e EmailAddressOrDomain, enquanto o exemplo utiliza genericamente RBL. Não normalizar silenciosamente estas grafias.

O comentário do exemplo exige exatamente um ramo adequado ao tipo: RBLList/RBLName ou RBLFile, IPAddressList/IPAddressNetwork ou IPAddressFile, ou ainda EmailAddressList/EmailAddressDomain ou EmailAddressFile. As entradas das listas são cadeias de caracteres; a tabela indica vários valores e duplicados ignorados. O exemplo mostra as alternativas em conjunto, mas não é uma instrução para enviar todas as listas e ficheiros. Para grupos de email/domínio, EmailImportType distingue os valores Manual e Import. A tabela indica os formatos csv e txt para EmailAddressFile, mas descreve contraditoriamente o campo como entrada manual; o exemplo refere o nome de ficheiro de um pedido multipart. Nenhuma destas indicações comprova uma associação multipart completa nem uma chamada de importação segura. Esclarecer estes detalhes para o build específico antes de uma importação.

Para Add Address Group, estão documentados 502 com Message.AddrGrpRecordExists, 541 com Message.AddrGrpImportFailed, 542 com Message.AddrGrpEmptyFile1 e 543 com Message.AddrGrpSomeEmailNotImported. Não deduzir das chaves não resolvidas nem as entradas efetivamente importadas nem um rollback completo. Comparar os membros guardados com a lista pretendida antes da importação seguinte.

Para Delete Address Group, 504, 505 e 506 têm a mesma chave Message.AddrGrpForeignKeyExists; 507 está associado a Message.AddrGrpEmailArcKeyExists. As chaves não distinguem com segurança os diferentes objetos que referenciam o grupo. Inventariar as políticas e as referências de journaling antes de eliminar, avaliar a resposta exata da operação e verificar depois se o grupo existe. Não remover cegamente uma política de proteção associada para forçar uma chamada de eliminação.

TrustedDomain, journaling e seleção do motor têm âmbitos diferentes

AntiSpamTrustedDomain/DomainList/DomainName é uma lista de cadeias de caracteres de domínios. Add e Delete utilizam DomainName como identidade da lista. A descrição da API refere um bypass da análise para emails de domínios de confiança, mas não identifica exatamente os analisadores que são contornados. A UI descreve Spam check exceptions como bypass de spam. Não ampliar estas duas afirmações para uma garantia relativa a todas as análises nem para uma equivalência exata API/UI comprovada. Gerir domínios apenas com uma finalidade documentada e um âmbito restrito; antes e depois de Add ou Delete, verificar a lista e o efeito de proteção esperado. Não inventar, a partir da página Delete, um pedido XML completo que não é fornecido.

AntiSpamEmailArchiver, por sua vez, cria cópias: Name identifica a entrada, RecipientList/Recipient limita os destinatários originais e SendCopyOfEmailTo é o endereço separado para a cópia. Segundo a tabela da API, o nome, os destinatários e o endereço para a cópia são obrigatórios; o nome e o endereço para a cópia podem ter, no máximo, 50 caracteres. A linha dos destinatários é descrita como cadeia de caracteres escalar, mas o exemplo apresenta-a num elemento-pai de lista. Não resolver esta divergência com um payload inventado para abranger todos os destinatários. O piloto com uma única caixa de correio descrito acima, incluindo proteção de dados, prevenção de ciclos e teste negativo, também se aplica à automatização; uma alteração dos destinatários não é uma alteração do endereço para a cópia.

MalwareProtection/PrimaryAntiVirusEngine é, por sua vez, um seletor escalar global do motor, não um filtro de destinatários nem uma política de análise individual. A tabela da API indica Sophos como valor predefinido; o exemplo Sophos/Avira mostra alternativas, não um valor combinado a enviar. Continua a ser necessário verificar o efeito de Avira sobre Zero-day Protection nas políticas SMTP com Single antivirus, explicado acima. Após uma mudança, verificar o valor global guardado e todas as políticas afetadas; rotas de documentação separadas não transformam isto em configurações de motor independentes.

Combinar NAT e regras de firewall

Publicar o caminho SMTP de entrada

Em Rules and policies > NAT rules, escolher a família IP adequada e abrir Add NAT rule. Deve existir um objeto IP host do servidor interno em Hosts and services > IP host para aparecer em Translated destination (DNAT). No exemplo simples de entrada, Translated source (SNAT) e Translated service (PAT) permanecem Original; em Original service, selecionar apenas serviços SMTP usados, por exemplo SMTP e SMTP[S]. Verificar todos os campos antes de Save. A tradução de destino NAT não equivale ao campo de firewall Destination networks, qualificado separadamente abaixo.

Para mensagens de entrada, uma regra DNAT traduz o endereço WAN público para o servidor de email interno. Original Source é limitado tanto quanto o design de email permitir; Original Destination é o endereço público previsto; Translated Destination é 10.20.30.25 ou o servidor de email real. Original service e translated service permanecem limitados às portas SMTP efetivamente disponibilizadas.

Uma regra reflexive também cria SNAT para a direção oposta. Só é selecionada se esta identidade de origem pública exata estiver prevista para o caminho de saída. Várias ligações WAN, smarthosts ou rotas de operador diferentes exigem um design próprio de routing e SNAT. A ordem geral e a zona de destino após NAT são explicadas em Publicar um servidor através de DNAT.

Utilizar duas regras de firewall restritas

Para criar uma regra em Rules and policies > Firewall rules, escolher a família de protocolo real IPv4 ou IPv6 e abrir Add firewall rule > New firewall rule. Indicar o nome e os campos necessários e guardar com Save. Não reutilizar os endereços IPv4 de exemplo deste artigo numa regra IPv6.

⚠️ As descrições de Destination networks são contraditórias: o exemplo de email Legacy indica o servidor interno, enquanto o procedimento DNAT geral baseia a correspondência da firewall no destino público original. Este guia não resolve o caso específico do proxy por suposição. Documentar a correspondência de entrada já comprovada e mantê-la no piloto. Não derivar uma nova regra de produção de nenhuma das correspondências nem alterar o destino por suposição. Para um novo percurso, esclarecer com Sophos Support ou verificação controlada adequada antes da aprovação, sustentando-o com Rule ID, ocorrência DNAT e capturas antes e depois da tradução. A variante SNAT de saída não resolve esta contradição.

Para a validação, regras separadas são mais claras do que uma regra bidirecional com várias zonas e objetos Any:

• Entrada: WAN para a zona do servidor de email interno, ponto terminal SMTP 10.20.30.25, apenas os serviços SMTP necessários, logging ativado. Este ponto terminal não é um valor prescrito para o campo não resolvido Destination networks.
• Saída: zona e host do servidor de email interno para WAN ou para o smarthost específico, apenas os serviços SMTP necessários, logging ativado

Em Scan email content, ativa-se Scan SMTP nas duas direções necessárias e Scan SMTPS apenas quando SMTPS é realmente utilizado. Se faltar em Services a porta padrão do protocolo selecionado, o SFOS disponibiliza Add ports. Para uma porta não padrão, deve definir-se deliberadamente o serviço correspondente. Serviço, NAT, listener do servidor e opção de análise devem descrever o mesmo caminho; Add ports não substitui esta verificação.

As regras são colocadas acima de regras mais gerais que já correspondam ao mesmo tráfego. Depois de guardar, a Firewall Rule ID registada é decisiva. A estrutura das regras, a zona NAT e a ordem são explicadas em Configurar regras da Sophos Firewall em segurança.

Opcional: utilizar outro endereço de origem público na saída

Esta configuração aplica-se ao tráfego SMTP encaminhado do servidor interno, não a mensagens MTA geradas pelo sistema. É útil quando é necessária outra identidade pública atribuída em vez do endereço MASQ da WAN. A atribuição do operador, routing, SPF, RDNS e autorizações do operador devem corresponder a essa identidade; SNAT não altera estes requisitos.

1. Em Network > Interfaces > Add interface > Add alias, selecionar a interface WAN física real, IP version IPv4 e o endereço atribuído com o valor IPv4/Netmask adequado; Save. O percurso do operador, Device Access e as verificações do alias estão em Configurar um IP alias.
2. Em Hosts and services > IP host > Add, criar um host com nome para o mesmo endereço público: IP family IPv4, Type IP, IP address o endereço atribuído; Save. Um objeto host por si só não associa um endereço à interface.
3. Em Rules and policies > NAT rules > New NAT rule, limitar Original source ao servidor de email interno real e definir Translated source (SNAT) como o host IP público. Limitar Original destination aos destinos necessários ou ao smarthost e Original service aos serviços SMTP necessários. Translated destination (DNAT) e Translated service (PAT) permanecem Original. Inbound interface e Outbound interface devem corresponder ao percurso real servidor-WAN. Guardar com Save e colocar acima de outras regras SNAT que também correspondam; verificar separadamente as ordens NAT e firewall. Fundamentos de NAT explica a primeira correspondência. Any, Top, Port1 e Port2 nos exemplos não são valores obrigatórios.
4. Em Rules and policies > Firewall rules > Add firewall rule > New firewall rule, criar uma regra IPv4 de saída adequada ou verificar a regra restrita existente: Action Accept, zona e host reais do servidor como origem, WAN e destinos necessários, apenas os serviços SMTP necessários, Log firewall traffic ativado. Selecionar Scan SMTP e, quando aplicável, Scan SMTPS como acima; Save e verificar a ordem do firewall independentemente de NAT.
5. Criar uma ligação SMTP nova para um destinatário externo controlado. Verificar em conjunto Firewall Rule ID, NAT Rule ID, IP de origem traduzido na captura ou no destinatário externo e a entrega real. Uma sessão existente ou um teste de porta SMTP não basta. Testar também negativamente uma origem fora do âmbito ou um serviço não permitido.

Para reverter, restaurar primeiro as regras documentadas e a respetiva ordem, e verificar depois o IP de origem anterior e a entrega com uma ligação nova. Remover o alias e o host IP apenas se nenhum outro serviço depender deles.

Validar o fluxo de email e a análise pelo proxy

Na regra de firewall de saída, During scheduled time determina quando a regra se aplica. Escolher conscientemente All the time para um servidor sempre disponível. Um horário restrito pode alterar a correspondência fora desse período; verificar aí também Rule ID e fluxo de email. Não é um horário da regra SNAT. A regra de firewall criada automaticamente ao ativar MTA pertence a outro fluxo e não substitui esta regra de servidor Legacy; usar o guia MTA para esse percurso.

Primeiro envia-se uma pequena mensagem externa para uma caixa de correio de teste. Depois, o servidor de email interno envia uma segunda mensagem para um destinatário externo controlado. Ambos os testes recebem assuntos únicos e timestamps UTC.

Para STARTTLS na porta 25 e uma ligação TLS direta na porta 465, podem ajudar as seguintes verificações apenas de leitura a partir de um sistema de teste autorizado:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Substitua mail.example.net pelo FQDN real e teste apenas as portas efetivamente disponibilizadas. Estes comandos OpenSSL apresentam a cadeia de certificados apresentada pelo servidor e os parâmetros TLS negociados; examine quaisquer erros de verificação dos certificados. Não verificam explicitamente o nome de anfitrião esperado e podem continuar apesar dos erros de verificação, pelo que uma ligação não comprova a autenticação bem-sucedida do certificado. Não comprovam nem a entrega bem-sucedida do correio nem a análise de malware, spam ou Data Control.

No Log Viewer, a origem, o destino, o serviço, a ação e a Firewall Rule ID devem corresponder às novas regras. Para o proxy SMTP/S Legacy, awarrensmtp.log e awarrenmta.log são correlacionados com o mesmo timestamp. Os ficheiros de log são explicados em Serviços e logs da Sophos Firewall.

Em seguida, realize testes negativos separados para o âmbito da regra de firewall e a correspondência com a política de mensagens. Uma origem ou um serviço fora do âmbito do piloto não deve corresponder à regra de firewall do piloto e deve seguir o resultado documentado de permissão ou bloqueio; outra regra autorizada pode continuar a fornecer proteção. Uma mensagem de teste sem o critério da política do piloto não deve corresponder a essa política nem receber a sua ação específica, mantendo, contudo, qualquer análise predefinida ou outra análise aplicável. Para cada caso, registe a Firewall Rule ID, a política e o resultado de entrega esperados e compare-os com o resultado observado. Não utilize malware real nos testes de produção; utilize padrões de teste inofensivos estabelecidos e uma caixa de correio controlada para validar a análise.

Delimitar erros por sintoma

O SMTP funciona, mas a política não é aplicada

Primeiro verifica-se a Firewall Rule ID. Se outra regra corresponder, corrigem-se a ordem, a origem, o destino, o destino NAT e o serviço. Se a regra esperada corresponder, Scan SMTP ou Scan SMTPS, a ordem das políticas e os grupos de remetentes e destinatários devem ajustar-se ao teste. Uma política isolada não ativa o proxy transparente.

O email de entrada não chega ao servidor

Verificam-se separadamente o endereço de destino público, o hit DNAT, o translated destination, a zona de destino, o listener do servidor e o caminho de retorno. Uma ligação TCP aberta até à firewall não comprova que o DNAT e a regra de firewall alcançam o servidor interno. Packet Capture e Rule ID devem mostrar a entrada e o encaminhamento.

O email de saída utiliza o endereço IP público errado

Verificam-se o SNAT, a regra reflexive, o gateway WAN, a rota SD-WAN e o comportamento dos reply packets. O proxy Legacy não seleciona automaticamente o endereço de origem público necessário para SPF, RDNS ou autorização do operador. Antes de uma alteração global de Route Precedence, é necessário comprovar o caminho concreto.

O TLS falha depois de ativar a análise

Registam-se o FQDN, o IP de destino, o certificado, o emissor, a cadeia e a versão negociada. Com vários domínios num endereço IP, a verificação de certificado baseada em IP documentada pode ser a causa. Allow invalid certificate não é ativado como solução rápida.

Falta uma mensagem e não aparece nada no MTA mail spool

Isto não é um critério de sucesso útil no Legacy mode, porque mail spool e os mail logs específicos do MTA pertencem ao MTA mode. A cadeia relevante é composta pela regra de firewall, NAT, logs do servidor SMTP, Log Viewer, awarrensmtp.log e awarrenmta.log. As mensagens em quarentena são verificadas separadamente em Email > SMTP quarantine.

Efetuar um rollback seguro

Para o rollback, repõem-se primeiro as regras piloto e as opções de análise no estado anterior documentado. Depois removem-se novas atribuições de políticas ou repõe-se a sua ordem. As alterações temporárias a DNAT, SNAT ou certificados só são removidas se nenhum outro serviço depender delas.

Só depois se repõe o SMTP Deployment Mode, caso a alteração tenha incluído essa mudança. O fluxo de email de entrada e de saída original deve voltar a funcionar com as Rule IDs, os endereços públicos e os logs de servidor esperados. Mensagens, conteúdo da quarentena ou logs do proxy não são eliminados como rollback padrão.

Checklist de operação

• O proxy transparente foi escolhido de forma consciente e os requisitos de MTA foram excluídos.
• O backup, o acesso de gestão e as Rule IDs originais estão documentados.
• O SMTP hostname, os limites de tamanho SMTP e POP/IMAP, a ação para mensagens grandes, IP Reputation e os limites DoS estão justificados.
• As portas padrão ou alternativas utilizadas e os POP/IMAP recipient headers correspondem ao caminho real do servidor.
• Foram verificados o motor antivírus primário e o seu efeito em Zero-day Protection nas políticas Single antivirus.
• O certificado, as exceções TLS e os domínios afetados foram verificados.
• DNAT, SNAT, zona de destino e portas reais do servidor coincidem.
• As regras de firewall de entrada e saída são restritas, têm logging e a sua correspondência foi comprovada.
• As políticas predefinidas e próprias possuem uma ordem rastreável.
• O journaling opcional está limitado aos destinatários necessários e tem uma finalidade documentada de proteção e retenção de dados.
• Os testes positivo, negativo, TLS e de entrega foram concluídos com sucesso.
• Os logs do proxy Legacy e do servidor de email podem ser correlacionados por tempo.
• O responsável, a data de revisão e o caminho de recuperação completo estão registados.

FAQ