So wouldn't this work better? @local_domains_maps=(read_hash("/etc/postfix/relay_domains"));
I know it's not an LDAP or SQL query, but a little easier to manage. I'm thinking with an LDAP or MySQL query especially with a large number of domain it may become a performance issue? I know I've seen it mentioned numerous times in the postfix mailing list where the they are very against SQL queries and always recommend hash files because of performance considerations. > -----Original Message----- > From: amavis-users [mailto:amavis-users- > bounces+dino.edwards=mydirectmail....@amavis.org] On Behalf Of > Quanah Gibson-Mount > Sent: Wednesday, March 23, 2016 1:27 PM > To: amavis-users@amavis.org > Subject: Re: Domains issue > > --On Wednesday, March 23, 2016 11:23 AM -0700 Quanah Gibson-Mount > <qua...@zimbra.com> wrote: > > > In dealing with a problem with disclaimers, I noticed that amavis is > > not really optimized for multi-domain installations. In the conf file I > > find: > > > > $mydomain = 'example.com'; # a convenient default for other settings > > > > and > > > > @local_domains_maps = ( [".$mydomain"] ); # list of all local domains > > > > > > While this probably is fine for most installations, we have customers > > who anywhere from one domain to > 1500 domains. This becomes > > problematic in particular when disclaimers are in use. Clearly, I can > > modify the conf file as necessary, but it'd be great if I could have > > amavis actually pull my domains out of LDAP, for example, so I didn't > > have to hack the conf file at all. Has there been thought on > > implementing something along these lines? I.e., a generic database > > mechanism, so LDAP, SQL, etc, can be used for pulling in the domain list? > > Note that this would allow for real-time updates to domains considered local, > w/o having to restart amavis, if implemented properly. > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration A division of > Synacor, Inc