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