valiases - Redistribute mail send to a virtual mail address


valiases [option]... [domain aliases]...

valiases [option]... -d alias-dir [domain]...

valiases -H


valiases may be used to set up virtual mail addresses pointing to a real mail address being permanently under service. By using valiases the real mail address may then resend the incoming mail as it would have been done by a sendmail running the virtual domain. This is useful if you have no access to /etc/aliases file on a machine connected to the Internet permanently.

See "USING A LOCAL MAJORDOMO" for some notes on using a local majordomo installation with valiases.

During normal operation valiases expects a mail on stdin. It analyzes the mail for occurences of a virtual mail address. valiases considers a mail address virtual if it is in the domain domain and uses the local part of one of the aliases defined in aliases for that domain. For each virtual mail address found, valiases redistributes the mail using sendmail using the alias file aliases.

The virtual mail addresses are searched in the To: and Cc: header fields of the original mail. If any Redist-To: and Redist-Cc: header fields in the mail exist, these are considered instead of the normal header fields.

valiases adds a header line to the redistributed mail which allows to detect loops. valiases will not process a mail for a virtual mail address in domain more than once even if it is received again.



Instead of normal operation check all aliases files for correctness. This includes checks for command and file aliases.

The mapping contained in the alias files is put to a log file if one is given.

-d alias-dir

If this option is given all alias files are expected in alias-dir and named after the domain domain they apply to.


Ignore Redist-To and Redist-Cc header fields.

-l log

Log all operations by appending to file log. If this is not given all operations are performed silently.

-p lines

Purges first lines Received: lines in the header. If lines is 0, all Received: lines so far are purged.

This option is useful since too many Received: lines may cause a mail agent to fail with Too many hops. However, purging Received: lines always cuts some debugging possiblities so your milage may vary.

How many lines to purge depends on your setup. The most useful number seems to be the number of Received: lines put in the mail on behalf of delivery to the real mail address instead of the virtual mail address. In my case this number is 4.

-r real-address

In addition to looking at the To:, Cc: and perhaps Redist-To:, Redist-Cc: header lines, consider the Received: lines. real-address has to be the real address used for feeding valiases.

Each Received: line is checked for a mail address. If a Received: line is found with mail address real-address, the first following Received: line with a different mail address is also used as a candidate for a virtual mail address. This address should be the original envelope address.

This feature works best (or at all) if the site where the virtual mail address is redirected to address real-address puts two consecutive Received: lines in the mail the first showing the real-address address and the second showing the original envelope address. Example:

        Received: from ... for; ...
        Received: from ... for; ...

Note: When using majordomo you must use this option, since the internal ...-outgoing never show up in one of the usual headers. They are used as envelope addresses only.


Operate verbose.


Generate the man page for this program on standard output.


The program exits without an error if there is at least one occurence of a virtual mail address. If there is no virtual mail address at all, the program exits with an error status 1.

This can be used to control the operation of slocal in a .maildelivery file. An entry of

        *       -       |       A       "<path>/valiases <domain> <aliases>"

may be the right thing to do.

If -c is given the program exits without an error only if all alias files are correct.


valiases has been mainly created to support a local majordomo installation. The following notes on installing such a majordomo might be helpful.

The most important thing is that such a majordomo does not need any special permissions such as root permissions or being in group daemon. Here are some hints following the description of a clean install in the INSTALL file of majordomo Version 1.94.5.


You need no special group or user id to run majordomo under. Your personal user and group are just fine.


The installation directory may be anywhere but something like $HOME/lib/majordomo seems to be a good choice.


You do not need to give permissions to anyone else but yourself. 600 and 700 are fine.

Comment the POSIX section and uncomment the non-POSIX section. We do not need root set-uid.


Set $whereami to the domain you want your local majordomo to appear to be in.

Remove the -f\$sender flag from $mailer and $bounce_mailer. Normally this sets the envelope From address but may not be used if sendmail is not run by a trusted user. This is the only disadvantage of such a installation as far as a I can see.


When adding aliases for a new list to aliases note that no program may use local addresses. In particular for aliases using the resend command, they have to give the fully qualified address as the final argument (e.g. new-outgoing@domain).

When setting up valiases you must use -r because only this way the original envelope addresses are available.


If valiases receives a single mail via two or more distinct addresses independently from each other, valiases has no way to know that this is actually the same mail. Thus it handles each mail independently which may result in duplication of the mail. A solution to this problem would involve a local history on sent mails.


Because this is a Perl program, Perl (>= V5.005) must be installed.

This program needs the great MailTools package installed. Try


slocal, majordomo, resend, sendmail, aliases


Stefan Merten <>


This program is licensed under the terms of the GPL. See