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.

CPANEL stores the LOCAL emils and doesnot forward to MX

Discussion in 'General Discussion' started by Webiz, Nov 14, 2002.

  1. Webiz

    Webiz Registered

    Joined:
    Oct 3, 2002
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    Hi..

    here is my problem :

    i have MX record to : (mail.other-mserver.com ) for example

    ok, when every my scripts on my domain sends emails to : anything@mydomain.com , it's stored *only* in the local inbox of the CPANEL...but it never forward them to the MX recorg i use ..

    Example :

    the VB script send email confirming new replies, if the email of the user is : ( anyone@mydomain.com ) then this email will *not* be forwarded to the MX record i use , it's just stored in a local inboz of the CPANEL that only me can access it with (Harode) or (NeoMail) from the CP.

    in the other side, if the email is set to ( anyone@otherdomain.com ) then the email is forwarded normally and is not stored in the local inbox..

    i had this problem on 4 completly deffrent hosting servers, and had lot's of freids suffering from the same thing !

    can any body please help me to solve this issue.

    thanx allot :)
     
  2. anand

    anand Well-Known Member

    Joined:
    Nov 11, 2002
    Messages:
    1,435
    Likes Received:
    1
    Trophy Points:
    38
    Location:
    India
    cPanel Access Level:
    DataCenter Provider
    i confirm the error. I noticed the same error on my server as well.

    regards,

    Anand
     
  3. anand

    anand Well-Known Member

    Joined:
    Nov 11, 2002
    Messages:
    1,435
    Likes Received:
    1
    Trophy Points:
    38
    Location:
    India
    cPanel Access Level:
    DataCenter Provider
    An update from cpanel/whm news:

    Fixups Changing the MX entry for a domain now removes/adds it from/to /etc/localdomains as needed.

    (5.3.0 build 42 EDGE or later only)

    This should help, i am yet to checkup.

    regards,

    Anand
     
  4. Webiz

    Webiz Registered

    Joined:
    Oct 3, 2002
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    thanx anand for your reply..

    but does this mean that i have to wait till my hosting server make the update, or they should do specific changes ?

    regards.
     
  5. anand

    anand Well-Known Member

    Joined:
    Nov 11, 2002
    Messages:
    1,435
    Likes Received:
    1
    Trophy Points:
    38
    Location:
    India
    cPanel Access Level:
    DataCenter Provider
    [quote:7b48d3d36f][i:7b48d3d36f]Originally posted by Webiz[/i:7b48d3d36f]

    thanx anand for your reply..

    but does this mean that i have to wait till my hosting server make the update, or they should do specific changes ?

    regards.[/quote:7b48d3d36f]

    Yes you need to wait for your hosting server to make the updates, also this update as stated is included in the bleading edge version which lots of servers don't update unless its in a stable form. However i run the bleeding edge version on my box.

    I just updated the whm and this is what i found by using mail -v mail@domain.com where domain.com had its MX entry set to another server.

    Now the mail program still delivered the mail to the local mailbox. I think nick still needs to look in this matter. But since this update has come inside the bleeding edge version, it shouldn't be much time once it is tweked up and is released inside the stable release.

    regards,

    Anand
     
  6. bmcpanel

    bmcpanel Well-Known Member

    Joined:
    Jun 1, 2002
    Messages:
    546
    Likes Received:
    0
    Trophy Points:
    16
    I think this is a normal process of sendmail (PHP, CGI, etc uses sendmail). Sendmail looks locally to find a FQDN and when it does find the domain on the same server as the form, it does not look externally and thus, the DNS MX record does not come into play. (I could be wrong but this is what seems to be happening).

    To work around this, I did the following.

    Server A
    -- Origin domain name exists here with a PHP form, as an example. (Origin Domain: www.serverA.com)
    -- The mx record directs mail to an exchange server that is NOT located on this server.
    -- I want to receive form results as &finaldestination@serverA.com&.

    Server B
    On a completely different server, I setup an email account simply to receive form results from www.serverA.com (Example Email: &results@serverB.com&). I then forward the email back to &finaldestination@serverA.com&.

    This is what happens...
    1. In the form on serverA, I put the email address in the form to which I want to send the form results. I send the email results to &results@serverB.com&.
    2. The email is sent to serverB and then forwarded to email address &finaldestination@serverA.com&.
    3. The mx record on serverA.com then properly routes the mail to the custom mx address

    I hope I have explained that properly. Basically, the form on serverA will only deliver locally and will ignore the custom MX record if the target email address is anything@serverA.com. Thus, you have to send the email to another server that does not have serverA.com listed on it. Then, forward it back to serverA.com. By doing this, you put the custom mx record in play and the form results are forwarded to the correct destination address according to the custom mx record.
     
  7. Webiz

    Webiz Registered

    Joined:
    Oct 3, 2002
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    hi..

    thanx for the tip..

    but unfourtnatly it's not practical when u are dealing with huge users or a free web-mail service...

    i'm useing the site : www.gawab.com to have a free webmail at the domain name of my site..

    so i think the developers -of CPANEL- should look about this issue.. and i don't think it's that hard to be fixed with some coding..

    regards.
     
  8. mohamed_gaber

    mohamed_gaber Member

    Joined:
    Mar 4, 2003
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    i have this problem..

    i'm a reseller on a WHM/cPanel 6 ... and this problem is driving my clients crazy...

    can any body help out please ?!!
     
  9. Annette

    Annette Well-Known Member
    PartnerNOC

    Joined:
    Aug 12, 2001
    Messages:
    445
    Likes Received:
    0
    Trophy Points:
    16
    Delivering mail from the local server to an external mail server.

    1. Make sure your local zones are set to use the remote MX for the domain. If they use mail.theirdomain.com, make sure you adjust the mail CNAME to an A record with the appropriate IP.
    2. Remove the domain's entries from /etc/userdomains and /etc/localdomains

    That's all it takes to get the server to deliver mail offnetwork when an account is utilizing a third party mail server. Systems will look locally to deliver mail before looking elsewhere, and if the items in number two above exist, it will push mail to the user's account on the server instead of looking outside its realm.

    If you're a reseller, you'll need to get your host to remove the /etc/*domains entries, as that takes root access. Depending on your zone editing permissions, they may need to make that change for you as well.
     
  10. mohamed_gaber

    mohamed_gaber Member

    Joined:
    Mar 4, 2003
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    thanx allot Annette for your reply, but can u please explane to me that point, coz i got confused..

    let's say :

    * my domain name is : cpanoz.com
    * my external mail server is : mail.pipoz.com

    so i change the MX record to point to mail.pipoz.com
    do i need some thing else ?

    i can edit my DNS records from the WHM, and for the /etc/ i'll ask my hosting comp. to make it for me..

    thanx again.
     
  11. Annette

    Annette Well-Known Member
    PartnerNOC

    Joined:
    Aug 12, 2001
    Messages:
    445
    Likes Received:
    0
    Trophy Points:
    16
    What you can do is edit your zone to point the MX record to mail.pipoz.com:

    cpanoz.com. IN MX 0 mail.pipoz.com.

    If you don't alter the mail CNAME entry, it will just act as a general subdomain of your account - if you don't intend to use mail.cpanoz.com for your mail, it can be left alone (or deleted, or changed) at your preference. Then have the host remove the other entries, send a test through the machine, and that will do it.
     
  12. MarlboroMan

    MarlboroMan Well-Known Member

    Joined:
    Dec 7, 2001
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    A further note - removing the domain from /etc/localdomains isn't a permanent fix, because if anyone runs /scripts/mailperm, it gets added right back. UNLESS the domain is listed in /etc/remotedomains. The mailperm script doesn't re-add domain names in /etc/remotedomains back to /etc/localdomains

    Just FYI
     
  13. mohamed_gaber

    mohamed_gaber Member

    Joined:
    Mar 4, 2003
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    i wonder why don't cPanel developers fix this problem in the script it self !!

    this is realy a nightmare ...
     
  14. Annette

    Annette Well-Known Member
    PartnerNOC

    Joined:
    Aug 12, 2001
    Messages:
    445
    Likes Received:
    0
    Trophy Points:
    16
    It isn't a problem in the script per se. This is the way systems are designed to work (look local, then look elsewhere). It's up to the system admin to finalize the process if default values won't be used. With the exception of the initial mail structure changes in cPanel v5, the /scripts/mailperm we've only seen run during server to server transfers - we've never run it ourselves and removing the entries from the two main *domains files works without a problem. Of course, if you introduce more steps in what you do, the chance arises that you'll have to compensate for that. In the end, though, using remote mail servers is a piece of cake and the required changes are no big deal.
     
Loading...

Share This Page