Like Zimbra, by default outbound email messages in Carbonio include detailed email client information like client IP address (gasp!) and X-Mailer headers. I am not going to paste my own from tests, but just some semi-sanitized stuff that is already on the internet, further below, to illustrate what I mean.
Thought to quickly share the fix, so others can easily achieve the same result, and maintain a reasonable sense of privacy, just like the big email providers like Gmail and Microsoft 365 offer. If you are a Carbonio admin and think removing this header information will prevent you from identifying abuse from your Carbonio account holders, it doesn't. It will require you to dig into logs, rather than just have that info for everyone in the world to see (and potentially abuse themselves).
Edit the following file as zextras user (or as root/with sudo):
/opt/zextras/conf/postfix_header_checks
to add the following:
removed link ESMTPSA/ IGNORE
/^X-Originating-IP:/ IGNORE
/^X-Mailer:/ IGNORE
/^Mime-Version:/ IGNORE
/^User-Agent:/ IGNORE
save the file, then issue the following commands as zextras user:
postmap /opt/zextras/conf/postfix_header_checks
postfix reload
That's it, now your home, work Wi-Fi (or secret lover's home) IP address won't show, as in below. 😀
Received: from smtpclient.apple ([174.29.38.75]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MS4Ue-1ps3Qv0vMo-00TGuw for <s*******@gmail.com>; Mon, 27 Mar 2023 03:59:55 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-4CA8FB79-EFCA-45D8-8F6C-5C5613F2A8B1 Content-Transfer-Encoding: 7bit From: Ronnpj <r@.com> Mime-Version: 1.0 (1.0) Subject: Re: March 25 Lumberjack Date: Sun, 26 Mar 2023 19:59:44 -0600 Message-Id: <3384AA9E-1D11-4181-A0ED-81161C448180@*.com> References: <CAKyN-DSNJvrT2iEfWcYX27LECOpGo3tid6MKEPqjjKVWePVirQ@mail.gmail.com> In-Reply-To: <CAKyN-DSNJvrT2iEfWcYX27LECOpGo3tid6MKEPqjjKVWePVirQ@mail.gmail.com> To: S* <s******@gmail.com> X-Mailer: iPhone Mail (20D67)
That's great. Thanks for your insight and I believe it would help users to strengthen their server security.
🙏
Could it be that this procedure doesn't work with Carbonio 25.9.0?
The file /opt/zextras/conf/postfix_header_checks is readonly and, after forcing the write to modify it, the command systemctl reload carbonio-mta.target re-wrote it, deleting the changes I made and reverting to the "original" text.
What would be the correct procedure for this changes in Carbonio 25.9.0?
This issue could be linked to linked to this topic: https://community.zextras.com/forum/postid/11401/
So I would recommend you to test this on a different version of CE (Not 25.9.1), if possible or wait to for the response from the devs.
Thanks
If anyone comes across this post, there is a solution to this problem:
The 'postfix_header_checks' will be indeed overwritten. You have to create an additional config file e.g. 'postfix_custom_header_checks' and add it to the zextras config:
zmprov mcf zimbraMtaHeaderChecks 'pcre:/opt/zextras/conf/postfix_header_checks, pcre:/opt/zextras/conf/postfix_custom_header_checks'
Found in another post: stackoverflow.com/questions/70583199/zimbra-received-headers
Cheers.
@all Try this and let me know:
# 1. Create the custom rules file with the headers you want stripped
sudo tee /opt/zextras/conf/postfix_custom_header_checks > /dev/null << 'EOF' /^X-Originating-IP:/ IGNORE /^X-Mailer:/ IGNORE /^User-Agent:/ IGNORE EOF sudo chown zextras:zextras /opt/zextras/conf/postfix_custom_header_checks
# 2. Register the new file alongside the default one:
su - zextras -c "carbonio prov mcf zimbraMtaHeaderChecks 'pcre:/opt/zextras/conf/postfix_header_checks pcre:/opt/zextras/conf/postfix_custom_header_checks'"
# 3. Unset the attribute
su - zextras -c 'carbonio prov mcf zimbraMtaBlockedExtensionWarnRecipient ""'
Side effect of this step: it disables the warn-on-blocked-attachment feature.
# 4. Restart MTA target so postfix picks up the new config
systemctl restart carbonio-mta.target
I will follow up internally on why zimbraMtaBlockedExtensionWarnRecipient interferes with header_checks and update this thread.
Therefore, for now I suggest you to check this and share your observation.