Maia Mailguard

A Spam and Virus Management System

Version 1.0.2c

Thank you ReachOne Internet for hosting our website!

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 is going to end up--all we know is that the mail relay for the domain should know where to send it next.

In the simplest case, the mail relay for the domain is a host in that domain--say, 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 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 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, being hosted there as well, and it might have another user named "joe". Now we have a problem. We have and, 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 into something like, where 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 "". Other MTAs may choose a slightly different rewriting method--perhaps, or, or even jsmith@[]. To the outside world, Joe's address is still, 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 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 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.

  $address_rewriting_type     Rewriting Method  
0 No rewriting takes place
1 ->$routing_domain
2 -> user_example_com@$routing_domain
3 ->$routing_domain
4 No rewriting, but username = e-mail address
5 -> user@$routing_domain

In other words, if you find that is being rewritten by your MTA-RX as, you would set $routing_domain = "" 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.


Edit your 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 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'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.

FEATURE(`virtusertable', `hash /etc/mail/virtusertable.db')dnl