The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Problems with new cpanel MX behaviour

Discussion in 'General Discussion' started by 4u123, Mar 26, 2010.

  1. 4u123

    4u123 Well-Known Member
    PartnerNOC

    Joined:
    Jan 2, 2006
    Messages:
    765
    Likes Received:
    1
    Trophy Points:
    18
    cpanel has made an error in the logic of this new MX record behaviour.

    If we change the IP address of a domain on the server - cpanel sets it to a remote domain automatically and all mail is rejected for that domain.

    This is because the cpanel server atomatically determines the MX behaviour based on the domains IP address - whether we want it to or not.

    This is astoundingly stupid.

    The main IP of a domain has absolutely no bearing on whether the MX should be local or remote - you cant just "presume" that if the main IP in the zone file is not the main hosting IP, the email should be remote - thats ridiculous. Like lots of hosting companies we use external appliances for anti spam that route mail back to the cpanel server - so all domains should be set to local unless manually changed. It seems that cpanel thinks the following..

    1. If the main A record for the domain is not the main server IP
    AND
    2. The lowest mx record is not the domain itself

    Set the domain to remote.

    That is a very narrow minded approach and its completely inappropriate.

    Secondly, this unwanted behavour cannot be disabled. As mentioned in previous threads, all domains are set to "automatic" unless they are each manually changed and there is no longer an override in tweak settings to prevent this.

    I cant begin to describe my disappointment about this badly thought out "logic". cpanel have not considered that an external MX in many cases does not require the domain to be in "remotedomains" because that external MX is processing mail on behalf of the cpanel server and routing mail to it. Also, the cpanel server considers one of its own IP addresses to be remote - Why?

    We need an override to remove the "automatic" behaviour completely. I'm sure lots of others will agree that a simple "Local or Remote" method is much more appropriate. The automatic setting doesnt provide any advantage - it just makes a bad guess!

    Rant over.
     
    #1 4u123, Mar 26, 2010
    Last edited: Mar 26, 2010
  2. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,461
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Thanks for your feedback on that feature change. From reading the above it sounds like what is needed is:

    1. A way to define the behavior of MXCHECK[1] server-wide ( the tweak setting you mention )
    2. A tool to manage the MXCHECK setting for individual accounts, and accounts in bulk
    3. A re-analysis of the various common scenarios wherein the automatic check does the wrong thing ( along with requisite fixes )


    [1] MXCHECK is the per-domain entry in the cPanel user file which determines whether MX handling is local, remote, or automatic.
     
  3. 4u123

    4u123 Well-Known Member
    PartnerNOC

    Joined:
    Jan 2, 2006
    Messages:
    765
    Likes Received:
    1
    Trophy Points:
    18

    Hi Ken, its nice to see a productive response.

    What I have experienced is that the process will recommend "local" in every circumstance apart from where the main IP of the domain is not the main shared IP of the server. As I mentioned above, there are a few scenarios where a domain can be pointing elswhere but the mail still needs to be routed locally.

    My question would be - why try and determine what is required if that isnt possible?

    In my opinion, there must be a default MX behaviour for all new domains and this should then be changed per domain as and when required (like it was before).

    For example....

    You use the standard cpanel setup - all mail is routed locally direct to the cpanel server itself - all MX records are set to %domain% by default.

    You would want the default behaviour of cpanel to set the domains to "local".

    A customer then decides to use an external email provider so their MX record is set to an external one via the admin/reseller in WHM or by the customer in cpanel. This is a manual process so options are chosen at the time. You would choose the option for the domain to be "remote" - unless usign the automated option.

    Unfortunately, the cpanel automated option would incorrectly suggest that the domain be set to "local".

    A similar scenario....

    A customer decides to use an external anti spam service that routes the mail back to the the cpanel server once it has been checked. Again, you have to perform an action to do this so nothing is automatic - you would choose the option to set the domain to "local".

    In both these scenarios, you are setting an external MX on the domain but not changing the main IP. The outcome you want is different for each - but the automated option cannot determine your wishes and so it fails, by suggesting "local" for both.

    Heres another scenario, as I have experienced today...

    The customer already has an external MX set on their domain but as in scenario 2 above, they route mail back to the cpanel server. This customer asks for a dedicated IP address. When this is added, the cpanel server decides to set the domain to remote. I presume this would also happen if the customer edited their DNS in cpanel and changed their domain's IP. Customer contacted us to say he was not receiving email. I checked and the domain was in /etc/remotedomains.

    When you set a domain to "automatic" you allow the cpanel server to make the decision for you about whether to set the domain to internal or external. This is of no use at all if it cant make the correct suggestion. The logic isnt flawed - its just not possible to determine what you actually want to achieve, therefore it renders itself completely useless. It fails more times than it suceeds in my opinion.

    So back to your points...

    1. A way to define the behavior of MXCHECK[1] server-wide ( the tweak setting you mention )
    2. A tool to manage the MXCHECK setting for individual accounts, and accounts in bulk
    3. A re-analysis of the various common scenarios wherein the automatic check does the wrong thing ( along with requisite fixes )

    1. Yes definately. I would say a way to determine the default behaviour is essential. Personally I'd like the option to disable the "automatic" option from display in the cpanel interface and just have local, remote and backup.

    2. This is something that is domain specific, not account specific. you can easily change it per domain either via the "MX Entry" option in cpanel or in WHM. It would be useful to somehow set all domains in bulk to use "local" unless they resided in "remotedomains".

    3. Yes if you intend to continue using an automated method - but I dont think this will be possible.
     
    #3 4u123, Mar 26, 2010
    Last edited: Mar 26, 2010
  4. 4u123

    4u123 Well-Known Member
    PartnerNOC

    Joined:
    Jan 2, 2006
    Messages:
    765
    Likes Received:
    1
    Trophy Points:
    18
    I want to add to this.

    Yesterday I changed the IP on an another account and again this morning, the MXCHECK setting on the domains was "automatic" but the domains were not set to remote by this process. So I've been unable to reproduce what I experienced yesterday with the first account wherby I changed the sites IP and it was automatically set to remote by cpanel.

    I also had a customer who uses an external MX report yesteday that email sent from the server to his domain was not being delivered. I checked and the domain was in /etc/localdomains when it shouldnt have been. I've seen this happen a few times where a remote domain reverts back to local without any reason. Perhaps something in the cpanel update process could cause that? I'm not sure but there is certainly some inconsistency here.
     
    #4 4u123, Mar 27, 2010
    Last edited: Mar 27, 2010
Loading...

Share This Page