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.

Domain forwarding not working

Discussion in 'E-mail Discussions' started by jhitesma, Feb 5, 2008.

  1. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Just tried to setup domain forwarding on our server but it doesn't seem to be working:

    WHM 11.2.0 cPanel 11.6.0-R15076
    REDHAT Enterprise 4 i686 - WHM X v3.1.0

    I'm trying to forward any e-mail to domain1.com over to domain2.com

    I looked in /etc/vdomainalises/domain2.com and it looks correct:

    domain1.com: domain2.com

    But when if I try to send to test@domain1.com even though test@domain2.com exists I get a bounce with:

    PERM_FAILURE: SMTP Error (state 13): 550 No Such User Here

    If I use the trace function in cpanel it comes back with:

    virtual_aliases via virtual_aliases router forced address failure


    Any ideas?
     
  2. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    domain2.com file would be reversed.
    domain2.com: domain1.com
     
  3. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Whoops, sorry. That was a typo in my post.

    I meant to say:

     
  4. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    Is there a file named domain1.com in your /etc/valiases also?
    This would be your user aliases forwards and if no user exists at this domain file. Exim looks for this file to be present also.
    If you were only failing all unknown users at domain1.com it would have *: :fail: No such person at this address
     
  5. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Yes the /etc/valiases file for domain1 does exist and just has:

    In it. Should I remove that line from that file then to get forwarding working without having any actual accounts at domain1?
     
  6. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    No you should leave that as is. Check the group ownership of those files? Matches the other domains, should be group 'mail'.
    Is domain1.com listed in /etc/localdomains
    Is your server picking up the MX record for domain1? 'dig MX domain1.com'
    When in CPanel under domain2.com, does it pick up domain1.com forward at the bottom of the email forwarder page?
     
  7. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Files are owned by the site with group "mail" as are all other alias files - permissions are the same on all of them as well.

    domain1 is indeed in /etc/localdomains

    DNS is pointing the MX at my server correctly.

    The forward shows up on the forwarders page for domain1 - but not on the page for domain2

    Adding individual forwards for users works fine, it's only the domain forwarding that's failing - but we really don't want to have to maintain aliases on domain1 every time we add a new account on domain2 - having any address at domain1 automatically forward to domain2 is pretty important.

    I found some other threads that suggested things like running /scripts/autorepair and /scripts/buildeximconf then restarting exim - I tried both of those and neither made any difference.
     
  8. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    The only thing I can think of is the /etc/vdomainaliases/domain1.com is not being accessed or there is an extra character in there. Maybe back that file up and recreate a new one. Make sure the users permissions are correct and they have access.
    chown acctowner:mail domain1.com
    chmod 644 domain1.com
    domain2.com should just be blank file with the same file permissions and ownership.
    Just to make sure I am clear. Everything I have been stating is for when email comes into domain1.com, all emails to be forwarded to domain2.com? Only the account owner of domain1.com will see the forward from CPanel. There isn't a filter for the test account to redirect mail is there? Would be listed in domain1.com under etc/vfilters.
    I am out of ideas...
     
  9. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Based on the sticky thread in this forum about a similar problem I think it's a problem with exim's configuration not finding the vdomainalises files. I've tried removing and recreating the file and checked the permissions but no luck. I looked in the exim config file though and couldn't find anything that would use the /etc/vdomainaliases files. But I tried resetting the exim config and doing a forced rebuild of exim and still can't find anything that references the vdomain files.


    Yep, that's correct all emails from domain1 forwrded to domain2. The /etc/vfilters are working - we had to add some temporarily for important addresses. But with or without them the domain alias isn't working.
     
  10. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    If you are looking from the WHM exim.conf editor, for whatever reason it is not visible. I have noticed this with other options in exim.conf. Like I can not see dk_remote for domainkeys. But if I open the exim.conf directly with nano, there it is. I just looked at mine from WHM and I can not 'see' the vdomainaliases line. Open up with nano and its there. Sits right on top of virtual_aliases

    Code:
    valias_domain_file:
      driver = redirect
      allow_defer
      allow_fail
      require_files = +/etc/vdomainaliases/$domain
      condition = ${lookup {$domain} lsearch {/etc/vdomainaliases/$domain}{yes}{no} }
      data = $local_part@${lookup {$domain} lsearch {/etc/vdomainaliases/$domain} }
    virtual_aliases:
        driver = redirect
        allow_defer
        allow_fail
        require_files = "+/etc/valiases/$domain"
        data = ${lookup{*}lsearch{/etc/valiases/$domain}}
        file_transport = address_file
        group = mail
        pipe_transport = virtual_address_pipe
    
    If I think of something else, I'll post back.
     
  11. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    Try running a dry run with exim on the address and follow through the path it runs. This should tell you if the vdomainaliases is being checked or not.
    exim -bt -d test@domain1.com
     
  12. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    I wasn't using the advanced editor, just using more to list/search though /etc/exim.conf directly.

    No sign of a vdomain line - that was why I tried the forced rebuild of exim.

    I tried: exim -bt -d test@domain1.com

    vdomain doesn't appear anywhere in the output. I can see the valiases in the output...but no sign of vdomainaliases
     
  13. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    Did you try forcing a rebuild of exim instead? /scripts/eximup --force I would renamed the exim.conf and exim.conf.local files before running. There is also a BSD version for rebuild if you are using BSD rebuildeximbsd.
    If that doesn't work, troubleticket. Sorry I am not of anymore help.
     
  14. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Yeah the /scripts/eximup --force was suggested in the other thread I'm watching and I tried it after backing up and removing a bunch of suggested config files first. Still no luck :(

    Thanks for all the help. I'm trying to get a ticket going...but my host just changed their support login and now I can't get in...so I'm also fighting through their support just to get to where I can access the ticket system again :( Not my week at all!
     
  15. jhitesma

    jhitesma Member

    Joined:
    Jun 17, 2007
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    My host ended up adding the following to the /etc/exim.conf:

    ==================================================================================
    valias_domain_file:
    driver = redirect
    allow_defer
    allow_fail
    require_files = /etc/vdomainaliases/$domain
    condition = ${lookup {$domain} lsearch {/etc/vdomainaliases/$domain}{yes}{no} }
    data = $local_part@${lookup {$domain} lsearch {/etc/vdomainaliases/$domain} }
    ==================================================================================

    That finally solved the problem.
     
  16. blkjck

    blkjck Well-Known Member

    Joined:
    Sep 17, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    It's odd that this is not being added with the eximup. It's working for now though. :) Might as well back it up incase upcp overwrites it.
    I found a reference to this also in this directory.
    /usr/local/cpanel/etc/exim/cf
    In this directory there is a file named virtual_aliases containing only this entry of code. I am guessing the cpanel build of exim looks to this folder for config settings. All these files contain a small blocks of code that is found inside the exim.conf
    These are the file names mine has...
    address_pipe
    localuser
    lookuphost
    virtual_aliases
    virtual_sa_user
    virtual_user
    virtual_userdelivery
     
    #16 blkjck, Feb 7, 2008
    Last edited: Feb 7, 2008
Loading...

Share This Page