On Thu, Jul 15, 2010 at 15:19, Victor Duchovni <victor.ducho...@morganstanley.com> wrote: > On Thu, Jul 15, 2010 at 02:45:10PM -0400, Phil Howard wrote: > >> > This is all documented Phil, please read more carefully, and if not sure >> > what something means, test your understanding in a test configuration that >> > does not handle live mail traffic. >> >> Fortunately I have that test machine, now. I've now tried both ways >> with a limited set of addresses hand coded (not the full set of data). >> It works exactly the same either way. I'm working on recoding the >> script that generates the maps. To split the domains between these >> two maps, it has to look at whether there are real mailboxes for a >> domain or not. Basically, the mailbox data will dictate what goes in >> virtual_mailbox_domains. But for virtual_alias_domains, derived from >> the forwarding data, it has to exclude the domains that have >> mailboxes. > > I am reluctant to recommend an approach where domains automatically > morph between virtual mailbox domains and virtual alias domains > based on transient surveys for the presence of non-forwarded mailboxes. > > The distinction between the two address classes should be a *design* > decision, that is made or changed by intent rather than circumstance.
It is a design decision. It's just that the information about it is not recorded in the data the script will be building from. > If you don't know in advance whether a domain may or may not host > mailboxes, then assume it will, and virtual mailbox domains for > all domains. There is nothing wrong with a virtual mailbox domain, > that has no mailboxes "yet", so long as the possibility to have them > later is a requirement. > > You are working too hard if you are trying to "optimize" mailbox > domains to alias domains when there are not yet any mailboxes. I *know* certain domains will never have mailboxes. However, if things work fine (and they do seem to) by assuming "they may have mailboxes some day in the future but just don't, yet", then that really would simplify things. I wasn't trying to do this to optimize ... I have no idea what is optimal in Postfix. Instead, I was trying to be "correct" without knowing for sure what was correct (initially). Actually, my script would be noticeably slower to separate the domains. It's simpler to put them all in virtual_mailbox_domains by concatenating all the domains from my mailbox password data and all the domains from my forwarding data (which can have domains from both sets) and piping that through "sort -u". By "correct" above, I mean semantically, not methodically. Methodically, it all looks identical (mail comes in, domain lookup is done, it gets OK from virtual_mailbox_domains ... BUT ... virtual_alias_maps rewrites it to something else ... before or after I don't know ... mail goes on to its final destination). A case of unknown user part, this may cause the wrong message. I don't know if I need to be concerned with that, or not. If not, virtual_mailbox_domains should suffice. It's kind of like some web design issues. There's a "right" way if you listen to the "semantic web" people, but many ways actually work. The problem is, some of the many ways that work may not do so in the future. Or it's like using undefined aspects of C programming known to always work fine on x86. Maybe they won't in x86_64 or PPC. -- sHiFt HaPpEnS!
