In a previous section we set up the fastforward package as a means of handling user aliases.

Yet another use of fastforward is to centrally configure email distribution to any number of satellite offices, in a way that is transparent to all senders.

Consider this: you are responsible for a multi-national organization --the omnipotent "example.com"-- headquartered in Geneva, with field operations in Amman, Ankara, Athens, Beirut, Berlin, Bogota, Dublin, Durban, Havana, Lahore, Lisbon, London, Manila, Moscow, Mumbai, Naples, Ottowa, Prague, Riyadh, Sydney, Tehran, Vienna, Warsaw, and Zagreb, to name a few.

You would like all senders to be able to address email simply to:

and have the message forwarded to the recipient at her current duty station, no matter where in the world that may be.

Also, you want email at each duty station to be handled efficiently, so that internal emails between colleagues at the same office will be treated as local, and not require a round-trip to the head office.

The functional topology for this email network (as distinct from its IP topology) will be the classic "star". That is, Geneva will act as the center of the star, forming the hub of the email network. Each field office will represent a "point" of the star.

"ankara"               "beirut"
22.33.44.55            9.9.9.9
  +---+                 +---+
  |   |                 |   |
  |   |                 |   |
  |   |\               /|   |
  +---+ \             / +---+
         \           /
          \         /
           \       /
            \     /
             +---+            +---+
             |   |            |   |
             |   |------------|   |
             |   |            |   |
             +---+            +---+
            "geneve"         "durban"
          aka "mailhub"     12.23.34.45
            1.2.3.4
etc.           :
               |
               |
               |
             +---+
             |   |
             |   |
             |   |
             +---+
            "moscow"
          81.72.63.54

Notice that each field office is setup with its own static IP address with a local ISP. The Geneva office then uses tinydns to publish DNS records for itself and all the field offices. Specifically, each field office has its own MX record for its fully qualified domain name, while the Geneva office has an MX record for both "example.com" and "mailhub.example.com". This setup could be provided by the following command sequence on "geneve":

# cd /service/tinydns/root
# ./add-host geneve.example.com 1.2.3.4
# ./add-alias mailhub.example.com 1.2.3.4
# ./add-mx example.com 1.2.3.4
# ./add-mx mailhub.example.com 1.2.3.4
# ./add-host ankara.example.com 22.33.44.55
# ./add-mx ankara.example.com 22.33.44.55
# ./add-host beirut.example.com 9.9.9.9
# ./add-mx beirut.example.com 9.9.9.9
...
# make

Now we will consider the qmail setup at the center of this network. The control/locals file on "geneve" includes these entries:

example.com
geneve.example.com
mailhub.example.com

The control/rcpthosts file includes these entries also. Since "geneve" is the MX host for all mail sent to the "example.com" domain, and since control/rcpthosts and control/locals includes "example.com", "geneve" will receive all mail to "example.com" and treat it as local.

"geneve" has a fastforward installation, exactly as described here. That is, /var/qmail/alias/.qmail-default has this one-line entry:

| fastforward -d /etc/aliases.cdb

Now the setup in /etc/aliases on "geneve" to handle the remote offices:

### local users/aliases, as usual:
webmaster: genny-webmaster
personnel: gerri-personnel

### forwards to ankara office:
alice: alice@ankara.example.com
arnie: arnie@ankara.example.com
alexy: alexy@ankara.example.com

### forwards to beirut office:
betty: betty@beirut.example.com
binty: binty@beirut.example.com
bjorn: bjorn@beirut.example.com

### forwards to durban office:
danny: danny@durban.example.com
dolly: dolly@durban.example.com
doris: doris@durban.example.com

### etc.

Of course, don't forget to run /var/qmail/bin/newaliases to rebuild /etc/aliases.cdb!

It should be clear what will happen now. Email sent to <alexy@example.com> will be received by "geneve" and forwarded to <alexy@ankara.example.com>; email sent to <binty@example.com> will be forwarded to <binty@beirut.example.com>; and so forth.

Users posted in Geneva, such as "genny", simply have user accounts on "geneve" that are handled normally with local delivery.

That takes care of Geneva. Now, what about the field offices?

Each field office has a full qmail installation, of course, including fastforward. As an example, we'll look at the host "durban". It's control/locals and control/rcpthosts files both contain:

example.com
durban.example.com

So "durban" will now receive all email forwarded from "geneve" addressed as recipient@durban.example.com. As long as qmail on "durban" can find delivery instructions for recipient --that is, there are local accounts for "dolly", "danny", etc.-- then the message will reach its destination.

This system also handles mail between colleagues at the same office without difficulty. If "doris" sends a message to <danny@example.com>, "example.com" is in control/locals, "danny" has an account on "durban", and the message is delivered normally.

But now for the big-money question: How do messages from "dolly" in the Durban office get to "genny" in Geneva and "alexy" in Ankara? Does "dolly" need to address these messages differently somehow?

Nope, just use <genny@example.com> and <alexy@example.com> like everyone else. The trick is in the fastforward installation on "durban". The /var/qmail/alias/.qmail-default setup on "durban" --and all the satellite offices-- looks like this:

| fastforward -p -d /etc/aliases.cdb
| forward ${LOCAL}@mailhub.example.com

There are two key differences to notice between this setup and the usual fastforward setup on "geneve":

• fastforward is called with the -p option, for "pass-through" mode.

• The second line forwards all messages not handled by fastforward, back to Geneva.

qmail on "durban" starts out thinking it should find local user accounts for "alexy" and "genny", since "example.com" is in its control/locals. But failing to find them, qmail then tries the special user "alias", and the fastforward instruction on the first line in /var/qmail/alias/.qmail-default.

Now, fastforward also fails to find an entry for "alexy" and "genny" in /etc/aliases.cdb. But instead of bouncing the message, it passes the message on for further processing. This is the effect of the -p option.

Then the message can be handled by the forward instruction, and so the envelope for "genny" is rewritten to <genny@mailhub.example.com> and "alexy" to <alexy@mailhub.example.com>. Since "mailhub.example.com" is not in control/locals on "durban", these messages are queued for remote delivery back to Geneva.

Once the messages get back to Geneva, qmail on "geneve" finds a local account for "genny" in the usual way. Meanwhile, the fastforward installation on "geneve" will route the message for "alexy" onward to <alexy@ankara.example.com> in Ankara.

In this way, "geneve" functions as the hub for all inter-office mail, as well as the central processing station for all mail intended for the "example.com" domain.

The sysadmin in Geneva has the most work to do, keeping /etc/aliases.cdb up to date. Hopefully, communications between IT and HR are efficient and well-coordinated, and a central database has been developed to make staff transfers, terminations, and new appointments automatically available to update the aliases database.

Outside of Geneva, field offices need not replicate this database. All they need to do is make sure the staff posted to their office have a user account for receiving mail locally.

One final point: nothing about this use of fastforward requires an operation of international scale. A similar system will work equally well for offices within the same country, the same campus, --why, even among departmental servers within the same building.