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

[Quanah Gibson-Mount]

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?

Thanks,
Quanah

--

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