[AMaViS-user] Setting up DKIM mail signing and verification - expanded documentation
quanah at zimbra.com
Wed Jul 20 02:06:33 CEST 2011
Continuing an old thread....
--On Thursday, December 11, 2008 7:21 PM +0100 Mark Martinec
<Mark.Martinec+amavis at ijs.si> wrote:
>> 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.
>> 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?
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
More information about the amavis-users