amavis-user March 2012 archive
Main Archive Page > Month Archives  > amavis-user archives
amavis-user: Re: Website suggestion, 2.8.0-pre4

Re: Website suggestion, 2.8.0-pre4

From: Quanah Gibson-Mount <quanah_at_nospam>
Date: Sat Mar 10 2012 - 02:11:42 GMT
To: Mark Martinec <>,

--On Saturday, March 10, 2012 2:32 AM +0100 Mark Martinec
<> wrote:

> /dev/rob0,
>> A suggestion (or maybe it is there and I missed it): a files/ or
>> download/ directory to make it easier to browse/find files for
>> download.
> I need to clean that directory before opening it up, contains
> plenty of intermediate, experimental and dedicated versions
> and is unsightly :)
>> Is amavisd-new-2.8.0-pre3.tar.gz still the most recent prerelease
>> version?
> I just wrapped a amavisd-new-2.8.0-pre4 and added a link to it
> to a News section on the amavis web page:
> The 2.8.0-pre4 should be compatible with 2.8.0-pre3 as well as
> with 2.7.0. Compared to -pre3 it contains some bug fixes,
> plus a support for 0MQ (a.k.a. ZeroMQ or ZMQ) message passing
> library ( ).
> The 0MQ can replace the use of BerkeleyDB for SNMP monitoring,
> for child process status monitoring (nanny), and perhaps logging.
> Its main advantage over BerkeleyDB is that it avoids the problem
> of lock contention on database updates, which can have significant
> impact when a number of busy child processes is large. An additional
> benefit is that monitoring can be done on a separate host, with
> a potential for easier monitoring of multiple hosts running amavisd.
> There are no immediate plans to remove BerkeleyDB, both choices
> will exist for some time, but one or the other can be disabled.

Hi Marc,

A few questions/comments on 2.8.0-pre4. :)

1) avoid persistent connections to SQL and LDAP servers - at the expense
  of about 3 to 7 ms elapsed time for a reconnect; persistent connections
  from mostly idling child processes unnecessarily consume database server
  resources (e.g. a TCP socket) and may become stuck when some intermediate
  stateful device like a firewall or a NAT decides to drop stale sessions;
  reported by Jernej Porenta;

 Can this be made optional? A well written LDAP server is designed to
handle persistent connections. I don't know what Jernej was using, but
apparently it wasn't well designed. In any case, well designed LDAP
servers also allow you to set a server-side timeout if you really don't
want idle connections sitting about.

2) I see you did some work on the Amavis portions. Will a scalable LDAP
solution be supported as previously discussed? See discussion from



-- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration