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. > 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. Michael, > You do know you can set up named pipes for the files, and have the backend > be a perl script that read the database, right? I wonder if that would help > (or does amavisd still need the reload, and yes, reloading it every time > does mess up things on large sites.. Any email that is in the middle of > being deliver through amavisd gets delayed for 'rescan time' with a entry > in the mta queue) > > So, mark, if the 'file' was a named pipe, does amavis call that named pipe > only upon restart, or would it call it (eventually) when a new amavisd > child was spawned? Currently, as a matter of principle, child processes never open and read files (except the mail they are dealing with), so this approach is not a viable solution. There is one trick of using a Perl 'tie' to associate a hash (associative array) with a database file, so when amavisd would do a lookup on a hash this would translate into a database lookup on a file, but it works only for scalar results. I don't think it can help with choosing and fetching DKIM keys without changing approach more radically. Mark ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
