7

I have a mail server running Sendmail that hosts multiple mail domains. So for instance, emails addressed to @aaa.com and @bbb.com are both going to this same server. All this time I am using /etc/mail/virtusertable to manage the mappings of different users of different mail domains to different local accounts.

But now I have just found out /etc/aliases might be doing the similar things.

  • What is the different role of /etc/aliases and /etc/mail/virtusertable?
  • What aliases can do but not virtusertable, and vise versa?

I have searched through the web but can't find any site that compares the differences in a very detailed way.

sylye
  • 241
  • 5
  • 13

4 Answers4

6

Key differences between virtusertable and aliases in sendmail

virtusertable provides one to one mapping of recipient address. aliases provide one to many mapping (handy for mailing lists).

aliases map "domain-less" recipient (recipients in local email domains with stripped domain part of email). virtusertable maps full recipient address.

virtusertable handles remapping of "all other/remaining addresses in email domain".

"virtusertable to alias" mapping may be used to get one to many mapping.


Wizard level hint: It is possible to make sendmail.cf handle aliases for full emails (user part and domain) but sendmail.cf generated using m4 files provided by sendmail.org does not handle it. Implementing it will not be very complicated but IMHO some unexpected "side effects" are guaranteed => proper testing period will be LONG.

AnFi
  • 5,883
  • 1
  • 12
  • 26
  • Your answer gives the most significant difference of the both config files. Sharp and clear. – sylye Nov 26 '15 at 07:05
5

Short Answer:

Aliasing is the process of converting one local recipient name on the system into another and Aliasing occurs only on local names. Which means, the username must be available via getpwnam from the password database:

e.g., the local password file /etc/passwd, NIS, and LDAP.

The sendmail virtusertable feature enables support for the virtual users, meaning it maps non-system users.


I have quoted the following from here. Very well explained, please have look.

/etc/mail/aliases

This database file contains a list of virtual mailboxes that are expanded to users, files, programs, or other aliases. Here are a few entries to illustrate the file format:

root: localuser
ftp-bugs: joe,eric,paul
bit.bucket:  /dev/null
procmail: "|/usr/local/bin/procmail"

The mailbox name on the left side of the colon is expanded to the target(s) on the right. The first entry expands the root mailbox to the localuser mailbox, which is then looked up in the /etc/mail/aliases database. If no match is found, the message is delivered to localuser. The second entry shows a mail list. Mail to ftp-bugs is expanded to the three local mailboxes joe, eric, and paul. A remote mailbox could be specified as user@example.com. The third entry shows how to write mail to a file, in this case /dev/null. The last entry demonstrates how to send mail to a program, /usr/local/bin/procmail, through a UNIX® pipe. Refer to aliases(5) for more information about the format of this file.

/etc/mail/virtusertable

This database file maps mail addresses for virtual domains and users to real mailboxes. These mailboxes can be local, remote, aliases defined in /etc/mail/aliases, or files. This allows multiple virtual domains to be hosted on one machine.

The following example demonstrates how to create custom entries using that format:

root@example.com                root
postmaster@example.com          postmaster@noc.example.net
@example.com                    joe

This file is processed in a first match order. When an email address matches the address on the left, it is mapped to the local mailbox listed on the right. The format of the first entry in this example maps a specific email address to a local mailbox, whereas the format of the second entry maps a specific email address to a remote mailbox. Finally, any email address from example.com which has not matched any of the previous entries will match the last mapping and be sent to the local mailbox joe.

Now a little more detailed answers to your questions:

  • The aliases database file contains a list of virtual mailboxes that are expanded to users, files, programs, or other aliases.
  • This virtuser database file maps mail addresses for virtual domains and users to real mailboxes. These mailboxes can be local, remote, aliases defined in /etc/mail/aliases, or files. This allows multiple virtual domains to be hosted on one machine.
  • The sendmail virtusertable feature on the other hand configure support for the virtual user table. The virtual user table maps incoming mail destined for someuser@host to someotheruser@otherhost. One can think of this as an advanced mail alias feature, one that operates using not just the destination user, but also the destination domain. The key portion (on the left) must be either a full address (user, host, and domain name), or an address without a host part (just a domain).
Diamond
  • 8,791
  • 3
  • 22
  • 37
  • 1
    Some years later, but still at the top of Google results for some keywords. Therefore: Your answer is not completely correct. I definitely have "virtual" users in the left column of my aliases file (i.e. users which are not in `/etc/passwd`, `/etc/shadow` and the like). This is not new functionality; I am using that configuration since several years without any problem. – Binarus Apr 02 '18 at 15:39
  • @Binarus, hi, the answer above if you read more carefully is full of quotes and little of my own invention. Still I have explained the "local username" part a little more to clarify it. As to your own particular case, I cant really comment. – Diamond Apr 03 '18 at 08:22
  • Regarding my case: for example, in `virtusertable`: `foo@mydomain.com list-01`, and in `aliases`: `list-01: john,fred`. On that systems, `list-01` is *not* in *any* password or user database (neither `/etc/passwd` nor SASL nor any other). It seems that `aliases` treats all "virtual" users which are "produced" by `virtusertable` as expected. – Binarus Apr 03 '18 at 08:50
  • 1
    Additionally, having lost a lot of time trying to configure sendmail according to it, I can tell for sure that this BSD handbook is plain wrong at least for sendmail *on Linux* in my version. For example, it clearly states that the real mailboxes (right hand side) in the `virtusertable` can be files. If I try that, I am getting errors logged from sendmail stating exactly the opposite: "Can't mail to files." (exact wording may be inaccurate, can't re-test at the moment). But the mileage may vary on BSD - I can't test this. – Binarus Apr 03 '18 at 09:00
2

The main difference that I recall is that virtusertable may contain domain information as well as user information; that is; foo@example.com and foo@example.co.uk are both valid and distinct left-hand-sides in virtusertable, but used together in aliases they will produce a duplicate alias name error.

That still leaves a whole group of entries that can legitimately go in either; my feeling is that one should use aliases wherever possible, leaving virtusertable for those things that are domain-specific.

bangal (q.v.) notes some more important differences, eg the ability to send email to pipes and files.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Point 1: virtualusertable is searched recursively as well. I have just tested. If I put foo6@aaa.com pointing to foo@yahoo.com and foo7@aaa.com pointing to foo6@aaa.com, sending email to foo7@aaa.com will able to reach foo@yahoo.com Point 2: I did test putting 'foo@aaa.com' pointing to foo in /etc/aliases, and it works. (aaa.com mx record already being set to point to this server). The email did reach my account mailbox in 'foo'. So it seems like both features are in fact workable in virtusertable and aliases. – sylye Nov 25 '15 at 08:31
  • You're right about point 1; I've looked for an up-to-date reference, and the bits about single pass have gone; that's good. Thank you! For point 2, your test is inadequate: you will need a *second* aliases entry for `foo@bbb.com`, pointing to user `bar` (where `bar`exists and `bbb.com` is also locally-deliverable), to confirm that domain information is being properly accounted for in `aliases`. I would be very interested to know the results of that test. – MadHatter Nov 25 '15 at 09:03
  • 1
    To save you the effort, I've done that test: you cannot use `aliases` as you would `virtusertable`, to handle `foo@example.com` and `foo@example.org` *differently*. – MadHatter Nov 25 '15 at 09:27
  • You are correct that aliases can't handle `foo@example.com` and `foo@example.org` differently. @Andrzej A. Filip did point out that. But if you use the format of `foo@aaa.com` in aliases, it will accept without giving you error either:) Of course it's pointless to put the domain name in aliases since it can't differentiate it. Appreciated a lot for your input! – sylye Nov 25 '15 at 10:08
1

Try this:

If your MTA server is the primary MX for a bunch of DOMAINS, you route them through virtusertable. Virtusertable allows you to pick-off individual destination emails such as "abuse@..." and "postmaster@" and forward everything else to a single mailbox or another server entirely with a different name but keeping everything left of the '@' intact. For example:

    abuse@xyz.com:         helpdesk                   <--- which could be in /etc/aliases to a list
    postmaster@xyz.com:    adminteam@vendor.xyz       <--- specific destination
    @xyz.com:              %1@customer2.server.com    <--- route everything else to another host`

Your /etc/aliases file is really for setting up simple destinations from one user to another or from one user to a group of other users:

    root:       sa@system.com           <--- route all root mail to sysadmin
    sales:      jdoe,mdoe,sone,mike@somewhere.com,sally@elsewhere.com  <-- to a list
    nobody:     /dev/null               <--- anything sent to "nobody" disappears forever

Aliases is not very good at handling multiple domains, on the other hand virtusertable is very good at it.

You will need to set up your MX records appropriate, etc.

Cheers, David

TekOps
  • 61
  • 4