[AMaViS-user] Setting up DKIM mail signing and verification - expanded documentation

[Quanah Gibson-Mount]

Hi Mark,

Continuing the thread again. ;)  Is it possible to get a patch for Amavisd 
2.8.0 that fixes @disclaimer_options_bysender_maps to work with LDAP with 
large domains?  You once said it should be fairly simple to do.  We've 
moved on to using OpenDKIM for signing since it supports doing everything 
via LDAP, so we no longer have a dire need of that functionality from 
Amavis.  However, supporting a scalable solution with altermime remains 
high on our list and we were hoping to roll it out in the next Zimbra 
release and the timeframe for that is narrowing.

Thanks,
Quanah

--On Tuesday, July 19, 2011 5:06 PM -0700 Quanah Gibson-Mount 
<quanah at zimbra.com> wrote:

> Hi Mark,
>
> Continuing an old thread....
>
> --On Thursday, December 11, 2008 7:21 PM +0100 Mark Martinec
> <Mark.Martinec+amavis at ijs.si> wrote:
>
>> Quanah,
>>
>>> This is a great update, thanks!
>>> I have a few questions in general though with Amavis and DKIM signing.
>>> Right now, it seems amavis needs a reload any time a new domain is
>>> added.
>>
>> Right.
>>
>>> That might be fine for a small site, but we offer a hosted solution
>>> where we will be dealing with some 10,000+ domains.  What we'd like to
>>> be able to do is to add signing for domains without having to reload
>>> amavis.
>>
>> I'll have to consider this. Currently all keys are loaded at startup time
>> by a parent process,  and no files (for config, keys, lookups, ...) are
>> read afterwards. This helps with stability of a running amavisd and
>> with security (private keys not readable after dropping privileges).
>>
>> To deal with 10k dynamic domains this approch seems impractical.
>> I'm afraid the change would be too large to fit into 2.6.2,
>> so I'll deal with it after a 2.6.2 release.
>>
>> Would it be practical to store a signing key (in PEM format) in LDAP,
>> or is it too risky, and storing a file name would be preferred
>> (filename within a fixed directory)? Finding the most appropriate
>> signing key is quite elaborate now (two level: known set of
>> available signing keys, and complicated by preferences in
>> @dkim_signature_options_bysender_maps), so this would have to
>> translate into LDAP lookups somehow, probably in a simplified
>> (less flexible) manner.
>
>
> I thought this was going to be done for 2.7.  However, in looking at it,
> it
> does not appear this is the case.  I certainly see no schema attributes in
> the updated LDAP.schema/LDAP.ldif file for this.    It looks to me like
> the
> 10k domains scenario across multiple amavisd servers is just as
> impractical
> now as it was under 2.6?
>
> per amavisd itself:
>
># Store a private DKIM signing key for a given domain and selector.
># The argument $key can be a Mail::DKIM::PrivateKey object or a file
># name containing a key in a PEM format (e.g. as generated by openssl).
># For compatibility with dkim_milter the signing domain can include a '*'
># as a wildcard - this is not recommended as this way amavisd could produce
># signatures which have no corresponding public key published in DNS.
># The proper way is to have one dkim_key entry for each published DNS RR.
># Optional arguments can provide additional information about the resource
># record (RR) of a public key, i.e. its options according to RFC 4871.
># The subroutine is typically called from a configuration file, once for
># each signing key available.
>#
>
>
> This does not appear to have any type of LDAP support. :/
>
>>> Another thing we want to be able to do is add a disclaimer on a
>>> per-domain basis with altermime, without having to restart amavis all
>>> the time, or to maintain the very large configuration array.
>>
>> It would be fairly trivial to add a LDAP (or SQL) attribute to
>> @disclaimer_options_bysender_maps, so the replacement of the _OPTIONS_
>> placeholder in @altermime_args_disclaimer could be made dynamic.
>> It would involve adding a LDAP attribute to the schema, adding LDAP
>> attribute name to @ldap_attrs list in package Amavis::Lookup::LDAP,
>> and adding a corresponding 'unshift' in sub process_request.
>>
>>> Would it be possible to extend amavis to pull this sort of information
>>> from a database such as LDAP or mysql, rather than using the hard coded
>>> arrays it does now?
>>
>> For @disclaimer_options_bysender_maps yes.  For fetching
>> signing keys it would require considering the best approach.
>
>
> This doesn't look like it was implemented either?


--

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