Virtual Hosts, Aliases, and E-mail Addresses

An e-mail address does not contain all the information required to route the mail to its intended recipient. Instead, e-mail relies on a system of "relays" at various points along the way to use their own specialized knowledge to route the mail to the next appropriate relay. There's no sure-fire way to tell where mail to joe@example.com is going to end up--all we know is that the mail relay for the example.com domain should know where to send it next.

In the simplest case, the mail relay for the example.com domain is a host in that domain--say, mail.example.com--and mail for user "joe" gets stored there for him to pick up with a POP3-compliant mail client. The mail relay (or mail transfer agent, or MTA) in this case only services the example.com domain, so things are pretty straightforward.

More often, though, a single MTA will service multiple domains, especially if it's being operated by an ISP. The example.com domain may be just one of dozens (or hundreds, or thousands) of domains the ISP hosts on its servers, and its MTA has to be aware of all of them. There might be another domain, say, example.net being hosted there as well, and it might have another user named "joe". Now we have a problem. We have joe@example.com and joe@example.net, so we can't just have a mailbox for "joe" anymore.

Most MTAs these days support virtual hosting, a means of aliasing, or rewriting e-mail addresses in one manner or another to ensure that mailbox and username conflicts are avoided. In our example, the MTA might rewrite joe@example.com into something like joe.example.com@isp.net, where isp.net is the ISP's own domain. That way, the "user" portion of a user@domain address is still unique--the "user" in this case becomes "joe.example.com". Other MTAs may choose a slightly different rewriting method--perhaps joe_example_com@isp.net, or joe@example.com@isp.net, or even jsmith@[127.0.0.1]. To the outside world, Joe's address is still joe@example.com, but after the mail is received by the ISP's MTA, it gets rewritten according to the MTA's virtual hosting rules.

Why is this important to us? Well, remember that amavisd-maia is sandwiched between your MTA-RX (upstream) and your MTA-TX (downstream). It gets fed e-mail from your MTA-RX, so amavisd-maia may never see joe@example.com if your MTA-RX has rewritten that address as part of its virtual hosting support. The only e-mail addresses that matter to amavisd-maia are the ones it can see, so it's important that you understand how your MTA-RX is rewriting e-mail addresses (if at all). You can test this out for yourself just by sending yourself a test e-mail, and watching the amavisd-maia log file. You should see something like:

Apr  5 23:11:46 mail.example.com amavisd[19111]: (19111-02) Passed, <sender> -> <recipient>, Message-ID: <message-ID>, Hits: <score>

Check the <recipient> in particular, to see whether it's different from the e-mail address you used when you addressed the mail to yourself. If you sent mail to you@yourdomain and it showed up in the amavisd-maia log file as something else (possibly you.yourdomain@ispdomain or somesuch), then you've got two options to choose from:

1. You can tell Maia how your MTA-RX is rewriting e-mail addresses, so that Maia can interpret them correctly, or


2. You can reconfigure your MTA-RX to not do any address rewriting, and then configure your MTA-TX (downstream) to do that rewriting instead--after it passes through amavisd-maia.

Telling Maia How to Handle Rewritten E-mail Addresses

If you choose the first option, you can use the $routing_domain and $address_rewriting_type settings in your config.php file to tell Maia how e-mail addresses are being rewritten by your MTA-RX.

In other words, if you find that user@example.com is being rewritten by your MTA-RX as user@example.com@isp.net, you would set $routing_domain = "isp.net" and $address_rewriting_type = 3.

Delaying Address Rewriting Until After amavisd-maia

If you choose instead to avoid the address-rewriting issue in the first place, you need to make some configuration changes to your MTA-RX and MTA-TX. In general terms, you want to disable any rewriting at the MTA-RX stage, so that it simply relays the mail to amavisd-maia as it receives it, and then have MTA-TX do the address-rewriting later before delivery. How you accomplish this depends on your particular MTA software, of course.

NOTE: Delaying the rewriting of virtual addresses until the MTA-TX stage may leave your mail server exposed to dictionary attacks, unless you have your MTA-RX configured to test the validity of the e-mail addresses it receives. In most cases this involves creating a list of all the valid recipient addresses and rejecting mail intended for any other address.

Postfix

Edit your master.cf file and add/modify the following items (excerpted from README.postfix in the amavisd-new distribution):

# handle both the canonicalization and virtual_alias_maps later
# (this will provide content filter with largely unmodified addresses)
#
pre-cleanup  unix n	-	n	-	0	cleanup
    -o virtual_alias_maps=
    -o canonical_maps=
    -o sender_canonical_maps=
    -o recipient_canonical_maps=
    -o masquerade_domains=

# The following is the normal cleanup daemon. No header or body checks here,
# because these have already been taken care of by the pre-cleanup service
# before the content filter.  The normal cleanup instance does all
# the virtual alias and canonical address mapping that was disabled
# in the pre-cleanup instance before the content filter.
#
cleanup	unix	n	-	n	-	0	cleanup
    -o mime_header_checks=
    -o nested_header_checks=
    -o body_checks=
    -o header_checks=

# These are the usual input "smtpd" and local "pickup" servers already
# present in master.cf. We add an option to select a non-default
# cleanup service.
#
smtp      inet  n       -       n       -       -       smtpd
    -o cleanup_service_name=pre-cleanup
pickup    fifo  n       -       n       60      1       pickup
    -o cleanup_service_name=pre-cleanup

Sendmail

Sendmail's virtual hosting feature is the "virtusertable" mechanism, which treats e-mail addresses as aliases, rewriting them as specified in your virtusertable file. If you're using Sendmail with amavisd-maia, it's presumably in a dual configuration--one instance running as your MTA-RX, another as your MTA-TX. If you only want address-rewriting to take place at the MTA-TX stage (i.e. downstream from amavisd-maia), you simply have to remove the virtusertable feature and VIRTUSER_DOMAIN() entries from your MTA-RX's configuration file and put it in the configuration file for your MTA-TX instead.

VIRTUSER_DOMAIN(`domain1')dnl
VIRTUSER_DOMAIN(`domain2')dnl
VIRTUSER_DOMAIN(`domain3')dnl
...
VIRTUSER_DOMAIN(`domainn')dnl
FEATURE(`virtusertable', `hash /etc/mail/virtusertable.db')dnl