Remove Dynamic IP From Received Header

[yock]

I did some searching through the forum and was not able to find the answer to this. I use SMTP to send mail from my laptop through a variety of my websites domains. The problem is some of my mail is being blocked as spam because my dynamic IP is included in the received headers.

What do I need to do to just have the domain name in the received headers?

Thanks.

 

[hilario]

I have the same problem: exim shows my dynamic IP and a few recipients are blocking my mail.

I would like to learn how to set exim to not show my particular dynamic IP in the headers?

I also would like to know if that exim behavior is normal or a result of some misconfiguration of my server.

 

[LasseTK]

Some of our clients are experiencing a similar issue. Any ideas?

 

[mtindor]

I don't have an easy answer for you, but modifying your exim to mask the IP address of the sender [or to remove that whole received line] is not the way to go.

9 times out of 10 the recipient mailsystem is using a Barracuda Spam Firewall with "deep scanning" enabled. That means that the recipient mail system not only checks the last received line for an IP to check against RBLS, but it checks the IP addresses in other Received lines. Any admin of a Barracuda Spam Firewall that does this should be smacked. Sure, it can cut down on spam a _very_little_bit_, but the recipient mailsystem would have a lot of false positive spam taggings / rejections based upon this.

For any place that is blocking your emails because of this, you should simply ask them to whitelist your mailserver's IP address of they are going to be so anal and foolish to run deep scanning.

NOTE: The Barracuda Spam Firewall is certainly not the only mail system capable of deep scanning, but it is _by_far_ the most popular one doing this. An unwitting admin-in-training gets a new Barracuda Firewall, starts getting click-happy with all of the options to fight spam, and suddenly they are blocking all kinds of legitimate mail because they are using deep scanning.

Don't get me wrong - I love Barracuda Spam Firewalls. I operate a couple myself. But I'd never ever consider enabling deep scanning on them.

Mike

 

[hilario]

Mike,

I confirm that the problems I am experiencing are related to recipients using Barracuda central. You went direct to the point.

In the first moment I thought our problem was due to some misconfiguration in our server.

The answer you provided was greatly appreciated.

Thanks for the help

 

[mtindor]

Mike,

I confirm that the problems I am experiencing are related to recipients using Barracuda central. You went direct to the point.

In the first moment I thought our problem was due to some misconfiguration in our server.

The answer you provided was greatly appreciated.

Thanks for the help

You're welcome, Hilario. If you are like me, you don't have the time or the staff to contact all companies running deep scanning to ask them to whitelist you [or to turn deep scanning off], but if you must get mail delivered to those recipients you are probably going to have to contact them.

As far as exim [and any good mail server], it is default behavior to show the IP addresses that the mail has passed through in the various Recieved lines, from beginning to end. It's normal and proper.

Barracuda should have a huge alert that pops up in their configuration to tell the Barracuda admin that turning on deep scanning IS going to reject legitimate mail

Mike

 

[Secmas]

A lot of my customers have the same problem with barracuda and some of them found a solution that works for them.

They have configured their email account with gmail so they change the MX to work with gmail servers and the error disappears and I wonder How this could be done?

I mean, why the same user that was using my server but was blocked by barracuda because of the ISP IP is not blocked when he changes the MX using the same ISP IP?

 

[reontrebl]

Same problem here...

 

[shenzy]

Same problem here...

 

[cPanelTristan]

Exim is going to show all IPs used for routing a message if it is sent from a local email client. Trying to spoof the IP to not have one of the senders is not the way to assist with this issue, since then you could have anyone who ends up being hacked having a spammer send out from their local system without it showing that IP connection in the header, then you won't be able to block their IP because you won't even know what IP was used.

Instead of trying to prevent a system that is there as a safety measure to show the routing for an email, the better choices are to ask these users to send from webmail (webmail interface will use the server's IP to send the message), or to contact the companies rejecting the emails about the deep scanning they are doing as previously mentioned and ask they whitelist the domain or IP in Barracuda.

Thanks.

 

[hbouma]

Instead of trying to prevent a system that is there as a safety measure to show the routing for an email, the better choices are to ask these users to send from webmail (webmail interface will use the server's IP to send the message), or to contact the companies rejecting the emails about the deep scanning they are doing as previously mentioned and ask they whitelist the domain or IP in Barracuda.
Thanks.

Tristan, if you're going to put this out as a "solution", why don't you actually confirm what you're saying is true first? Otherwise, someone like me is going to come along and show how you're totally wrong on this. I've even been flagged by the deep header scan when clients use cPanel's webmail. For example, here's a bounced header from last month:

host [cpanel5.netwisp.com] blocked using Barracuda Reputation;
BarracudaCentral.org - Technical Insight for Security Pros

------ This is a copy of the message, including all the headers. ------

Return-path: <[email protected]>
Received: from localhost ([127.0.0.1] helo=cpanel5.netwisp.com)
by cpanel5.netwisp.com with esmtpa (Exim 4.69)
(envelope-from <[email protected]>)
id 1Q4Lpd-0001SP-QK; Mon, 28 Mar 2011 18:26:45 -0500
Received: from 194.146.217.49 ([194.146.217.49])
(SquirrelMail authenticated user [email protected])
by cpanel5.netwisp.com with HTTP;
Tue, 29 Mar 2011 01:26:45 +0200

As you can see, even though they used a webmail client, it was still refused by the deep header scan because it included their IP address in the header. Simply using webmail may not resolve the problem because both Squirrelmail and Horde will include the sender's IP address. Roundcube does not and is safe to use.

Hal

 

[cPanelTristan]

Edit: All right, I do see what you are saying about the other email clients. I've used webmail before to confirm what it uses to send and it should only be sending using localhost and the server's IP in Roundcube webmail client for all of the tests. I was not aware that Horde and Squirrelmail performed differently than Roundcube webmail client.

This has been tested for purposes in the past for checking the headers for dedicated IP addresses used to send emails to see if the header showed the IP for the domain's dedicated IP when the option in Tweak Settings was set to automatically send from the dedicated IP (versus the main IP).

Per a test on my cPanel machine from Roundcube where it does work:

Received: from [109.123.86.173] (helo=pandacow.errorcodex.com) by mx1.cpanel.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[email protected]>) id 1QD2c2-0004Kh-0H for [email protected]; Thu, 21 Apr 2011 17:44:38 -0500
Received: from localhost ([127.0.0.1] helo=ratingbar.com) by pandacow.errorcodex.com with esmtpa (Exim 4.69) (envelope-from <[email protected]>) id 1QD2by-0001sH-LU for [email protected]; Thu, 21 Apr 2011 18:44:34 -0400

The server's IP is 109.123.86.173 and the webmail first sent from localhost, then from the server. There is no other IP listed in the long header at all beyond the server's own IPs.

I apologize for not realizing the other webmail clients did this differently than Roundcube. I will try to see if there is a way to get Horde and Squirrelmail to function the same as Roundcube in this regard if that's possible.

 

[crazyaboutlinux]

Same problem here...