Hide originating IP from exim headers
Recently many of our customers are complaining of their emails getting bounced due to IP being listed in the Symantec Global Bad Senders List. This is the link where Symantec's IP reputation can be checked: user@example.com>)
(ecelerity 4.2.38.62370) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384)
id 2D/C6-04510-1D6E08C5; Thu, 07 Mar 2019 04:39:30 -0500
Received: from [clientHostIP] (port=63438 helo=clientHostName)
by cpanelServerHostname with esmtpa (Exim 4.91)
(envelope-from <user@example.com>)
id 1h1pUm-0006xV-43; Thu, 07 Mar 2019 02:39:28 -0700
While it seems to be over-kill for Symantec firewalls to check both the server IP as well as the client IP, there's nothing that can be done about it.
And it's difficult to explain to every client that the problem is with their local IP and their ISP, because even ISP's tend to just deflect the blame to others.
So, the solution I am looking for is, how to remove the clientHostIP from the exim headers? Is it even possible?
Thanks
-
Obfuscating the originating IP many be in violation of the RFC, so you could end up swapping one problem for another. There is a discussion here : lists.exim.org/lurker/message/20150707.090106.6f3f2d44.en.html 0 -
About all you can do is suggest that they switch to using Webmail which will not put their IP in the header when they send mail that way. 0 -
Yes, I did suggest that only to realise later that when you use Horde, it adds an extra "Received: from" line to the email header with the client IP. In RoundCube you are right, it doesn't include the client IP. Still, it feels awkward and unprofessional to restrict customers to using only RoundCube to prevent this problem. The thread referred by @rpvw has a working solution. Don't know whether it will result in any other problems though. 0 -
Since its THEIR ip that is blocked, its really out of your hands. You could also suggest to them using a VPN service which would change their IP, though VPNs can get blocked as well. 0 -
Thanks @cPanelMichael What I have done so far is to remove the '$sender_rcvhost' variable from the default "received_header_text" string in the advanced exim config tab. (Based on the thread referred by @rpvw ) This does satisfy my requirement of removing the originator's IP from the header. But that fact that this is a violation of RFC 5321 is a cause of worry. Especially because it is applied universally to all outgoing mails and AFAIK there is no way to make it selective for only the complaining customers. @cPanelMichael's suggestion of using a system filter rule seems promising. But I would appreciate some help with the syntax. I need a rule that will remove or mask only the sender IP from the header when sender matches a list of complaining senders. So I can just keep appending to the list as new users come with similar complaints. For a more stricter implementation we may want to include the concerned recipient domain as well, so that only in the case of the specific sender-receiver pair, this IP removal needs to happen. Grateful for any help as I'm still very new to this. Thanks. 0 -
Ok.. I don't know whether I need to create another thread for this, but I'll go ahead with this one. Admins please let me know and I'll create a new one. The issue is the following bounce/error message: [QUOTE] "SMTP error from remote mail server after initial connection: 554 5.7.1 You are not allowed to connect."
From my understanding this happens when the recipient server uses Symantec firewall and the sender host IP is on the symantec global bad senders list. (Please correct me if I'm wrong and there is some other possible scenario.) I came to this conclusion because the same recipient server will accept the message when sent from a different Host IP. My cpanel mail server IP is not in any black list and in fact has a great senderscore and a "good" reputation on cisco talos. So it's definitely not the sending server IP. Also, all senders would get rejected if the problem was with OUR IP. As discussed above, I changed the exim received_header_text to hide the originator IP, but it turns out that this rejection happens at the server EHLO/HELO stage. I am totally lost. I have been telling customers to clean up their networks and get clean IP's from their ISP's. But I still think that I may be missing something in my trouble shooting of this issue. My main confusion is how the originator's IP comes into the picture when it's actually my server that is relaying the message? Anyone has experience with this error message or has any clues? Am attaching a screenshot of recent log file (with private info obfuscated, of course) which shows a typical case of the same recipient server rejecting some and accepting others.0 -
As discussed above, I changed the exim received_header_text to hide the originator IP, but it turns out that this rejection happens at the server EHLO/HELO stage. I am totally lost. I have been telling customers to clean up their networks and get clean IP's from their ISP's. But I still think that I may be missing something in my trouble shooting of this issue. My main confusion is how the originator's IP comes into the picture when it's actually my server that is relaying the message?
Can you open a0 -
Here you go @cPanelMichael : Your Support Request ID is: 11670113 Thanks! 0 -
For anyone else who may have faced this SMTP error 554 5.7.1, just on a hunch I tried changing the exim outgoing IP (using /etc/mailips and /etc/mailhelo) and the error disappeared. It's strange because the original IP was not on any known blacklist and had a good reputation, but it's possible that some servers had blacklisted that IP locally. It's unfortunate that the error message is so vague instead of clearly describing the issue. So if you are facing a similar error without no apparent explanation, and you have additional IP's, try changing the outgoing IP. It just might work. 0
Please sign in to leave a comment.
Comments
10 comments