On Tue, Apr 10, 2012 at 08:10:52AM -0400, btb wrote: > On 2012.04.09 23.32, Viktor Dukhovni wrote: > >On Mon, Apr 09, 2012 at 10:21:05PM -0400, [email protected] wrote: > > > >>Given my understanding of address classes, it seemed that in > >>order to use virtual_alias_maps, those related domains would need > >>to be listed in virtual_alias_domains. > > > >This assumption is incorrect. All recipients, regardless of > >address class are subject to virtual(5) rewriting. > > so the relationship between virtual_alias_maps/ > virtual_alias_domains is not quite the same as the relationship > between virtual_mailbox_maps/virtual_mailbox_domains or > relay_recipients/relay_domains? > > meaning- iiuc, in order for virtual_milbox_maps to be used for a > given domain, the domain needs to be listed in > virtual_mailbox_domains, and the same concept for the relay domain > class. is this right? > > whereas with virtual_alias_maps, this is always used, regardless > of if a given domain is listed in virtual_alias_domains -
Yes. > and, putting the given domain in virtual_alias_domains serves > not to allow virtual_alias_maps to work, but rather to preclude > the given domain from being in some other address class [i.e. to > isolate the domain as *only* a virtual alias domain]? That's one effect. Another effect is that the virtual_alias_maps expansion is constrained such that the final result must be an address which is *not* in virtual_alias_domains. myorigin = example.com virtual_alias_domains = example.com[, ...] virtual_alias_maps include: [email protected] btb Now, mail to [email protected] is rejected with "User unknown in virtual alias table." -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
