Configure Sophos Firewall Mail Protection in legacy mode

In Legacy mode, Sophos Firewall operates as a transparent mail proxy. The internal mail server remains the actual SMTP endpoint; the firewall forwards traffic through the existing firewall and NAT rules while checking it for spam, malware, file types, or data control matches.

This is fundamentally different from MTA mode. The firewall does not become a mail transfer agent, does not take over mail delivery for protected domains, and does not provide an MTA mail spool for this path. A successful SMTP port test therefore proves neither proxy scanning nor the correct policy.

⚠️ Changing the SMTP deployment mode is a global change to the mail protection path. Before switching, document a backup, existing policies, firewall and NAT rules, and a tested fallback path. An MTA issue is not a reason to switch to legacy mode without planning.

Legacy mode in nine steps

1. Document the existing inbound and outbound SMTP path, including IP addresses, ports, NAT, and Firewall Rule IDs.
2. Check whether transparent proxy operation really fits better than MTA mode.
3. Secure a configuration backup and independent management access.
4. Under Email > General settings, select Switch to legacy mode.
5. Define the SMTP hostname, size limits, oversize action, IP reputation, DoS limits, ports, and TLS behavior.
6. Create only the required SMTP malware and SMTP spam policies, or verify their order.
7. Restrict inbound DNAT and outbound SNAT paths to the actual mail server.
8. In the firewall rules that actually match, turn on Scan SMTP or Scan SMTPS.
9. Validate inbound and outbound test emails against the Rule ID, policy result, certificate, and legacy proxy logs.

Choose legacy mode or MTA mode

Legacy mode mainly suits existing environments where the internal mail server is already published directly through NAT and that path must remain in place. SFOS sits transparently between the remote peer and the server. MX target, SMTP acceptance, and delivery logic remain part of the existing mail server design.

MTA mode is the better choice when the firewall must accept emails itself, route them by protected domain, relay them, and retain them in a spool during temporary delivery failures. Mail logs and mail spool explicitly belong to this operating model. The complete setup is described in Configure Mail Protection in MTA mode.

According to the SFOS 22 help, MTA mode is not available on XGS 87/87w and XGS 88/88w. However, this does not automatically make legacy mode a suitable cloud email architecture. Microsoft 365, Google Workspace, and modern hosted services use their own TLS, authentication, and anti-abuse requirements. Their support for a transparent proxy must be confirmed first.

In short: MTA mode has its own mail flow. Legacy mode protects an already working SMTP path. Mixing these models leads to troubleshooting in the wrong log, at the wrong NAT destination, or in a spool that does not exist.

Example topology and fallback path

The following example uses documentation values and must be adapted to the actual environment before implementation:

• internal mail server 10.20.30.25 in the DMZ zone
• public SMTP address 192.0.2.25 on the WAN path
• inbound SMTP service TCP 25
• optional SMTPS on TCP 465, only if the peers and server actually use this variant
• firewall rules SMTP_In_Legacy and SMTP_Out_Legacy

192.0.2.25 belongs to the TEST-NET range and is not a production value. Before the change, run an external inbound test and an outbound test with timestamps. Save the currently matched Rule IDs, the public source address used by the outbound server, and the certificate chain.

The fallback path involves more than switching the mode back. New scan options, policy order, DNAT, reflexive or manual SNAT rules, and temporary tests must also be restorable to the documented previous state.

Define global email settings

Where MTA mode is available, the help identifies it as the default mode. Under Email > General settings, deliberately select Switch to legacy mode after securing the documented fallback path. Switching modes alone does not create a validated legacy mail path.

Under Email > General settings, SMTP hostname only applies to system-generated notification emails in HELO and SMTP banner strings; its default is SMTP. It replaces neither the production mail server FQDN nor its public DNS. If you change it, validate an SFOS notification rather than only a normal server-generated message.

XML API check: The SFOS 23 documentation lists operation status 506 for Email Configuration, paired with Message.AVGeneralConfInvalidSmtpNtfyHostname. This is an unresolved message key, not an English error message or an HTTP status code. If this status appears in the actual XML API response, check the submitted notification hostname, the operation response, and the saved configuration before treating the change as successful. The key does not establish specific validation rules. The additional documentation entry proves neither that the behavior was introduced in SFOS 23 nor that it applies to REST.

Size limit, oversize action, and DoS protection

Under Email > General settings > SMTP settings, Don’t scan emails greater than defines the maximum message size for scanning. In the SMTP path, the value 0 means 51,200 KB according to the SFOS 22 help, not unlimited. For larger messages, the options are Accept, Reject, and Drop.

Accept delivers an oversized message without scanning it. Reject refuses it and informs the sender, while Drop discards it without notification. This choice is a deliberate risk and operational decision. An untested Drop complicates troubleshooting; an untested Accept creates a scan gap that must be documented.

Verify sender’s IP reputation checks the sender IP before the spam criteria in the SMTP policy and rejects emails from IP addresses with a bad reputation. The six SMTP DoS fields accept these ranges in SFOS 22:

• Maximum connections: 1 to 20000 connections to the mail server
• Maximum connections/host: 1 to 10000 connections from one host
• Maximum emails/connection: 1 to 1000 messages per connection
• Maximum recipients/email: 1 to 256 recipients per message
• Emails rate: 1 to 20000 messages from one host per minute
• Connections rate: 1 to 20000 connections from one host per second

An accepted value is not automatically a suitable value. Derive production limits from actual mail volume and a baseline so that legitimate sending peaks are not treated as a DoS.

Bypass spam check for SMTP/S authenticated connections globally skips spam checks for connections the mail server reports as authenticated. This is only acceptable after validating authentication, allowed sources, and abuse protection on this path. A successful sign-in replaces neither malware scanning nor a negative test using a connection that isn’t authenticated. Domains under Spam check exceptions are also a global bypass and aren’t used as a quick replacement for a tightly scoped exception.

The global email banner offers Inline, no conversion, MIME part, and Off. Inline, no conversion appends the text directly to outbound messages; MIME part adds it as a separate MIME part. Off adds no banner. Enter text only in Email banner, such as a short confidentiality notice. The banner requires SMTP or SMTPS scanning in the matching firewall rule. Check a plain-text and an HTML test message at the recipient to confirm that content, MIME structure, and presentation remain as intended. Because changing the body can break an existing DKIM signature, also validate the actual outbound path by checking the headers.

Plan POP/IMAP and ports separately

POP/IMAP has its own TLS certificate selection for the CA under POP and IMAP TLS configuration. Keep Allow invalid certificate off to reject invalid server certificates; Disable legacy TLS protocols also blocks only protocols earlier than TLS 1.1 here. SMTP settings do not replace this configuration. The complete retrieval path is covered in POP/IMAP email scanning; CA and certificate administration in Certificate management.

Legacy mode also covers transparent POP3/S and IMAP/S scanning. Under POP/S and IMAP/S settings, 0 for Don’t scan emails greater than means 10,240 KB. The Recipient headers setting determines which message headers SFOS searches for the recipients used by POP/IMAP policies; the defaults are Delivered-To, Received, and X-RCPT-TO. Change this setting only when a captured message header from the mail server in use justifies it.

The documented standard ports are SMTP 25, SMTPS 465, POP3 with STARTTLS 110, POP3S 995, IMAP with STARTTLS 143, and IMAPS 993. SFOS can also scan email on other ports; the help explicitly mentions port 587. An alternative port must be present as a service in the matching firewall rule and associated with the scan protocol that is actually enabled. Changing a port alone does not turn implicit TLS into STARTTLS or vice versa.

A POP-IMAP scan policy can combine sender and recipient groups with criteria such as inbound classification, source IP address, message size, or message header. The only actions available here are Accept and Prefix subject. The policy does not activate the proxy by itself: Under Scan email content in the matching firewall rule, you must also select the POP3, POP3S, IMAP, or IMAPS protocol actually in use.

Do not overestimate TLS because of a checkbox

Under SMTP TLS configuration, select the CA or server certificate intended for scanning. Keep Allow invalid certificate turned off. According to the help, Disable legacy TLS protocols only disables protocols earlier than TLS 1.1 and does not prove a specific TLS 1.2 or TLS 1.3 session.

Sophos also points out an important legacy limitation: the firewall establishes the TLS connection using the domain IP address instead of the domain name. If multiple domains share one IP address, certificate validation can fail. In this case, Sophos recommends another protection path such as Sophos Email Security. Do not bypass the check with Allow invalid certificate.

Require TLS negotiation enforces TLS for selected remote hosts or networks; Require sender email domains enforces it for sender domains. If the TLS connection cannot be established, SFOS discards the affected emails. Skip TLS negotiation intentionally allows unencrypted SMTP connections to selected peers and belongs only in documented exceptions. According to the help, each field accepts up to 512 host entries; rule out overlap between enforcement and bypass lists before using broad selections.

Use scan policies deliberately

Without a valid Email Protection subscription, mail traffic may still be allowed but receives no Email Protection. Reachability is therefore not proof of licensing or scanning. Global email settings are processed before SMTP and POP-IMAP policies. Under Email > General settings > SMTP settings, enable IP reputation in legacy mode with Verify sender’s IP reputation and save with Apply; the MTA control is instead called Reject based on IP reputation. The global outbound email banner supports text only.

After the Email Protection subscription is activated, Sophos Firewall automatically applies the default policy default-smtp-av to SMTP traffic in legacy mode. Custom policies are created under Email > Policies and processed in list order. First verify which existing policy matches the specific sender and recipient.

Create new legacy SMTP policies under Email > Policies > Add policy, using SMTP malware scan or SMTP spam scan. To update an existing policy, go to Email > Policies, select Edit for the relevant policy, change the required settings, and save the policy. Then recheck the policy order and repeat the positive and negative tests.

Under Email > General settings > Malware protection, select the primary antivirus engine globally as Sophos or Avira. If you select Avira, SFOS turns off Zero-day Protection in SMTP policies that use Single antivirus. Inventory all affected single-antivirus policies before changing the engine and validate them again afterward.

Change policy order by dragging and dropping entries in the policy list. Record the previous position and repeat both test cases afterward: a narrow pilot policy must not be hidden behind a broader policy that already matches.

SMTP malware scan

When creating the policy, specify a clear name and the sender and recipient email address or domain groups. Under Block file types, select the attachments to block; use Ctrl+Shift to select multiple types. MIME whitelist allows the selected MIME headers, while the remaining file types are blocked according to the help. This file-type allowance is not an antivirus bypass. Disable, by contrast, explicitly means that emails are not scanned.

The Delivery option for recipient applies to infected, protected and suspicious attachments:

• Don’t deliver: neither the message nor a notification is sent to the recipient.
• Deliver original: sends the original message to the recipient; this does not clean it.
• Remove and deliver: removes the infected attachment, sends a removal notification and delivers the message. This action does not apply to file types specified under Block file types; this does not establish another delivery action for blocked types.

Protected attachments remain unscanned; the recipient is notified by default unless configured otherwise. Save the configuration with Save and check the actual delivery and notification results with harmless positive and negative cases.

An SMTP malware scan policy controls blocked file types, MIME exceptions, antivirus scanning, and delivery actions. With Single antivirus, the selected engine applies only to inbound messages according to the help; outbound messages are scanned by both engines. Dual antivirus runs the primary and secondary engines sequentially.

The Quarantine action is combined with the recipient and administrator actions. Don’t deliver, Deliver original, and Remove and deliver have very different consequences. A protected or unscannable attachment must not automatically be equated with malware. Each action therefore needs a test message, an expected recipient state, and a documented release path.

Quarantine doesn’t automatically mean that the recipient receives no message; the Delivery option for recipient remains decisive. According to Sophos, Notify sender only works together with Don’t deliver. Protected attachments aren’t scanned but can still trigger a notification. Under Delivery option for administrator, Don’t deliver means administrators aren’t notified; Send original sends them the original message. That original may contain dangerous or unscanned attachments and is not a safe notification substitute. Check sender, recipient, administrator, and quarantine outcomes separately.

⚠️ Remove attachment under Delivery option for administrator is excluded from this guide: the field label suggests an administrator action, but its description mentions a message without the attachment to the recipient and a removal notification to administrators. This does not establish a safe delivery mapping. Do not newly enable this option in production. For an isolated pilot of infected attachments, use Don’t deliver for both recipients and administrators, monitor quarantine separately, and check outcomes with harmless test patterns. Change an existing Remove attachment setting only after documented clarification with Sophos Support and controlled verification; assume neither a clean result nor automatic sanitization.

A bounded pilot instead of an unverified example policy

For mail server 10.20.30.25, initially restrict a clearly named policy to a test recipient group in example domain example.net; replace the domain and group with your own controlled values. If the domain is missing from the address book, add it using Create new. Under Block file types, choose Executable files, for example, select Dual antivirus and Quarantine, and plan recipient and administrator actions separately as above. Add a MIME allowance only with a justified need. A protected attachment remains unscanned; do not blindly copy Send original for protected attachments from an example policy.

An example scan limit of 2048 KB belongs to Don’t scan emails greater than in the global SMTP settings, not the pilot policy and not a fixed product default. It limits scanning to small messages. Before adopting it, plan the oversize action and a test just above the limit based on actual mail volume; otherwise Accept creates a scan gap, or Reject and Drop cause delivery problems. Custom SMTP spam and POP/IMAP policies are optional additions according to need, not prerequisites merely to create the NAT path.

SMTP spam scan

Specify a name and the sender and recipient email address or domain groups. Deliberately choose exact or keyword matching for these groups: a keyword search must not unintentionally broaden the scope. Do not assume undocumented regex, wildcard or AND/OR syntax.

• Inbound email is and Outbound email is: choose the direction separately; criteria are spam, probable spam, virus outbreak or probable virus outbreak.
• Source IP/network address and Destination IP/network address: specify the required sender or recipient IP address or network.
• Sender remote blacklist: select the appropriate sender RBL group.
• Message size: set an upper or lower size limit; do not confuse this with the global oversize limit.
• Message header: select the header; for Other, enter the details, choose exact or keyword matching and specify the keyword value.

Reject refuses the message and informs the sender. Accept delivers it. Prefix subject adds to the subject and also delivers it; for example, a Probable spam prefix labels a controlled test. Drop discards without notifying the sender; Quarantine retains the message in quarantine. SPX template selection is documented for Accept and Prefix subject, exclusively for outbound emails. This establishes neither SPX support for every other action nor automatic encryption of every accepted message. Save with Save and check matching and action separately.

An SMTP spam scan policy can match spam classification, source or destination, RBL, message size, headers, or a data control list. Depending on the path, the actions include Reject, Accept, Change recipient, Prefix subject, Drop, and Quarantine.

The Data control list criterion and SPX assignment in this policy only apply to outbound messages. None, however, applies the selected action to all messages between the specified sender and recipient groups. Change recipient doesn’t additionally deliver to the original recipient, but replaces it with the configured destination. Test these three scopes with one positive and one negative recipient case before placing the policy in the production order.

Prepare custom file types and Data Control

The email file-type presets are 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, and Web files. These are classifications based on extensions or MIME headers, not safety verdicts. For example, Executable files lists exe, cmd, bat, and com; pdf occurs in both Document files and Page layout files, and application/octet-stream occurs in several categories. Do not treat the categories as mutually exclusive or broadly allow a generic MIME header to fix one attachment. The detailed internal file-type reference is in Web Protection; check the preset values in the target installation before selecting a template or building a narrow custom type.

Give the custom file type a name and save the object with Save before changing the policy. The separate MTA creation path is Email > Policies and exceptions > File type > Add; it does not replace the legacy path. File types are also used in web policies; their configuration belongs in Web Protection. Also give the Data Control List a clear name and select Save after choosing the CCLs.

In legacy mode, create custom file types under Email > Policies > File type > Add from a template or from file extensions or MIME types. Enter extensions without a leading dot; only custom types can be edited. A new type isn’t added automatically to existing policies. Open the affected scan policy, add the file type, and save the policy again. A positive attachment test and a similar negative test show whether the intended policy action really applies.

Build a Data Control List under Email > Data control list > Add from the required Content Control Lists. The Type and Region filters help select only relevant financial, identity, or other sensitive data patterns. A list match doesn’t define an action; the linked scan policy does. A small pilot list with a positive and a negative content test is safer than a broad collection of unverified CCLs.

SPX can be selected in this policy for outbound messages in legacy mode. However, the password model, portal, and validation form a separate security workflow; see Configure SPX email encryption. Do not add a data control list or SPX assignment to the first basic proxy test.

CCLs can detect patterns such as credit card or social security numbers, postal addresses, and email addresses. Use synthetic data for pilot verification, never real personal records. Include only patterns suitable for your purpose and region; a match proves neither data authenticity nor a legal classification.

Don’t resolve a confirmed misclassification by disabling a broadly applied policy. In legacy mode, make targeted changes to the appropriate SMTP malware scan or SMTP spam scan policy; a positive test and a negative test outside the intended scope must confirm the effect. Create and test email exceptions safely instead covers only the exception object in MTA mode: source, sender, or recipient are alternative triggers (OR), not an exact AND condition combining all three attributes. This MTA exception object is not a legacy control.

Documented file-type mappings

This reference retains the email preset mappings; it is neither an allowlist nor evidence of malware. Check the target installation before changes. Technical MIME tokens remain unchanged, including unusual documented spellings such as text/x-script.phyton; this establishes neither standards compliance nor a new custom MIME rule.

Audio files

• Extensions: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• MIME headers: 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

• Extensions: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• MIME headers: application/octet-stream.

Compressed files

• Extensions: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• MIME headers: 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

• Extensions: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• MIME headers: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Extensions: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• MIME headers: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensions: 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.
• MIME headers: 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

• Extensions: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME headers: application/x-cdlink.

Document files

• Extensions: 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.
• MIME headers: 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

• Extensions: pl, jsp, asp, php, cgi, shtml.
• MIME headers: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Extensions: bin, enc, hex, hqx, mim, mime, uue.
• MIME headers: 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

• Extensions: exe, cmd, bat, com.
• MIME headers: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Extensions: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• MIME headers: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

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

Plugin files

• Extensions: 8bi, arx, crx, plugin, vst, xll.
• MIME headers: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

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

Video files

• Extensions: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• MIME headers: 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

• Extensions: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME headers: application/atom+xml.

Use optional email journaling with data protection in mind

Give the journal entry a clear name and save the recipient selection and journal destination with Save before starting the following tests.

Under Email > General settings > Email journaling > Add, SFOS can send copies of inbound SMTP/S messages for selected recipients or address groups to a separate journal address. Selecting Any captures all inbound messages. The function applies only to SMTP/S; it does not journal POP or IMAP traffic.

Journaling creates an additional email copy. It is not automatically a tamper-proof archive and does not prove that legal retention obligations are met. Before enabling it, define the purpose, authorized recipients, access to the journal mailbox, encryption, retention period, storage requirements, and responsible owner.

For the first test, select a single test mailbox instead of Any. An inbound message to this mailbox must appear at the normal destination and in the journal mailbox; a message to a recipient outside the selection must not create a journal copy. The journal address must not trigger a mail flow that sends the copy back to SFOS and creates a loop.

Only extend the recipient selection after the positive and negative tests. For rollback, remove the journal entry or restore the documented previous state. Copies already delivered remain in the journal mailbox and must be handled according to its own retention rules.

Safely map legacy mail objects via the XML API

The XML API references for SFOS 22 and 23 describe separate legacy mail objects. A menu path from MTA mode, a flat parameter table or a sample with slash-separated alternatives is not a request ready to copy and use. Secure XML API access explains API access, transport, operation statuses, unresolved message keys and checks after writing. The mappings below help you read an existing configuration and do not automatically apply to REST or the Central API.

Before making a change, save a backup, the current object content, referencing policies and their order. Clarify the specific request and conflicting field values using the API help for the installed build or with Sophos Support. Afterwards, check the saved objects and the actual effect on email separately. A required field in the table does not establish whether omitting other fields preserves their previous values. Nor does it establish how lists are cleared, replaced or merged, or whether changes are atomic.

EmailConfiguration: protocol and TLS context belong to the field

Under EmailConfiguration, fields with the same name are distinguished by their parents:

• GeneralSettings/EmailSignature and GeneralSettings/EmailBannerMode concern the outbound banner. The API table lists the mode values inline_plain, mimepart and off; the sample instead contains alternatives resembling UI labels. Do not treat these texts as identical API values without checking. EmailSignature is a string with a maximum of 2000 characters according to the API table.
• SMTPSSettings/DontScanEmailsGreaterThan is the SMTP scan limit in KB; SMTPSSettings/ActionForOversizeEmails is the separate action Accept, Reject or Drop. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings and the six DoS limits are also located in SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan is a different integer limit in KB. POPIMAPSettings/RecipientHeaders/Header is a list of header strings for recipient detection, not an SMTP recipient list.
• SMTPTLSConfiguration and POPSIMAPTLSConfiguration each contain their own TLSCertificate, AllowInvalidCertificate and DisableTLS1. The SMTP certificate does not replace the POP/IMAP certificate. RequireTLSWithHost, RequireTLSWithSenderDomain and SkipTLSHosts are in the SMTP TLS context; they are separate lists of strings, not a shared on/off exception. Do not confuse the UI limit of 512 host entries with the API table’s maximum of 512 characters.

Keep the API table, sample and UI reference separate: The API table lists 1024 as the default for both scan limits. For MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate and ConnectionsRate, it lists 5000, 100, 100, 100, 1000 and 100, respectively. The sample instead uses 1000 for MaximumEmailsConnection; the UI example of 2048 KB explained above is not a default either. The meaning of 0 remains the protocol-specific UI reference described above, not an unlimited setting inferred from the API sample.

The API table permits 1 to 512 for MaximumRecepientsEmail, whereas the UI reference lists 1 to 256 for Maximum recipients/email. The API spelling MaximumRecepientsEmail remains unchanged; infer neither a corrected field name nor that 512 is safely valid in the UI. The other five DoS ranges agree with the UI ranges stated above. The saved state and the help for the target build remain authoritative.

Further conflicts prevent blind adoption of the sample: For VerifySendersIPReputation, the table lists on/off and gives Disable as the default, whereas the sample shows Enable. For SMTPSDosSettings, the datatype INTEGER appears alongside the table default Disable and the sample value Enable. According to the table, BypassSpamCheck defaults to Disable, but the sample enables it. Both TLS contexts allow invalid certificates in the sample. Neither adopt these unsafe sample settings nor construct a supposedly valid payload from the conflicting information; the safe TLS and bypass decisions described above remain in place.

For the Email Configuration operation, 200 with Message.AVGeneralConfUpdateSuccess, 500 with Message.AVGeneralConfUpdateFail and 505 with Message.ASConfigSubOperationFail are documented. SFOS 23 adds the mapping of 506 to Message.AVGeneralConfInvalidSmtpNtfyHostname already explained above. These are operation statuses and unresolved keys, not HTTP codes or confirmed runtime texts. In particular, after 505, first read back the SMTP, POP/IMAP and TLS settings; assume neither a complete rollback nor complete saving, and do not blindly repeat the operation.

SMTP malware: treat recipients and administrators independently

The object is called AntiVirusMailSMTPScanningRules. Name identifies the policy, and After/Name is the predecessor reference shown in the sample. SenderList/Sender and ReceiverList/Receiver are separate lists; BlockFileTypes/FileType is the list of blocked file types. The API table also lists WhiteList as a MIME list, but shows no corresponding nesting in the sample. Do not invent an additional XML parent node from this.

For Scanning, the API table lists Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) and Disable, with a default of Disable. The sample’s Disable/Disable is neither a complete enum nor a usable value for the intended antivirus scan. Quarantine and NotifySender are separate switches with Enable/Disable; according to the API table, both default to Disable. These table values replace neither the existing default policy nor evidence of the current scan status.

For infected, suspicious and protected attachments, there are two independently selected actions in each case:

• Recipients: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment with Don'tDeliver, DeliverOriginal or RemoveAndDeliver.
• Administrators: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment with Don'tDeliver, SendOriginal or RemoveAttachment.

The API table lists Don'tDeliver as the default for all six action fields. This is not equivalent to the UI description of a default notification for protected attachments and does not establish the current delivery state. The effects and limitations explained above remain decisive: DeliverOriginal or SendOriginal can pass on unscanned or dangerous attachments; quarantine is not proof that delivery to the recipient is suppressed. The unresolved administrator option RemoveAttachment remains excluded, even though the API lists it as a value. Check sender, recipient, administrator and quarantine outcomes separately.

AntiSpamRules: do not confuse matching, order and action

For AntiSpamRules, Name identifies the rule. After/Name is the reference shown in the sample for its position after another rule. Before Add, Edit or Order, save the actual order and the referenced rule name; this documentation does not automatically describe syntax for the first position or for predecessors that do not exist.

RecipientList/Action with RecipientEmail and SenderEmailList/Action with SenderEmail separately control recipient and sender matching. The API table lists Equals or Contains for both match actions, with a table default of Contains. They are not the delivery action. MarkSpamIf, by contrast, contains Condition and the corresponding OtherHeader, Operator and MatchIs. A message size needs a size comparison; a header needs a text match; a classification needs a classification value. The flat table row describes MatchIs as an integer message size, but the sample uses Spam. Do not conclude from this that every condition type is numeric. The table value 4 and the differing condition identifiers in the sample are not a basis for inventing a header or enum mapping.

SMTPAction/Action and SMTPAction/ActionParameter determine the SMTP action and its additional value; SMTPAction/Quarantine is separate from them. POPIMAPAction/Action and POPIMAPAction/ActionParameter belong to the retrieval path, whose sample shows only Accept and Prefix Subject. Do not transfer an SMTP action to POP/IMAP. For Change recipient, the parameter is the replacement delivery destination, not an additional journal address. The restrictions described above for outbound Data Control and SPX remain in place.

Here too, the sample and table conflict: For Quarantine, the sample shows Enable/Disable, while the table permits 0 and Enable. The SMTP action table also lists Accept With SPX; do not infer this API spelling from the UI label or a normal Accept. Before a write call, clarify the specific condition-dependent value rather than sending the slash-separated sample alternatives.

For Order SMTP Scanning Policy, the entries are 200 with Message.SpamRuleUpdateRuleOrderSuccess and both 500 and 505 with Message.SpamRuleUpdateRuleOrderFail. The same key therefore identifies two status rows; it does not explain their cause. For Add SMTP Scanning Policy, 502 with Message.SpamRuleRecordExists is documented. Before another Add or Order, check the existing name, content and saved order; the central API safety checks and the positive and negative policy tests apply here too.

DataControlList: signatures are not yet a delivery action

The legacy object DataControlList contains Name and Signatures/Signature, a list of CCL signature names. The flat table uses the labels name and signaturename for these; it is not a reason to silently rename the XML tags shown in the sample. The table lists the name as a required string with a maximum of 255 characters and the signatures as an optional list of strings. Use the actual signature name from your own available CCL selection, rather than copying it from the country example. The action still comes only from the linked policy. Do not use the different object MTADataControlList instead of this legacy object.

For Add Data Control List and Update Data Control List, both references list 502 with Message.DLPAddSameName and 545 with Message.MTAModeDisableCheck. 545 is a documented status/key mapping, not a verified statement that legacy mode prohibits this function or that a mode change is required. Therefore, do not switch modes to troubleshoot it. Check the saved list and its references before another Add or Update, and clarify the actual response using the help for the installed build or with Sophos Support.

AVASAddressGroup: exactly one type-dependent branch

AVASAddressGroup is the legacy address group for these mail rules, not an equivalent object established by an MTA menu path. Name identifies the group; the API table lists a maximum of 50 characters, and a maximum of 255 for the optional Description. The GroupType table lists RBLIPv4, RBLIPv6, IPAddress and EmailAddressOrDomain, whereas the sample simply uses RBL. Do not silently normalise these spellings.

The sample comment requires exactly one branch matching the type: RBLList/RBLName or RBLFile, IPAddressList/IPAddressNetwork or IPAddressFile, or EmailAddressList/EmailAddressDomain or EmailAddressFile. The list entries are strings; the table specifies multiple values and ignored duplicates. The sample shows the alternatives together, but is not an instruction to send all lists and files. For email/domain groups, EmailImportType distinguishes the values Manual and Import. The table lists the formats csv and txt for EmailAddressFile, but contradictorily describes the field as manual input; the sample refers to the filename of a multipart request. Neither establishes a complete multipart binding or a safe import call. Clarify these details for the specific build before importing.

For Add Address Group, 502 with Message.AddrGrpRecordExists, 541 with Message.AddrGrpImportFailed, 542 with Message.AddrGrpEmptyFile1 and 543 with Message.AddrGrpSomeEmailNotImported are documented. Infer neither the entries actually imported nor a complete rollback from the unresolved keys. Compare the saved members with the intended list before the next import.

For Delete Address Group, 504, 505 and 506 have the same key, Message.AddrGrpForeignKeyExists; 507 is linked to Message.AddrGrpEmailArcKeyExists. The keys do not reliably distinguish the individual referencing objects. Inventory policies and journal references before deletion, evaluate the exact operation response and check afterwards whether the group exists. Do not blindly remove a linked protection policy to force a delete call.

TrustedDomain, journaling and engine selection have different scopes

AntiSpamTrustedDomain/DomainList/DomainName is a list of domain strings. Add and Delete use DomainName as the list identity. The API description refers to a scan bypass for mail from trusted domains, but does not identify exactly which scanners are bypassed. The UI describes Spam check exceptions as a spam bypass. Extend neither statement into a guarantee for all scans or proven exact API/UI equivalence. Manage domains only with a documented purpose and a narrow scope; check the list and expected protection effect before and after Add or Delete. Do not invent a missing complete XML request from the Delete page.

AntiSpamEmailArchiver, by contrast, creates copies: Name names the entry, RecipientList/Recipient restricts the original recipients, and SendCopyOfEmailTo is the separate copy address. According to the API table, name, recipient and copy address are required; name and copy address may contain a maximum of 50 characters. The recipient row is described as a scalar string, while the sample shows it within a list parent node. Do not resolve this discrepancy with an invented catch-all payload. The single-mailbox pilot described above, including data protection, loop prevention and a negative test, also applies to automation; changing a recipient is not changing the copy address.

MalwareProtection/PrimaryAntiVirusEngine is, in turn, a global scalar engine selector, not a recipient filter or an individual scan policy. The API table lists Sophos as the default; the sample’s Sophos/Avira shows alternatives, not a combined value to send. The effect of Avira on Zero-day Protection in single-antivirus SMTP policies explained above must still be checked. Check the globally saved value and all affected policies after a change; separate documentation routes do not make these independent engine configurations.

Combine NAT and firewall rules

Publish the inbound SMTP path

For inbound email, a DNAT rule translates the public WAN address to the internal mail server. Restrict Original Source as tightly as the mail design permits; Original Destination is the intended public address; Translated Destination is 10.20.30.25 or the actual mail server. Original and translated service remain limited to the SMTP ports actually offered.

Under Rules and policies > NAT rules, choose the appropriate IP family and open Add NAT rule. An IP host object for the internal server must exist under Hosts and services > IP host for it to appear under Translated destination (DNAT). In the simple inbound example, Translated source (SNAT) and Translated service (PAT) remain Original; under Original service, select only SMTP services in use, such as SMTP and SMTP[S]. Check all fields before saving with Save. NAT destination translation is not equivalent to the separately qualified firewall field Destination networks below.

A reflexive rule also creates SNAT for the reverse direction. Select it only if this exact public source identity is intended for the outbound path. Multiple WAN links, smarthosts, or different provider routes require their own routing and SNAT design. General ordering and the destination zone after NAT are explained in Publish a server with DNAT.

Use two tightly scoped firewall rules

To create a rule under Rules and policies > Firewall rules, select the actual protocol family IPv4 or IPv6 and open Add firewall rule > New firewall rule. Specify the name and required fields, then save with Save. Do not reuse this article’s IPv4 example addresses in an IPv6 rule.

⚠️ The descriptions conflict for Destination networks: the legacy email example names the internal mail server, while the general DNAT rule workflow bases firewall matching on the original public destination. This guide does not resolve the specific proxy case by guessing. Document the already proven inbound rule match and retain it for the pilot. Do not derive a new production inbound rule from either mapping or change the destination on speculation. For a new path, clarify this with Sophos Support or suitable controlled verification before approval, and substantiate it with Rule ID, DNAT hit, and captures before and after translation. The outbound SNAT variant does not resolve this conflict.

For validation, separate rules are easier to understand than one bidirectional rule containing several zones and Any objects:

• Inbound: WAN to the internal mail server zone, SMTP endpoint 10.20.30.25, only required SMTP services, logging enabled. The endpoint is not a prescribed value for the unresolved Destination networks field.
• Outbound: internal mail server zone and host to WAN or the specific smarthost, only required SMTP services, logging enabled

Under Scan email content, turn on Scan SMTP in both required directions and Scan SMTPS only when SMTPS is actually used. If the standard port for the selected protocol is missing from Services, SFOS offers Add ports. For a nonstandard port, define the matching service deliberately instead. Service, NAT, server listener, and scan option must describe the same port path; Add ports does not replace that check.

Place the rules above more general rules that already match the same traffic. After saving, the logged Firewall Rule ID is decisive. Rule structure, NAT zone, and order are covered in Configure Sophos Firewall rules safely.

Optional: use a different public source address outbound

This setup applies to forwarded SMTP traffic from the internal server, not system-generated MTA messages. It is useful when a different assigned public identity is required instead of the WAN MASQ address. Provider allocation, routing, SPF, RDNS and provider authorisation must fit that identity; SNAT does not change these prerequisites.

1. Under Network > Interfaces > Add interface > Add alias, select the actual physical WAN interface, IP version IPv4 and the assigned address with the appropriate IPv4/Netmask; Save. Provider path, Device Access and alias checks are covered in Configure an alias IP.
2. Under Hosts and services > IP host > Add, create a named host for the same public address: IP family IPv4, Type IP, IP address the assigned address; Save. A host object alone does not bind an address to the interface.
3. Under Rules and policies > NAT rules > New NAT rule, restrict Original source to the actual internal mail server and set Translated source (SNAT) to the public IP host. Restrict Original destination to the required mail destinations or smarthost and Original service to the required SMTP services. Translated destination (DNAT) and Translated service (PAT) remain Original. Inbound interface and Outbound interface must match the actual server-to-WAN path. Save with Save and place it above other SNAT rules that also match; check NAT and firewall order separately. NAT basics explains first matching rule behaviour. Any, Top, Port1 and Port2 in examples are not mandatory values.
4. Under Rules and policies > Firewall rules > Add firewall rule > New firewall rule, create a suitable outbound IPv4 rule or check the existing narrow rule: Action Accept, actual server zone and server host as source, WAN and required destinations, only required SMTP services, Log firewall traffic enabled. Select Scan SMTP and, where applicable, Scan SMTPS as above; Save and check firewall order independently of NAT.
5. Create a new SMTP connection to a controlled external recipient. Check Firewall Rule ID, NAT Rule ID, translated source IP in capture or at the external recipient and actual delivery together. An existing session or SMTP port test is insufficient. Also negatively test a source outside the scope or a service that is not allowed.

For reversal, first restore the documented rules and their order, then check the previous source IP and delivery using a new connection. Remove the alias and IP host only when no other service depends on them.

In the outbound firewall rule, During scheduled time determines when that rule applies. Deliberately choose All the time for an always-available mail server. A restricted schedule can change the rule match outside its window; check Rule ID and mail flow there too. This is not a schedule for the SNAT rule. The firewall rule automatically created when MTA mode is enabled belongs to a different mail flow and is not edited as a replacement for this legacy server rule; use the MTA runbook for that path.

Validate mail flow and proxy scanning

First send a small external message to a test mailbox. Then have the internal mail server send a second message to a controlled external recipient. Give both tests unique subjects and UTC timestamps.

For STARTTLS on port 25 and a direct TLS connection on port 465, the following read-only checks from an authorized test system can help:

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

Replace mail.example.net with the actual FQDN and test only ports that are really offered. These OpenSSL commands display the presented certificate chain and negotiated TLS parameters; inspect any certificate verification errors. They do not explicitly verify the expected hostname and can continue despite verification errors, so a connection is not proof of successful certificate authentication. They prove neither successful mail delivery nor malware, spam, or data control scanning.

In Log Viewer, source, destination, service, action, and Firewall Rule ID must match the new rules. For the legacy SMTP/S proxy, correlate awarrensmtp.log and awarrenmta.log with the same timestamp. The log files are explained in Sophos Firewall services and logs.

Then perform separate negative tests for firewall-rule scope and message-policy matching. A source or service outside the pilot scope must not match the pilot firewall rule and must follow its documented allow or block outcome; another authorized rule may still provide protection. A test message without the pilot policy criterion must not match that policy or receive its specific action, while retaining any applicable default or other scanning. For each case, record the expected Firewall Rule ID, policy, and delivery outcome and compare them with the observed result. Do not use real malware in production testing; use established harmless test patterns and a controlled mailbox for scan validation.

Troubleshoot by symptom

SMTP works, but the policy does not apply

Check the Firewall Rule ID first. If another rule matches, correct the order, source, destination, NAT target, and service. If the expected rule matches, Scan SMTP or Scan SMTPS, policy order, and sender and recipient groups must fit the test. A policy alone does not activate the transparent proxy.

Inbound mail does not reach the server

Check the public destination address, DNAT hit, translated destination, destination zone, server listener, and return path separately. An open TCP connection to the firewall does not prove that DNAT and the firewall rule reach the internal server. Packet capture and Rule ID must show ingress and forwarding.

Outbound mail uses the wrong public IP address

Check SNAT, the reflexive rule, WAN gateway, SD-WAN route, and reply packet behavior. The legacy proxy does not automatically select the public source address required for SPF, RDNS, or provider authorization. Prove the specific path before making a global route precedence change.

TLS fails after scanning is enabled

Record the FQDN, destination IP, certificate, issuer, chain, and negotiated version. With multiple domains on one IP address, the documented IP-based certificate check can be the cause. Do not enable Allow invalid certificate as a quick fix.

A message is missing and nothing appears in the MTA spool

This is not a useful success criterion in legacy mode because mail spool and MTA-specific mail logs belong to MTA mode. The relevant chain here consists of the firewall rule, NAT, SMTP server logs, Log Viewer, awarrensmtp.log, and awarrenmta.log. Check quarantined messages separately under Email > SMTP quarantine.

Roll back safely

For rollback, first restore the pilot rules and scan options to their documented previous state. Then remove new policy assignments or restore their order. Remove temporary DNAT, SNAT, or certificate changes only when no other service depends on them.

Only then restore the SMTP deployment mode if the change included that switch. The original inbound and outbound mail flow must work again with the expected Rule IDs, public addresses, and server logs. Do not delete messages, quarantine contents, or proxy logs as a standard rollback action.

Operations checklist

• Transparent proxy operation is a deliberate choice and MTA requirements have been excluded.
• Backup, management access, and original Rule IDs are documented.
• SMTP hostname, SMTP and POP/IMAP size limits, oversize action, IP reputation, and DoS limits are justified.
• Standard or alternative ports in use and POP/IMAP recipient headers match the actual server path.
• The primary antivirus engine and its effect on Zero-day Protection in single-antivirus policies have been checked.
• Certificate, TLS exceptions, and affected domains have been checked.
• DNAT, SNAT, destination zone, and actual server ports match.
• Inbound and outbound firewall rules are tight, logged, and proven to match.
• Default and custom policies have a traceable order.
• Optional journaling is limited to the required recipients and has a documented data-protection and retention purpose.
• Positive, negative, TLS, and delivery tests have passed.
• Legacy proxy logs and mail server logs can be correlated by time.
• Owner, review date, and complete fallback path are recorded.

FAQ