7

Some email have a header like "Received: from [172.16.1.2] (some.public.ip.address)" Why is that? why does the sender's client of someone behind NAT reveal the private address?

White_Rabbit
  • 73
  • 5
    Why do you think this is a problem? – Sven Apr 18 '17 at 13:12
  • 3
    @Sven I'm just curious: if it's needed, why is it needed; if it's not needed, why is it there? – White_Rabbit Apr 18 '17 at 13:16
  • 1
    SMTP headers are there to record information about how mail passes from one server to another. Among other things, this is quite useful in helping to diagnose mail issues. But again, one cannot know why a certain company has configured their mail systems as they have, without asking that company's mail admins. – EEAA Apr 18 '17 at 13:29
  • @EEAA I don't know much about SMTP, I suppose the important point is 4.1.1.1. I'm seeing Thunderbird sending the private address. I've read a bit of the discussion about what the rationale was, but ultimately I've realized there is no easy way to choose what to do behind NAT. – White_Rabbit Apr 18 '17 at 14:03
  • They can have hostnames as well, but it is not mandatory. Outlook Express Clients managed it. If you absolutely positively need to know the point of origin then you would want the private IP to be static. – mckenzm Apr 18 '17 at 23:20

4 Answers4

12

Because that is how SMTP is designed, and how the sending email system has been configured.

There are ways to suppress this information, but the sending mail system needs to be explicitly configured to do this.

EEAA
  • 109,904
  • That doesn't explain the why. – Rob Apr 18 '17 at 13:02
  • 2
    It does explain the why. I'm not sure what you're expecting. We cannot know why a certain org has configured their mail system the way it's configured. – EEAA Apr 18 '17 at 13:05
  • 1
    The question doesn't explain why it should be hidden. There're as many "172.16.'s" as there are private networks. Therefore it reveals less and is really anonymous compared to the public IP address also shown. – Esa Jokinen Apr 18 '17 at 13:06
  • 1
    Not to be argumentative but you say you explain why and then say we can't know why. I believe you are only saying "because it is". – Rob Apr 18 '17 at 13:07
  • The "why" I explained is why the headers are in there (because that's how it was configured), not why a certain org has configured things as they have. – EEAA Apr 18 '17 at 13:08
  • 12
    As for "Why?", I'd presume that in 1982, when RFC 821 on SMTP protocol was drafted, the 1994' RFC 1597 on IANA-reserved private address space (eg. 172.16...) was not widely anticipated. Nor the evil human nature, if you were to realise that the good old SMTP did not support any authentication at that time, and the IP that the whole fuss here is about was purely declared by client without any serious verification. – Michał Sacharewicz Apr 18 '17 at 14:41
  • 1
    Adding to @MichałSacharewicz's comment, back when SMTP was conjured and designed, the entire Internet operated on the principle of end-to-end connectivity and globally routable address space everywhere. The Internet of 35-40 years ago was a very different place from the Internet of today. – user Apr 18 '17 at 21:47
7

Received: from [172.16.1.2] (some.public.ip.address)"

As you mentioned in the comments, the private IP in this particular location is because it was sent as the clients hostname in the HELO command.

For proper mail servers, the HELO command should include their fully qualified hostname, which should also match with DNS. For inbound email, many servers actually verify the HELO hostname to make sure it's valid and the DNS matches. For sending email, servers will normally accept anything as long as you are authenticated (you can't expect end users to all have real, valid hostnames configured on their machines).

For SMTP clients like Outlook, they could send your machine name, but that isn't fully qualified and might not be desirable depending on what the machine is called. For example you often see headers like the following:

Received: from DESKTOP9U6J0BC (unknown)

Using the IP address probably provides a bit more privacy as some people may argue seeing 172.1.2.3 in the headers is better than MIKES-MACBOOK or CEO-WORKSTATION.

At the end of the day the client just needs to provide something reasonable in the HELO command, and some clients choose the IP address.

This is slightly different to what other answers have discussed, which are related to actual SMTP servers using private addresses to transport email inside an organisation.

USD Matt
  • 5,391
4

It is not the mail client that adds a Received header, but each SMTP mail server in the path an SMTP message follows from the first outgoing mail server (mail relay) the sender uses, to the final destination of the recipient’s mailbox.

If the first mail server is in the sender’s internal network it can (and unless otherwise configured, will) record the sender’s internal IP address in the first Received header.

TRiG
  • 1,181
  • 3
  • 13
  • 30
HBruijn
  • 80,330
  • 24
  • 138
  • 209
1

When a SMTP client sends a mail to a SMTP server it starts out with a "helo" or "ehlo" command. This command has a field for the senders hostname.

Why have the client send the hostname to the server? because SMTP was designed to run over many transport protocols, some of which may not provide ways for the server to identify the client. The world back then was also much more trusting, noone expected people to deliberately lie about their identity.

"personal computers" as we know them today didn't exist back when SMTP was created. Networked email started it's life as a way of interconnecting the local email systems in use on big multi-user computers. These big multi-user computers would have had a well-defined hostname.

The receiving mail server adds a "Received:" header to document the path the mail took. Typically on modern mailservers it records in the "hostname" field of the header both the "hostname" reported by the client along with the actual IP address and/or reverse DNS hostname seen by the server.

Coming forward to the modern world we now use desktop email clients. The client has to use something as the hostname since the protocol requires it to send one but a desktop system may not have a meaningful hostname. Some clients use a hostname reported by the OS (which may or may not bear any resemblence to a hostname that has any meaning on any network), some use their local IP address.

Peter Green
  • 4,296
  • 1
    "personal computers" as we know them today didn't exist back when SMTP was created. Actually, they did. As pointed out, SMTP was RFC'd in (August) 1982. The IBM 5150 was introduced in August 1981, and was far from the first microcomputer within a price range that was, though expensive, at least affordable to individuals (compared to mainframes and minis, that is). I think it's fairly safe to say that the first widely accessible micro in the US was the Apple II in 1977, so predating SMTP by about five years. Granted, few of these were networked, but personal computers definitely existed! – user Apr 18 '17 at 21:52
  • Clients generally don't add any headers to a message, that's done by the server – Jim B Apr 21 '17 at 19:44