Removing internal host names and IP addresses from message headers

by Bharat Suneja

Another frequently asked question about SMTP mail – how can I remove internal host names and IP addresses from outbound Internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization’s internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it’s a part of an IT audit checklist written by a security expert at some law firm somewhere and given the viral nature of checklists it’s all over the place!

Let’s take a look at what we’re talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).

Here are headers from a message received from Dell. (Unnecessary headers removed).

These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.

What the standards say

Let’s take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):

4.4 Trace Information

When an SMTP server receives a message for delivery or further processing, it MUST insert trace (“time stamp” or “Received”) information at the beginning of the message content, as discussed in section 4.1.1.4.

This line MUST be structured as follows:

– 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, determined from the TCP connection.

and prohibits removing received headers (repeatedly). One example:

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.

Is it really more secure?

Should you remove these Received headers and “hide” internal hosts and IP addresses? Are they really a security risk?

There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.

In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.

Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.

Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don’t want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor’s checklist).

How to remove Received headers in Exchange Server 2007/2010

Exchange 2007/2010 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon — a well-known security principal that refers to anonymous users, as shown below:

What’s your take?

Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.

i understand the comments about it not really increasing security to hide the internal IP’s and FQDNs, however, being the nosey little SH*T that i am, i often peruse other peoples message headers to see what i can see. Maybe it is just a personal thing, but the naming of our internal servers is somthing of an in-joke so i dont really want them broadcasted around the net, and heaven forbid i ever had a problem which needed an external source to look into my headers… well r2d2 and c3p0.domain.local might leave me a bit redfaced – perhaps i should just come up with better server names, jahjah perhaps?

So after installing exchange 2007 i was a bit worried when my first few test messages proudly showed off my new server and domains internal info. im not having that.. i thought. So a few hours on google led me to your post, and a few others like it. I wasnt keen on removing permissions, so i stumbled apon a transport rule.

I have a transport rule that applies to messages sent to users outside the organisation and it removes the header ‘received’ and thats it.

Headers now show the message orginating at my external IP which is publically resolvable to a more respectable name, and i am happy again :)

Hi All,Need an immediate assistant on this email problem. My problem is i cannot send email to only 1 domain email so far. When try to sending to this domain [email protected], there is and bounce back with error ‘[email protected]#550 4.4.7 QUEUE.Expired; message expired ##’. Please help..

Removing this permission can caused undetected message loops and potentially even bring down exchange. Much better to use transport rules to remove the Received and Message-ID headers from inside users.

This is great, I have something similair, where my internal hostname and IP shows up. My question is I have heard that some places block .local addresses from going through there IP gateways is that true? Wouldnt that be a reason to make this Best Practice?

My biggest issue is that we are on a ListServ list that tries to verify the sending server. When it tries to verify server.company.local [192.168.1.2] it is unable to contact the server and the user is then removed from the list.

Microsoft has expertise in security? As soon as I read that implication, I considered this entire article tainted because Microsoft's swiss-cheese approach to security (it's full of holes) is one of the de-facto industry examples of what not to do.

Given the number of times I've been burned by Microsoft's security techniques, I have no choice but take all of their recommendations with a grain of salt.

@Anonymous from Oct. 15: It's not just Microsoft – plenty of other organizations including Dell and HP don't hide internal IP addresses in message headers. Microsoft's security reputation isn't what it once was – in fact, Microsoft products have increasingly proven to be more secure and less vulnerable, and its secure development lifecycle cited as an example for other software companies to emulate.

@Anonymous from Oct. 14: And how does it help you, besides showing off to your customers that you can read their headers? Please provide real life example where you were able to utilize that, other then stating "oh you've got 1 or 2 mail relays and this is the name of your mail server". I mean carry out an attack and be successful based on the info from header. As the article says "if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about." If your firewall is wide open and you are running unpatched OS and Mail server, you are asking for it and no amount of obscurity is going to protect you.

@Anonymous from Oct. 15: It is actually them conforming to RFCs that does not allow you to remove the info from headers. Did you read the article?

Its still trendy to bash MS these days?!? I thought those were the jokes that went the way of the Dodo. Whilst i hold no allegiance or partiality to any vendor or product im so tired of hearing this same tired line about Microsoft’s apparent lax security.

@ Anonymous Coward: I suggest you pick up a manual if you’ve been burnt by endless MS products. A poor workman always blames he’s tool’s.

Anyway EXCELLENT blog Bharat. Your work is valued in the Exchange community.
Keep it up.

I done exactly mention above. but result no changes. still internal IP Address have been display in email header. i have Exchange 2007 SP 3, HUB/CAS/Mailbox and Edge Server. if any1 have any other trick to hide internal ip address of exchange server would be grateful to guide me.

My question has nothing to do with mail, but more to do with IRC. how can I hide or change my internal hostname and ip from programs like Mirc. I’ve used hotspot shield, but it doesn’t change my hostname but am sure it changes my ip. any help would be appreciated……..TY

Transport Rules for removing Received headers worked for me in earlier versions of Exchange (2007, 2010 SP1?) but had strangely stopped working after some updates.
Thanks for this post which helped me to solve the issue!

I have the same need, but for deleting the “acceptlanguage” header field.

I’m not a pro in Exchange tech., so I deliver here my first analysis after some days of research and test (also using the PipelineTracing tool).
Thank to correct me or help me back with any feedback.

I have a SBS 2008/Exchange 2007 SP3 with Hub but no Edge server.

The common way for deleting an header field without programming transport agent or installing extra filtering tools is to implement a Transport Rule, BUT :
I think the Transport Rule effect is in this case overloaded by the “post-routing” process in the Hub server (i.e. the categorizer in the content conversion module):

– the header fields are created somewhere when constructing the mail
– the headers fields are effectively deleted after the “OnRoutedMessage” step by the “Transport Rule Agent”
– the headers fields (or some of them), are created again by the “conversion module”

So it seems that the only way is to install an Edge server (an extra tool, finally !) taking care of the outgoing mails and program similar “Transport Rule” but on the Edge.