Discussion:
Domains issue
(too old to reply)
Quanah Gibson-Mount
2016-03-23 17:23:15 UTC
Permalink
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?

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
Quanah Gibson-Mount
2016-03-23 17:27:26 UTC
Permalink
--On Wednesday, March 23, 2016 11:23 AM -0700 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
In dealing with a problem with disclaimers, I noticed that amavis is not
$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
Dino Edwards
2016-03-23 17:40:53 UTC
Permalink
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-
Quanah Gibson-Mount
Sent: Wednesday, March 23, 2016 1:27 PM
Subject: Re: Domains issue
--On Wednesday, March 23, 2016 11:23 AM -0700 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
In dealing with a problem with disclaimers, I noticed that amavis is
$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
Quanah Gibson-Mount
2016-03-23 18:08:21 UTC
Permalink
--On Wednesday, March 23, 2016 6:40 PM +0000 Dino Edwards
Post by Dino Edwards
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.
Hash files don't scale well across multiple servers, nor does it scale well
for on-the-fly changes. LDAP is highly performant, and not somethign I
worry about. There's a reason I personally don't use SQL for things like
this. I put it out there so that feature parity is maintained.

--Quanah
Post by Dino Edwards
-----Original Message-----
From: amavis-users [mailto:amavis-users-
Quanah Gibson-Mount
Sent: Wednesday, March 23, 2016 1:27 PM
Subject: Re: Domains issue
--On Wednesday, March 23, 2016 11:23 AM -0700 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
In dealing with a problem with disclaimers, I noticed that amavis is
not really optimized for multi-domain installations. In the conf file
$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
--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
Patrick Ben Koetter
2016-03-23 21:38:04 UTC
Permalink
Post by Quanah Gibson-Mount
In dealing with a problem with disclaimers, I noticed that amavis is
not really optimized for multi-domain installations. In the conf
$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?
@local_domains_maps serves to identify if a messages recipient is local.
If you configure SQL or LDAP amavis looks up every recipient address in these
backends automatically. If the address is found the recipient is considered
local automatically.

Is there any other use case you would need the domain for?

***@rick
--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Quanah Gibson-Mount
2016-03-23 22:26:26 UTC
Permalink
--On Wednesday, March 23, 2016 11:38 PM +0100 Patrick Ben Koetter
Post by Patrick Ben Koetter
@local_domains_maps serves to identify if a messages recipient is local.
If you configure SQL or LDAP amavis looks up every recipient address in
these backends automatically. If the address is found the recipient is
considered local automatically.
Is there any other use case you would need the domain for?
The general problem I'm having is with multiple domains and disclaimers.
But your reply makes me think perhaps I can work around the problem I'm
having. Right now, $mydomains is empty because it can't handle multiple
domains. Then local_domains_maps becomes:

(["."])

which treats /everything/ as a local domain. When I then flip on the bit
for adding disclaimers to non-local recipients, it never gets added,
because all domains are considered local. I think I'll try having it set
to undef instead. ;)

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
Quanah Gibson-Mount
2016-03-23 22:29:21 UTC
Permalink
--On Wednesday, March 23, 2016 4:26 PM -0700 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
--On Wednesday, March 23, 2016 11:38 PM +0100 Patrick Ben Koetter
Post by Patrick Ben Koetter
@local_domains_maps serves to identify if a messages recipient is local.
If you configure SQL or LDAP amavis looks up every recipient address in
these backends automatically. If the address is found the recipient is
considered local automatically.
Is there any other use case you would need the domain for?
The general problem I'm having is with multiple domains and disclaimers.
But your reply makes me think perhaps I can work around the problem I'm
having. Right now, $mydomains is empty because it can't handle multiple
(["."])
which treats /everything/ as a local domain. When I then flip on the bit
for adding disclaimers to non-local recipients, it never gets added,
because all domains are considered local. I think I'll try having it set
to undef instead. ;)
And boom, that resolved my problem. Sweet! So never mind on any of this.
:)

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc

Loading...