Protecting a mail client's IP address
A mail submission server can record the connecting client's address in a Received header. Sending directly to a remote mail server can therefore expose an unprotected source address, even when your public service uses DDoS protection. If you submit mail directly from an address you want to keep private, inspect a delivered test message to see what your mail server exposes.
This may look something like:
Received: from localhost (something [1.1.1.1])
by mail.domain.com (Postfix) with ESMTP id 25EDB8AA2F
for <abc@gmail.com>; Sun, 14 Jun 2015 14:20:13 -0400 (EDT)
Client-session privacy concerns authenticated mail submission, usually on ports 587 or 465. Internet mail relay on port 25 needs normal trace information. Mail submitted locally or through a private network can still contain identifying information added by other software.
Choose the instructions for your mail-server installation. Back up its configuration and identify the installed version before changing it.
Postfix
Postfix 3.10 and later
Postfix 3.10 introduced smtpd_hide_client_session. It produces a Received header with client-session details omitted while retaining the server's trace entry.
1. Check the installed version and services
Run as the mail-server administrator:
postconf mail_version
postconf smtpd_hide_client_session
postconf -M
If the parameter is unavailable, use your distribution's supported upgrade path or obtain version-specific guidance. Preserve the existing configuration until a supported approach is established.
2. Configure the submission services
Edit the existing submission service entries in master.cf, normally /etc/postfix/master.cf on Debian and Ubuntu. Use postconf -h config_directory to find your installation's configuration directory. Add this override to each intended authenticated submission service on port 587 or 465:
-o smtpd_hide_client_session=yes
Keep the existing authentication, TLS and relay restrictions. Retain smtpd_hide_client_session=no for the port-25 SMTP service. The override belongs under the selected service entry, alongside its other -o settings.
3. Check and reload
postfix check
postfix reload
Resolve configuration errors before reloading. Then complete the delivered-message checks below.
Existing header-check rules
Review existing header_checks and mime_header_checks in main.cf before changing them. Edit an existing setting rather than adding a duplicate entry. Keep unrelated filtering rules intact. Remove broad trace-header or MIME-Version deletion rules if they were added solely by an older version of this tutorial.
regexp: tables are read directly. They need no indexed-map build; a lookup can be tested with postmap -q 'sample header' regexp:/path/to/checks. Reload after changing a table so running processes use the updated rules.
Zimbra
Zimbra installations
Zimbra normally installs beneath /opt/zimbra and manages its bundled Postfix configuration. Use the configuration mechanism supported by your installed Zimbra release so changes survive service restarts and upgrades.
1. Inspect the installation
As the zimbra service user, record the release and effective Postfix settings:
zmcontrol -v
postconf mail_version
postconf header_checks mime_header_checks
zmprov gcf zimbraMtaHeaderChecks
Check for server-specific overrides as well as global settings. Paths and bundled Postfix versions vary between releases.
2. Select a supported privacy setting
If the bundled Postfix supports smtpd_hide_client_session, have the Zimbra administrator apply it to authenticated submission through that release's supported service-configuration mechanism. Keep normal port-25 trace behavior.
For older bundled versions, obtain release-specific guidance from Zimbra before changing trace headers. Direct edits to generated main.cf or assumptions about /opt/zimbra/postfix paths can be overwritten or target the wrong installation.
3. Preserve managed header checks
Zimbra exposes header-check configuration through zimbraMtaHeaderChecks. Preserve existing checks and any server-level override. Its published header-removal example is marked as requiring specialist review; choose rules for a specific privacy requirement and test their effects rather than copying the entire example.
4. Apply and verify
Apply changes and restart the MTA using the procedure for the installed release. Check the effective Postfix configuration after the restart, then complete the delivered-message checks below. Recheck persistence after the next supported configuration regeneration or upgrade.
Other identifying headers
Mail clients can also add X-Originating-IP and X-Mailer. In an existing header-check table scoped to the intended submission path, these rules remove those optional headers:
/^X-Originating-IP:/ IGNORE
/^X-Mailer:/ IGNORE
Keep unrelated checks in the file, and merge the configuration with existing settings rather than creating duplicate main.cf entries. Confirm the table's scope before applying it; removing signed headers can affect DKIM verification. Zimbra installations must use their release's managed header-check configuration. These rules do not remove Received or MIME-Version.
Verify delivered messages
- Submit a test message through each configured authenticated submission service and inspect the full headers at an external recipient.
- Confirm that the intended client-session details are omitted and server trace information remains.
- Test inbound delivery on port 25 and verify its normal trace headers.
- Test an attachment and check MIME rendering and DKIM verification after all mail-processing stages.
- Review other headers and message content for addresses added by the mail client or another relay.
ESMTPSA denotes encrypted, authenticated ESMTP. A header containing that text alone is insufficient to identify a trusted submission session for a global deletion rule.
References: Postfix client-session privacy, Postfix regexp tables, Zimbra header-check guidance, SMTP trace requirements and ESMTP transmission types.
