On Mon, Nov 30, 2015 at 04:11:15PM -0800, Quanah Gibson-Mount wrote:

> >Duplicates arise when multiple lists have common recipients, and
> >whether these lead to multiple deliveries or not depends mostly on
> >enable_original_recipient.
> 
> That's not really what we're seeing.  What we are seeing is:
> 
> A list has 51 or more members (users1 through users55)
> 
> One of those list members sets their email to forward somewhere else (local
> or remote, doesn't matter) (say, user50 forwards to user70).

That is two lists with common members, one list is user50 (expands
to user70), the other list is user70 (no expansion).  Your real
problem however is the self-referencing user50:

    user50: user70, user50

If you expand this twice, you get:

        user50 -> user70, user50 ----> user70, user50
                    \
                     ----------------> user70

Hence the duplication.  At the second hop, the two expansions have
different original recipient values.  This is why FILTER_README
describes doing virtual expansion either before or after the filter,
but not both.

I usually solve this differently.  I avoid self-referential
expansions!

    virtual:
        use...@example.com      
                use...@mailstore-name.example.com,
                use...@mailstore-name.example.com,

That is, I ensured that the input keys for virtual aliases are
*always* in virtual alias domains (this is not required, but a good
idea).  And the outputs are *never* in virtual alias domains.  I
used LDAP with a "domain = example.com" setting to not even bother
to do lookups on the output domains (big latency saving since
virtual alias expansion is recursive).

I had an environment with multiple mailstores under a single virtual
domain.  Multiple Microsoft Exchange deployments, some IMAP
mailstores, and some cloud mailstores.  All expansions were:

        mail -> maildrop

not

        mail -> mail

The domainpart of "mail" was always a virtual alias domain.  The
domainpart of "maildrop" is always the routing information to the
user's mailstore.  The transport table was per maildrop domain,
not per user.

-- 
        Viktor.

Reply via email to