Hide client IP in email headers

Mail
1

It seems emClient sends out my private/lan IP to the SMTP server. For example, in an Email sent out by emClient, the header contains

Received: from [192.168.1.2] (example.com [1.2.3.4])
	by mail.example.com (Postfix) with ESMTPSA id 92CD297DEA;

It is fine that the SMTP server records the public IP (1.2.3.4) as it is what it sees. But only emClient can get my lan IP (192.168.1.2 here, as the SMTP server on the Internet can’t find that) and it sent the info to the SMTP server.

How to make emClient hide the lan IP in the header of emails sent out?

2

That is added by the server, irrespective of what client you use. All mail servers do that.

3

No, you didn’t understand. The LAN-IP is not accessible by the Server, only the public IP. However, emClient adds the private/LAN IP (not the public IP) to the email headers.

4

So the lan IP is 192.168.1.2. There must be 100 million with the same. Still, it’s added by the server. you will see the same whatever email client you are using. The only way to avoid that is to use a webmail interface.

5

No matter how many clients might use that internal IP, do you have an answer to my question?

Following your derailing: No matter how many clients might use that internal IP, emClient is sending out internal Information of the client to third parties without any need. Depending on the set-up of the LAN (company, NGO) this can provide sensitive information - and the decision to provide third parties internal information should be a decision of the user (also pointing to the GDPR).

6

Yes. Answered above.

7

Yes, saw you editited your post.

Blockquote[quote=“Gary, post:4, topic:67424”]
Still, it’s added by the server. you will see the same whatever email client you are using.
[/quote]

It’s the primary decision of emClient to send that information out.

Thunderbird can be configured to hide the LAN-IP or to provide a fake-IP. Just edit mail.smtpserver.default.hello_argument to localhost and within the extended HELO the client (eg Tunderbird) provides “localhost” to the Server.

So, this would be a feature-request.

8

I think it is a requirement of all mail servers.

9

No, the mail server do not need that information, it’s the decision of the client to send internal information within the extended HELO.

RFC 2821 says:

In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.

This is why

Received: from localhost (example.com [1.2.3.4])
by mail.example.com (Postfix) with ESMTPSA id 92CD297DEA;

would be perfectly enough. You can see I stripped the LAN-IP.

10

Yes, you can find it in RFC 2821:

The FROM field, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source.

I guess you did not get to that section yet. :wink:

11

Yes, it says it must provide the public IP of your connection and not your internal/private/LAN-IP. The latter is an optionally information that is ot needed.

12

No, it says address literal containing the IP address of the source.

13

Yes, the address literal is defined as an IP (not the hostname) and is the public IP of the smtp client (eg connection), not the internal. See section 4.1.1.1 I cited above. Address literals are defined in 4.1.3

Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier a special literal form
of the address is allowed as an alternative to a domain name.

This means if you’re using a dynamic IP (as most private DSL/cable-connection do) the host like f4zhg.dynip.verizon.com is not enough but the smtp client (eg emClient) has to provide the public IP of the client connection; not the private/LAN-IP. The source is the public IP of the connection.

See also 3.2 of the RFC:

In the EHLO command the host sending the command identifies itself;
the command may be interpreted as saying “Hello, I am domain” (and,
in the case of EHLO, “and I support service extension requests”).

Normally, the MUA would provide the hostname (eg domain) of the connection (no NAT). However, the hostname is not enough in some cases where not real routing is provided on the hostname (see above), thus the MUA must send the IP of the connection, thus the public IP.

14

@wolf1

You’re forgetting NAT and also the situation in most homes.
Home devices often don’t come with an FQDN - they know the hostname, but most home users do not have their own domain.

Devices behind NAT don’t see their public IP address, they only see the LAN IP therefore they make the string literal up from that.

Finally, knowing the “private” LAN IP is of no use to attackers as:

  1. They’re not unique to you.
  2. They’re not reachable from the internet.

BTW - If you’re going to throw RFC’s at each other, be aware that the current SMTP standard is RFC5321, issued in 2008.

15

Right, but this is not a base for a MUA to refrain from the obligations of the relevant RFC and provide indentifiable information without any need. Providing an IP (address literal) is a workaround from Section 2.3.5, 4.1.3, 4.1.4 of the RFC. However, the IP named there is the public IP, not the internal/LAN-IP.

Section 4.1.4 says why a public IP can be provided in the case above:

An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.

A domain can not be verified when the MUA provides a private/LAN-IP. Therefore, only a public IP is meant to be provided.

The RFC continues by stating

Information captured in the
verification attempt is for logging and tracing purposes.

So providing an IP is of no need/help for the SMTP-transaction, it is only use by the server (third party) for their own logging and tracing). If the MUA provides the internal IP it therefore gives the server information that is not needed for the SMTP transaction and decouraged by the RFC but used by the server for tracing the user. (as the server has the public IP, the host and the private/LAN-IP - it has all information to definitely identify the user)

This - on a sitenote - is also problematic with respect to the GDPR: the IP (even the NATed one - and especially the combination: private/LAN-IP + public IP + host) is personal data that falls under the GDPR. If a EU-company provides emClient for its employees the company has no legal base (no lawfulness processing according to Art. 6 GDPR) for providing that personal data to third parties. If the company even allows it’s employees to use the company-device for personal purposes or the company even allows the employee to use his own device with emClient for comany purposes, this is even a bigger problem, as the company would then - by forcing the employee to use emClient - provide private personal data to third parties.

Which they don’t need, as providing this literal is optional as specified in the RFC.

Actually, the RFC5321 - which you correctly pointed out is the current one - even specifies that:

RFC 2821, and some earlier informal practices, encouraged following the literal by information that would help to identify the client system. That convention was not widely supported, and many SMTP servers considered it an error. In the interest of interoperability, it is probably wise for servers to be prepared for this string to occur, but SMTP clients SHOULD NOT send it.

ofc, it is of great interest for a third party with bad intentions to know the structure of the internal set-up of the network. As soon as the HELO is initiated, the server knows the public IP. With the knowledge of the internal/private/LAN-IP the third party can identify the individual system and person.

You’re right, but - as stated above - RFC5321 even obsoletes the allowance for MUA to provide the internal/private/LAN-IP, it even encourages MUA to not send that information (see citation above) and section 2.3.4 of RFC5321:

For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP
network) and supporting the SMTP protocol. Hosts are known by names
(see the next section); they SHOULD NOT be identified by numerical
addresses, i.e., by address literals as described in