Zimbra offers Open Source email server software and shared calendar for Linux and the Mac
Go Back   Zimbra :: Forums > Zimbra Collaboration Suite > Administrators

Welcome to the Zimbra :: Forums!
Welcome, if you would like to post a comment please register. We also encourage you to explore all things Zimbra with our team and members of the community.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 09-29-2008, 01:43 PM
New Member
 
Posts: 3
Default Config Zimbra to answer on two domains?

Hi All,

We're planning on migrating all of our users from our existing Sendmail setup to Zimbra. We've been digging around the forums trying to find a way to forward all new email destined to the old domain (oldmail.org) to our Zimbra setup (newmail.org). We've found a couple of posts relating to aliases and multiple domains that sound like they might be what we're looking for, but we could use some clarification and/or advice on the best way to proceed.

In a nutshell, when we go live with Zimbra we would like to avoid having to manually set forwarding up for 2000 accounts in our old system.

Thanks in advance.
Reply With Quote
  #2 (permalink)  
Old 09-30-2008, 08:04 PM
Trained Alumni
 
Posts: 29
Default

Idea #1 --
Simply host both domains on your Zimbra server.
Code:
[zimbra@mail ~]zmprov cd oldmail.org
[zimbra@mail ~]zmprov cd newmail.org
Migrate users intact with accounts named user@oldmail.org however you choose to do that. Then bulk rename them with a script to user@newmail.org and add an alias for user@oldmail.org. Zimbra will catch either address and place it in the users Inbox.
Code:
[zimbra@mail ~]zmprov ra user@oldmail.org user@newmail.org
[zimbra@mail ~]zmprov aaa user@newmail.org user@oldmail.org
Our employees have two email addresses on two domains in our Zimbra server in each account.
Code:
[zimbra@mail ~]$ zmprov ga first.last@domain.tld | grep ^mail:
mail: first.last@domain.tld
mail: first.last@anotherdomain.tld
mail: first@domain.tld
mail: first@anotherdomain.tld
Idea #2 --
We host several domains on our system and split one of them to another domain outside our system. Anyone who isn't a user on Zimbra gets translated with a new domain and forwarded on to another email server.

Code:
[zimbra@mail ~]$ zmprov gd olddomain.tld | egrep "CatchAll|Transport"
zimbraMailCatchAllAddress: @olddomain.tld
zimbraMailCatchAllForwardingAddress: @newdomain.tld
zimbraMailTransport: smtp:mail.newdomain.tld
It's based on the following... Split Domain - Zimbra :: Wiki

We only do this because we keep some mail and forward the rest. Otherwise the first idea is much easier to implement and troubleshoot.
Reply With Quote
  #3 (permalink)  
Old 10-01-2008, 03:35 AM
Member
 
Posts: 10
Default

A quicker way than creating aliases for all the users is just to create a domain alias, explained here: ManagingDomains - Zimbra :: Wiki

Have both domains on your Zimbra system, rename all the accounts in bulk as mentioned above, delete the old domain, and then create a domain alias, per the link above. That way, existing users and new users alike will automatically get mail for both domains without the need to manage aliases, and it's a simple deletion later.
Reply With Quote
  #4 (permalink)  
Old 10-01-2008, 04:24 AM
Trained Alumni
 
Posts: 29
Default

I just got this in my email twice saying it was posted to this thread, but it wasn't. So I'm posting it for him. It's from nate.olmstead.

Idea #3 --
Quote:
A quicker way than creating aliases for all the users would be to create a domain alias, per the instructions at: ManagingDomains - Zimbra :: Wiki

Basically, have both domains on the Zimbra host. Batch rename all of the accounts as mentioned above so they exist in the new domain. Delete the old domain and create the domain alias. That way, existing users and new users alike automatically receive mail for both domains and it's a quick deletion later if you choose.
It essentially points to a wiki article similar in content to the one I used to create CatchAll forwarding. I'm sure this method will work too.

Good luck.
Reply With Quote
  #5 (permalink)  
Old 10-01-2008, 05:31 AM
Member
 
Posts: 10
Default

Sorry about that. Apparently the "Quick Reply" button didn't do quite as I expected. D'oh!
Reply With Quote
  #6 (permalink)  
Old 10-01-2008, 06:24 AM
Moderator
 
Posts: 2,207
Default

Domain aliasing can be a big pain because it breaks the "reject unknown recipient" feature.

See here : Bug 14129 – no 550 unknown recipient rejection or out of office replies for alias domains
Reply With Quote
  #7 (permalink)  
Old 10-01-2008, 10:09 AM
New Member
 
Posts: 3
Default

Thank you all for taking the time to answer my question. After reading Klug's response regarding Bug 14129, I'm obviously concerned about the "reject unknown recipient" feature bouncing mail through my ISP and blacklisting my domain.
I am curious if the Domain CatchAll method would work cleanly with domain aliasing though. In reading the Wiki article, ManagingDomains, under Domain Catchall, it states:

"If the users "john@domain.com", "webmaster@domain.com", and "xyznobody@domain.com" don't exist, and mail arrives for them, it will be delivered to the catchall account "user@domain.com". This will increase the amount of spam delivered, and can lead to being blacklisted. To remove the catchall from an email account, unset the catchall address: "

I'm not understanding why this would lead to being blacklisted. If the mail is being delivered to the catchall account, why would this lead to any blacklisting at all. The mail is being delivered, not bounced back through the ISP. Any insight would be appreciated. Thanks in advance.
Reply With Quote
  #8 (permalink)  
Old 10-01-2008, 10:17 AM
Moderator
 
Posts: 2,207
Default

Bounce is only one side of the issue (and yes, setting a catchall will allow you not to bounce).

If you accept any mail (even if the recipient does not exist), your server will spend CPU cycles and RAM treating (antivirus and antispam) these emails.

Depending on how badly your domain are spammed, this can lead to an _awfull_lot_ of lost CPU cycles and RAM...
Reply With Quote
  #9 (permalink)  
Old 10-01-2008, 06:58 PM
Trained Alumni
 
Posts: 29
Default

It's not a "CatchAll" account. It's a "CatchAll" forward. It's a little like Jai alai - Wikipedia, the free encyclopedia. The CatchAllAddress modifies the "RCPT TO:" field in the message replacing the old domain with the new one and re-submits it to smtp. Lots of messages could go unanswered that way. As I understand it mail to invaliduser@oldmail.org will always create a message to invaliduser@newmail.org. I believe that both get processed through spam filters. Bounce messages may not be correctly delivered because the submitting SMTP server is Zimbra itself. Anyway you can read the bug.

If the goal is to move the identity of the organization from oldmail.org to newmail.org, why not create all the current users as user@newmail.org and with alias of user@oldmail.org? A simple text file of usernames and a recursive zmprov script should take care of it in a minute or two. Or you could migrate users creating them on the fly and use zmprov to create your user list from which you recursively create the aliases.

As you add new people, there will be no need to identify them as newuser@oldmail.org, so don't even create it for them. Just give them newuser@newmail.org.

Bounces will all work. No extra cycles will taken accepting mail for anyone who doesn't exist.

Server configuration would be as standard as can be. CatchAll can't be seen in the admin web interface, but user aliases can.
Reply With Quote
  #10 (permalink)  
Old 10-01-2008, 07:41 PM
Moderator
 
Posts: 2,207
Default

That's (one alias per account) is also the solution we're using to avoid all the "domain aliasing" issues.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads

Why Join?

Registering let's you ask questions, makes it easier to search, displays any files attached to posts, and notifies you about replies.

blog.zimbra.com




 

SEO by vBSEO ©2011, Crawlability, Inc.