Prev: private/smtp-amavis: No such file or directory helps for master.cf
Next: private restriction class is ignored
From: Victor Duchovni on 15 Jul 2010 14:17
On Wed, Jul 14, 2010 at 06:38:17PM -0400, Wietse Venema wrote:

> Phil Howard:
> > Every address in these domains will be rewritten to some other address
> > (not all with the same domain) and sent on their way. Some of them
> > will be rewritten to addresses that do fall into other classes for
> > some kind of local delivery (right now, in virtual mailbox).
>
> You give pretty much the definition of a Postfix virtual alias
> domain.
>
> All addresses are rewritten to an address in a different local or
> remote domain, therefore, the domain must be listed as a virtual
> alias domain, as per ADDRESS_CLASS_README.html.
>

He mentioned "not all witht the same domain", which is not entirely
clear. I read it to mean that some of the rewrites are to different
local-parts, but with the domain unmodified. In that case, and especially
if this is followed by virtual mailbox delivery, the domain is a
virtual_mailbox_domain with partial forwarding.

If what the phrase meant was that there are multiple target domains
into which the original domain is rewritten, but no addresses stay
in the original domain, then it is a virtual alias domain.

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.

--
Viktor.

From: Phil Howard on 15 Jul 2010 14:45
On Thu, Jul 15, 2010 at 14:17, Victor Duchovni
<Victor.Duchovni(a)morganstanley.com> wrote:
> On Wed, Jul 14, 2010 at 06:38:17PM -0400, Wietse Venema wrote:
>
>> Phil Howard:
>> > Every address in these domains will be rewritten to some other address
>> > (not all with the same domain) and sent on their way.  Some of them
>> > will be rewritten to addresses that do fall into other classes for
>> > some kind of local delivery (right now, in virtual mailbox).
>>
>> You give pretty much the definition of a Postfix virtual alias
>> domain.
>>
>> All addresses are rewritten to an address in a different local or
>> remote domain, therefore, the domain must be listed as a virtual
>> alias domain, as per ADDRESS_CLASS_README.html.
>>
>
> He mentioned "not all witht the same domain", which is not entirely
> clear. I read it to mean that some of the rewrites are to different
> local-parts, but with the domain unmodified. In that case, and especially
> if this is followed by virtual mailbox delivery, the domain is a
> virtual_mailbox_domain with partial forwarding.
>
> If what the phrase meant was that there are multiple target domains
> into which the original domain is rewritten, but no addresses stay
> in the original domain, then it is a virtual alias domain.

I think this is what it is.


> 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.

--
sHiFt HaPpEnS!

From: Victor Duchovni on 15 Jul 2010 15:19
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.

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.

--
Viktor.

From: Phil Howard on 15 Jul 2010 16:44
On Thu, Jul 15, 2010 at 15:19, Victor Duchovni
<Victor.Duchovni(a)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!

From: Victor Duchovni on 15 Jul 2010 17:13
On Thu, Jul 15, 2010 at 04:44:00PM -0400, Phil Howard wrote:

> > 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.

You can make these virtual alias domains, but if you make them
virtual mailbox domains with no mailboxes, the difference will
be rather small. Instead of the queue manager routing the mail
of non-existing users directly to the error transport, they'll
be routed to the virtual(8) transport, which will bounce them
instead. Since smtpd(8) rejects non-existing users (when not
misconfigured), the different internal logic has little
practical impact.

> 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.

If you have a lot of domains to manage, you can make do with
virtual mailbox domains as a sensible default.

You need separate tables for virtual aliases and virtual mailboxes
regardless of which designation you choose, all that changes
is the contents of virtual_mailbox_domains vs. virtual_alias_domains.

--
Viktor.

First  |  Prev  | 
Pages: 1 2 3 4
Prev: private/smtp-amavis: No such file or directory helps for master.cf
Next: private restriction class is ignored