Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

Hide originating IP from exim headers

Discussion in 'E-mail Discussion' started by FM Kappungal, Mar 7, 2019.

  1. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    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: IP Reputation Investigation

    The strange thing is, it is not our cpanel mail server's IP that is getting blocked, rather, it is the host IP of the client PC or network sending the email. Here's an example of the Exim mail headers:

    Received: from [cpanelServerIP] ([cpanelServerIP:56060] helo=cpanelServerHostname)
    by recipientserver (envelope-from <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
     
  2. rpvw

    rpvw Well-Known Member

    Joined:
    Jul 18, 2013
    Messages:
    1,088
    Likes Received:
    442
    Trophy Points:
    113
    Location:
    Spain
    cPanel Access Level:
    Root Administrator
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    FM Kappungal likes this.
  3. GOT

    GOT Get Proactive! PartnerNOC

    Joined:
    Apr 8, 2003
    Messages:
    1,478
    Likes Received:
    185
    Trophy Points:
    193
    Location:
    Chesapeake, VA
    cPanel Access Level:
    DataCenter Provider
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    FM Kappungal and rpvw like this.
  4. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    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.
     
  5. GOT

    GOT Get Proactive! PartnerNOC

    Joined:
    Apr 8, 2003
    Messages:
    1,478
    Likes Received:
    185
    Trophy Points:
    193
    Location:
    Chesapeake, VA
    cPanel Access Level:
    DataCenter Provider
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    FM Kappungal, cPanelMichael and rpvw like this.
  6. cPanelMichael

    cPanelMichael Technical Support Community Manager Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    47,334
    Likes Received:
    2,162
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello,

    A custom Exim system filter rule is another option to explore if you decide to remove parts of the message header. There's some discussion of this on the following thread:

    How to remove X-Ham-Report from message header

    That said, addressing the source of the issue (the customer's blocked IP) is generally the better approach to solving this type of problem. You could try reaching out to the ISP's support team and requesting an escalation if their initial answer is unhelpful (depending on how the ISP handles support).

    Thank you.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    FM Kappungal likes this.
  7. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    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.
     
  8. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    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:
    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.
     

    Attached Files:

  9. cPanelMichael

    cPanelMichael Technical Support Community Manager Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    47,334
    Likes Received:
    2,162
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Twitter:
    Can you open a support ticket so we can take a closer look at your mail logs to see what's happening? You can post the ticket number here and we'll link this thread to it.

    Thank you.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    FM Kappungal likes this.
  10. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    Here you go @cPanelMichael :
    Your Support Request ID is: 11670113

    Thanks!
     
    cPanelMichael likes this.
  11. FM Kappungal

    FM Kappungal Member

    Joined:
    Feb 24, 2019
    Messages:
    18
    Likes Received:
    3
    Trophy Points:
    3
    Location:
    Saudi Arabia
    cPanel Access Level:
    Root Administrator
    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.
     
    cPanelMichael likes this.
Loading...

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice