Scan and test POP3 and IMAP on Sophos Firewall

Sophos Firewall can scan emails as clients retrieve them over POP3, POP3S, IMAP, and IMAPS. Creating a POP-IMAP policy alone isn’t enough. Only a matching firewall rule directs the mail traffic through the proxy and activates the configured scanning and TLS settings.

The most important acceptance test is therefore not a green toggle, but an actual retrieval from the intended client to the intended mail server. The Firewall Rule ID, port, certificate chain, negotiated TLS version, and warren.log must all match the planned path.

⚠️ Without Scan email content in the firewall rule that actually matches, SFOS doesn’t apply the POP/IMAP settings or policies. A policy on its own provides no protection.

POP/IMAP scanning in eight steps

1. Document the client network, mail server, protocols, and ports actually in use.
2. Select a single pilot source and test its existing mail retrieval.
3. Import the CA that issued the mail server certificate under Certificates > Certificate authorities if it isn’t already trusted.
4. Set POP/S and IMAP/S settings and POP and IMAP TLS configuration under Email > General settings.
5. Only if required, create a POP-IMAP scan policy under Email > Policies and exceptions for senders, recipients, or message characteristics.
6. Create a narrow, logged firewall rule for the pilot client and mail server and enable the required protocols under Scan email content.
7. Verify retrieval, the TLS connection, Firewall Rule ID, and warren.log with a small test message.
8. Add more clients only after positive and negative tests, and document the rollback path.

What the POP/IMAP proxy protects

POP3 and IMAP retrieve and manage messages in a mailbox. They aren’t SMTP, which transports messages between a sender, MTA, and mail server. The MTA mode guide therefore explains MX, SMTP routing, relay, spool, and SMTP quarantine; this guide focuses on a client’s mail retrieval.

SFOS distinguishes the unencrypted or STARTTLS-upgraded ports from the variants that use TLS from the start:

• POP3: TCP 110, with an optional upgrade to TLS using STARTTLS
• POP3S: TCP 995, TLS from the start of the connection
• IMAP: TCP 143, with an optional upgrade to TLS using STARTTLS
• IMAPS: TCP 993, TLS from the start of the connection

New designs should use encrypted connections for mail clients. Selecting a protocol in SFOS doesn’t change the client configuration, however. If the client uses a different port or bypasses the planned rule, that traffic isn’t automatically protected by the selected standard option.

POP/IMAP scanning requires a valid Email Protection license. It doesn’t replace protection on the mail server or scanning when a message arrives over SMTP. Especially with cloud mail services, first confirm whether the provider still allows conventional POP/IMAP retrieval and whether a transparent proxy is compatible with its TLS and authentication requirements.

Define the example and test boundary

A controlled pilot prevents an incorrect certificate or rule configuration from affecting every mail client at once. This example uses documentation values:

• pilot client 10.20.30.50 in the LAN zone
• mail server mail.example.net
• destination address 192.0.2.25
• protocol IMAPS on TCP 993
• firewall rule Pilot_POP_IMAP_Scan

Replace 10.20.30.50, mail.example.net, and 192.0.2.25 with the real values. The destination address is part of the TEST-NET documentation range and must not be used as a production server address. The pilot should use a dedicated test mailbox, not an administrator’s only account.

Before the change, retrieve a message and record the current certificate issuer. Also preserve the existing firewall rule, its rule counter, and the client configuration. This makes it possible to distinguish a routing, TLS, proxy-scanning, or mail-server problem later.

Prepare TLS and scan limits

CA and certificate validation

Under Certificates > Certificate authorities, add the CA that issued the mail server’s certificate if the firewall doesn’t already trust it. Private CA files must only come from the organization’s own PKI or another verified source. Import certificates on Sophos Firewall explains the general import and chain check.

Then select the intended TLS certificate under Email > General settings > POP and IMAP TLS configuration. Keep Allow invalid certificate disabled. Disabling validation doesn’t repair an invalid, expired, or untrusted peer.

According to the SFOS help, Disable legacy TLS protocols turns off protocols earlier than TLS 1.1. The option doesn’t prove that a specific session uses TLS 1.2 or TLS 1.3. If the security standard requires at least TLS 1.2, verify the negotiated version in the real client path. If the deployed combination can’t meet that requirement, stop the rollout and evaluate a different protection architecture.

Because the firewall processes encrypted mail traffic for scanning, a certificate warning may become visible on the client. Don’t dismiss a new warning. Check the presented name, issuer, chain, and client trust and resolve the cause before a broad rollout.

Message size and recipient headers

Under POP/S and IMAP/S settings, Don’t scan emails greater than sets the maximum message size for scanning. For POP/IMAP, 0 doesn’t mean unlimited; according to the SFOS help, it sets the limit to 10,240 KB. Larger messages aren’t scanned. Choose a limit that reflects typical attachments, available performance, and the accepted residual risk.

The Recipient headers help SFOS identify recipients for POP/IMAP policies. By default, the firewall uses Delivered-To, Received, and X-RCPT-TO. Add another header only if the actual mail server sets it reliably. A fabricated or subsequently removed header otherwise creates policy matches that are difficult to understand.

Create an optional POP-IMAP policy

With an active Email Protection subscription, SFOS automatically applies the default policy default-pop-av to POP3/S and IMAP/S traffic. It removes virus-infected attachments and replaces the message body with a notification. Account for this automatic baseline policy during testing and troubleshooting before attributing the behavior to a custom policy.

A POP-IMAP policy adds criteria and user-facing warnings. Under Email > Policies and exceptions > Add a policy > POP-IMAP scan, first set a name and the sender and recipient groups. The policy can then react to a spam classification, source IP or network, message size, or a header, among other criteria.

The documented actions are Accept and Prefix subject. Prefix subject delivers the message and adds a notice to its subject. The policy therefore isn’t a general quarantine or blocking rule. If None is selected as the criterion, the action applies to all messages between the specified senders and recipients. Review that scope consciously before saving.

The additional policy can be omitted for the first technical proxy test. This keeps it clear whether the basic TLS, firewall rule, and scanning chain already works. Add a policy only when sender, recipient, or header logic is actually required.

Create the firewall rule for mail retrieval

Create the rule under Rules and policies > Firewall rules. It should contain only the intended client network or pilot host, the mail server destination, and the mail ports that are actually required. A general LAN-to-WAN rule with many security features is difficult to assess during acceptance testing.

The following values fit the Pilot_POP_IMAP_Scan example:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: the zone of the mail server path, usually WAN for an external server
• Destination networks: host object for 192.0.2.25 or the real mail server
• Services: IMAPS
• Log firewall traffic: enabled

Under Scan email content, enable Scan IMAPS. If the environment actually uses additional protocols, also select Scan IMAP, Scan POP3, or Scan POP3S. Add ports adds the corresponding services; they must then appear under Services in the rule.

Place the rule above a more general rule that already matches the same client and mail server. After saving, the actual Firewall Rule ID in Log Viewer is decisive, not the expected position in the rule table. Configure Sophos Firewall rules safely explains rule construction, order, and Rule ID validation.

Test the complete path

First place a small, harmless message in the private test mailbox. The pilot client retrieves it through the intended FQDN and port. In Log Viewer, source IP, destination IP, service, action, and Firewall Rule ID must match the new rule. A counter increase on a different rule is a stop condition.

For certificate and TLS validation, the following read-only connections can be run from a client in the same network, for example:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Only test protocols the mail server actually provides. Replace mail.example.net with the real FQDN. The output confirms the certificate, chain, and TLS parameters, but not a successful login or content scan. End the interactive connection with Ctrl+C after checking it.

Then repeat the retrieval with the actual mail client. Use warren.log for proxy analysis; Log Viewer and Packet Capture additionally show the rule match and network path. Record the timestamp, client IP, server IP, port, and test subject together. Sophos Firewall services and logs maps the log file and explains safe access.

A reliable acceptance test also includes a negative case. A pilot host that isn’t allowed or a port that isn’t selected must not accidentally receive the same protection through another broad scan rule. If a specially prepared test peer with an invalid certificate chain is available, it must fail while Allow invalid certificate is disabled; don’t create a certificate fault on the production peer for this test.

Troubleshoot by symptom

Retrieval works, but the proxy doesn’t scan

Check the Firewall Rule ID first. If a higher or more general rule matches, correct the order, source, destination, and service. If the intended rule matches, the corresponding Scan IMAP/IMAPS/POP3/POP3S option and port must be active under Services. A POP-IMAP policy alone doesn’t activate the proxy.

The mail client reports a certificate error after activation

Record the presented FQDN, issuer, validity, and complete chain. Then check the CA selected under POP and IMAP TLS configuration and the client’s trust. Don’t enable Allow invalid certificate as a permanent workaround. If it remains unclear which certificate the proxy or server presents, roll back the pilot before affecting more clients.

STARTTLS works, but POP3S or IMAPS doesn’t

Check the ports and connection modes separately. POP3 on 110 and IMAP on 143 switch to an encrypted session only with STARTTLS; POP3S on 995 and IMAPS on 993 start with TLS. The mail client, server listener, firewall service, and enabled scan option must use the same variant.

A large message is delivered but isn’t scanned

Compare Don’t scan emails greater than with the actual message size. Even 0 limits POP/IMAP scanning to 10,240 KB. Don’t blindly increase the limit for a single test without assessing the effect on performance and accepted risk.

The subject prefix is missing

Check the sender and recipient group, match type, criterion, and Recipient headers. The message may have been scanned technically even though the optional policy didn’t match. Evaluate proxy operation and policy action separately.

Operation and rollback

After a successful pilot, add clients gradually. Monitor rule counters, warren.log, TLS errors, and helpdesk feedback during rollout. Changes to the mail server certificate, FQDN, port, or client profile belong in the same change process afterwards because they alter the validated path.

For rollback, first remove the pilot from the narrow rule or disable the corresponding scan option. Confirm that the original mail retrieval works again and that the expected previous rule matches. Remove an imported CA or a global POP/IMAP setting only if no other service uses it. Don’t delete messages, logs, or certificates as a standard rollback step.

FAQ