why mumara's IP address: 165.140.***.162 appears in the email header.

H

hwp994108018

Beginner
Hello,
I send emails using postfix+mumara, postfix is hosted on server provider A and mumara is hosted on another server provider B. The question is why mumara's IP address: 165.140.***.162 appears in the email header. How to remove/hide mumara ip from email header?

I have tried to turn off "open tracking","click tracking", "unsubscribe link" and" DKIM Authentication ".

Here is the email source code:

Received: by mail-tester.com (Postfix, from userid 500)
id 46220A0ACE; Mon, 26 Feb 2024 11:23:21 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail-tester.com
X-Spam-Level: ***
X-Spam-Status: No/3.7/5.0
X-Spam-Test-Scores: DKIM_INVALID=0.1,DKIM_SIGNED=0.1,
FROM_SUSPICIOUS_NTLD=0.499,FROM_SUSPICIOUS_NTLD_FP=0.001,
HTML_MESSAGE=0.001,PDS_OTHER_BAD_TLD=1.725,RDNS_NONE=1.274,
SPF_HELO_NONE=0.001,SPF_PASS=-0.001,URIBL_BLOCKED=0.001
X-Spam-Last-External-IP: 49.83.***.236
X-Spam-Last-External-HELO: mail.example.xyz
X-Spam-Last-External-rDNS:
X-Spam-Date-of-Scan: Mon, 26 Feb 2024 11:23:21 +0100
X-Spam-Report:
* 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
* blocked. See
* http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
* for more information.
* [URIs: example.xyz]
* 1.7 PDS_OTHER_BAD_TLD Untrustworthy TLDs
* [URI: example.xyz (xyz)]
* 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid
* 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
* 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=49.83.***.236; helo=mail.example.xyz; envelope-from=[email protected]; receiver=[email protected]
DMARC-Filter: OpenDMARC Filter v1.3.1 mail-tester.com 4CBE6A0AD2
Authentication-Results: mail-tester.com; dmarc=pass header.from=example.xyz
Authentication-Results: mail-tester.com;
dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=example.xyz [email protected] header.b=IFEQ0aQ9;
dkim-atps=neutral
Received: from mail.example.xyz (unknown [49.83.***.236])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail-tester.com (Postfix) with ESMTPS id 4CBE6A0AD2
for [email protected]; Mon, 26 Feb 2024 11:23:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.xyz;
s=202401; t=1708942994;
bh=PcUqKJdYBz6x8aBJjlcrSxdxtAXM1dvdN4Fbb9ibJKQ=;
h=Date:Subject:From:Reply-To:To:From;
b=IFEQ0aQ9Strbj3BywSAXwTHC655JUIPWv2dTwAfjjxNgEPVGM0J0huO5uUh205FJO
CqRj/i2SYfU0vAYiEKbTHUfE1CekigJa4rcTlV4nAlUXSNeyFMMzWk0cD8DmgcwvSp
LBTLaZXcpoySndQgPeAkxrzc7zWpHzdGiBpv3i1K7LnX/uoUsKDDYucd7BcnbVV+U/
N4RGjFDWkP7CznoEzuhLE/Ymr5joOgs47gLkhgNaFwYN0AJuMkASo2yMqldFDaskp0
GKhKnaqeDJ1xK6J9Z4DfQ1PC6PzhOxTe3Z0TO1n8ssdGU0FfORCaxSJF6eawYZzq2T
2fWrXlF1VXx+Q==
Received: from [127.0.0.1] (unknown [165.140.***.162])
by mail.example.xyz (Postfix) with ESMTPA id 0DA6031C2D
for [email protected]; Mon, 26 Feb 2024 10:23:13 +0000 (UTC)
Message-ID: [email protected]
Date: Mon, 26 Feb 2024 10:23:13 +0000
Subject: Show you how to find reliable ways to grow your website
From: John Musk [email protected]
Reply-To: [email protected]
To: [email protected]
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=swift_1708942993_3656a8822803baf79017d86346585655 = "
x-var: 30015-1-11-1-1-1-2-
x-logid: 30015

--=swift_1708942993_3656a8822803baf79017d86346585655 =
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Click to expand...
 
Last edited:
Understanding the Issue with Email Headers:
The email headers showing the client IP address is a standard behavior of Mail Transfer Agents (MTAs) like Postfix. It's automatically adding the IP address of the originating client. Disabling features such as engagement tracking or unsubscribe links won't change this. It's inherent to how Postfix processes email headers.

Objective:
After reviewing your attached headers, it seems like you may need to remove headers that begin with "Received: from [127.0.0.1]". This requires configuring Postfix.

Step-by-Step Guide:

1. Edit Postfix Configuration:
Open the main Postfix configuration file, typically at `/etc/postfix/main.cf`.
Add the following line:
Code: 
header_checks = regexp:/etc/postfix/header_checks
This enables header checks, directing Postfix to the rules file.

2. Create or Edit Header Checks File:
Create or modify the `header_checks` file:
Code: 
sudo nano /etc/postfix/header_checks

3. Add a Rule to Remove the Header:
In the `header_checks` file, add this rule:
Code: 
/^Received: from \[127\.0\.0\.1\]/ IGNORE
This regex matches lines starting with "Received: from [127.0.0.1]" and ignores them, removing them from the header.

4. Compile Header Checks File:
After saving, compile the file:
Code: 
sudo postmap /etc/postfix/header_checks

5. Reload Postfix:
Reload Postfix to apply changes:
Code: 
sudo systemctl reload postfix

6. Testing:
Test the configuration by sending a test email. Check the headers to ensure the specified lines are removed.

Important Considerations:
  • Modifying email headers can affect how your emails are processed and perceived by receiving servers. Ensure changes align with email standards and best practices.
  • Removing headers could affect email deliverability, potentially leading to emails being marked as spam.
 
wasif said:
Understanding the Issue with Email Headers:
The email headers showing the client IP address is a standard behavior of Mail Transfer Agents (MTAs) like Postfix. It's automatically adding the IP address of the originating client. Disabling features such as engagement tracking or unsubscribe links won't change this. It's inherent to how Postfix processes email headers.

Objective:
After reviewing your attached headers, it seems like you may need to remove headers that begin with "Received: from [127.0.0.1]". This requires configuring Postfix.

Step-by-Step Guide:

1. Edit Postfix Configuration:
Open the main Postfix configuration file, typically at `/etc/postfix/main.cf`.
Add the following line:
Code: 
header_checks = regexp:/etc/postfix/header_checks
This enables header checks, directing Postfix to the rules file.

2. Create or Edit Header Checks File:
Create or modify the `header_checks` file:
Code: 
sudo nano /etc/postfix/header_checks

3. Add a Rule to Remove the Header:
In the `header_checks` file, add this rule:
Code: 
/^Received: from \[127\.0\.0\.1\]/ IGNORE
This regex matches lines starting with "Received: from [127.0.0.1]" and ignores them, removing them from the header.

4. Compile Header Checks File:
After saving, compile the file:
Code: 
sudo postmap /etc/postfix/header_checks

5. Reload Postfix:
Reload Postfix to apply changes:
Code: 
sudo systemctl reload postfix

6. Testing:
Test the configuration by sending a test email. Check the headers to ensure the specified lines are removed.

Important Considerations:
  • Modifying email headers can affect how your emails are processed and perceived by receiving servers. Ensure changes align with email standards and best practices.
  • Removing headers could affect email deliverability, potentially leading to emails being marked as spam.
Click to expand...
hello,
Another question about installing mumara

I install mumara according to the tutorial: https://docs.mumara.com/Mumara-Campaigns-Documentation/Getting-Started/Installation-Guide.

System: CentOS 7 (x86_64 minimal)

Question: when accessing the Login URL: http://mail.earngoldtoday.xyz, display an error "Testing 123..
This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page it means that this site is working properly. This server is powered by CentOS. "(Related screenshot is 2024-03-19.jpg)

I'm not familiar with linux and the code, but it seems that something went wrong with MariaDB during the mumara installation

error code:

failure: repodata/repomd.xml from mariadb: [Errno 256] No more mirrors to try.
http://yum.mariadb.org/10.7/centos7-amd64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
./mumara.sh: line 507: certbot: command not found
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
epel/x86_64/metalink | 25 kB 00:00:00
* base: ix-denver.mm.fcix.net
* epel: ziply.mm.fcix.net
* extras: mirrors.raystedman.org
* remi-safe: cdn.centos.no
* updates: or-mirror.iwebfusion.net
base | 3.6 kB 00:00:00
extras | 2.9 kB 00:00:00
http://yum.mariadb.org/10.7/centos7-amd64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below wiki article


If above article doesn't help to resolve this issue please use https://bugs.centos.org/.



One of the configured repositories failed (MariaDB),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

1. Contact the upstream for the repository and get them to fix the problem.

2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

3. Run the command with the repository temporarily disabled
yum --disablerepo=mariadb ...

4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:

yum-config-manager --disable mariadb
or
subscription-manager repos --disable=mariadb

5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:

yum-config-manager --save --setopt=mariadb.skip_if_unavailable=true

failure: repodata/repomd.xml from mariadb: [Errno 256] No more mirrors to try.
http://yum.mariadb.org/10.7/centos7-amd64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
Click to expand...


So, how can this problem be solved

best,
huang
 

Attachments

  • 2024-03-19.jpg
    2024-03-19.jpg
    123.7 KB · Views: 0
Last edited:
You must log in or register to reply here.
Back
Top