One of the problems I've seen people ask about, over and over, is how to "split" a domain's email between multiple locations. For example, you may have multiple offices in different parts of the world, and you don't want all of your users connecting across the net to access their mailboxes on a server back at the main office... and/or you can't see the point in having email between two users in the same remote office ever having to leave that remote office.
Most people who face this problem run into one of two "problems":
There is no obvious way to forward an existing message to another server without changing the email address. The example below will show how to do this using the qmail-remote program, which is a standard part of qmail but is not normally called by a user.
There is no obvious way to handle some mailboxes with a domain on one server, and other mailboxes within the same domain on a different server. There is a way to do it, and it results in a smoother flow of mail (i.e. the process of forwarding a non-local message to another server is not done as part of a delivery) but it involves a lot more changes to qmail's control files, and also prevents you from being able to freely use vpopmail and/or qmailadmin on some of the servers.
I had thought about describing this other method here, and I may still add it in later, but for now I've decoded to "not go there" because of the number of questions I can see it generating from people who don't really want to understand qmail and just want to have "solutions" spoon-fed to them (i.e. the typical "qmailrocks" user.)
The examples below will talk about a fictional company called Megacorp, which owns the domain "megacorp.xyz" (I am deliberately using a fictional domain name here.) Their main office is in New York, they have branch offices in Atlanta and Denver. They want every one of their employees to have a "firstname.lastname@example.org" email address, and if an employee at one office sends an email to another employee at the same office, they don't want that email to leave that office.
Here is a basic list of the locations, their public IP addresses, and a few users at each location (with names chosen to make it obvious which office each user works at.)
|New York - 10.1.1.1||Atlanta - 10.2.2.2||Denver - 10.3.3.3|
Each of the three locations has a mail server (and of course they're all running qmail.) Each server uses vpopmail to manage the mailboxes at that location.
There are a few different possibilities for how to configure the servers, depending on various factors such as the availability and cost of bandwidth and static IP addresses at each location.
This example demonstrates the simplest case- every office knows where every mailbox can be found, and any messages for any other location are sent directly to that location.
All three servers are configured with .qmail-userid files, and .qmail-userid-default symbolic links, for every mailbox which is not local to that server. For example, the New York server is configured like so:
vpopmail manages the domain megacorp.xyz
The ~vpopmail/domains/megacorp.xyz directory contains the following files:
|.qmail-alex|||qmail-remote '[10.2.2.2]' "$SENDER" "$EXT@$HOST"|
|.qmail-alex-default||(Symbolic link to .qmail-alex)|
|.qmail-alice|||qmail-remote '[10.2.2.2]' "$SENDER" "$EXT@$HOST"|
|.qmail-alice-default||(Symbolic link to .qmail-alice)|
|.qmail-dave|||qmail-remote '[10.3.3.3]' "$SENDER" "$EXT@$HOST"|
|.qmail-dave-default||(Symbolic link to .qmail-dave)|
|.qmail-diane|||qmail-remote '[10.3.3.3]' "$SENDER" "$EXT@$HOST"|
|.qmail-diane-default||(Symbolic link to .qmail-diane)|
The directory also contains the standard .qmail-default file created by vpopmail. If you want the domain to have a real "catch-all" mailbox, you need to make sure that on the servers which DON'T contain that particular catch-all mailbox, you configure the catch-all as "forward to an external email address" (even though it's in the same domain) rather than "deliver to a local mailbox". Otherwise, if you're going to have "catch-all bounce" or "catch-all delete", make sure you set it the same way on every server.
One sticky point about this is the "postmaster" address. All three servers will have a physical "postmaster" mailbox, and all three servers will send any postmaster mail to their own local version of the mailbox. The easiest way to handle this is to choose one server which will have the "real" postmaster mailbox, and on the other servers, create a ".qmail-postmaster" file which calls qmail-remote to forward any messages to the one server which has the "real" mailbox. Note that this will not prevent the postmaster account from working on the machine (for SMTP AUTH, or for logging into qmailadmin) but it will prevent any mail sent to the email@example.com address from being stored in the local mailbox on that server.
Another sticky point is that if you set things up like this, you will have to update the mail servers at every location whenever you add, remove, or change a mailbox anywhere in the domain. If you do this, you may want to write some kind of a script to maintain the mailboxes and .qmail-* files on all of the servers, from one central location.
Again, there are other ways to set things up. The example above was chosen because it is the easiest to understand. However, if you really understand how qmail-send works (i.e. how the virtualdomains file is parsed) you can make the same thing happen more smoothly, without having to do a delivery in order to move messages to the correct servers. Personally, I think this other method is better, however it involves setting up separate domains (or sub-domains) for each server, and directly changing a few of qmail's control files.
I'm not going to go any further into the details right now- if you understand how qmail works (or if you're not afraid to read qmail's man pages to fill in the missing pieces) then what I've already said should be enough for you to figure out the rest on your own.
Like just about anything else involving qmail, it all boils down to UNDERSTANDING what you are doing when you set up something like this.