Michael,
> do you have documentation on the pure-amavisd solution?
No documentation yet, but here is an example of a DKIM-signing
policy I have currently - it uses the usual lookups provisions,
but only the tables which can provide structured results are
useful, which means a hash or a regexp -type of a lookup table
(no SQL or list lookups).
The result of a lookup is a hash (a set) of DKIM signing attributes,
i.e. canonicalization method, hashing algorithm, domain, identity,
selector, expiration time and the private key. Something like the
following can go into amavisd.conf, missing attributes fall back
to more general settings (or have a built-in default).
If a lookup does not find a key, d, and s attributes, no signing
takes place. Also, only mail with 'originating' flag are eligible
for signing. A lookup is based on either the From, the Sender
(both form a header), or on a mail_from address from the envelope,
whichever yields a useful result first. This results either in an
originator signature (based on From), or a third-party signature
(based on Sender or mail_from).
@dkim_signing_options_bysender_maps = ( # a list of lookup tables
{ # a hash-type lookup table, results are sets of attributes,
# missing attributes are looked up on a next more general match
'[EMAIL PROTECTED]' =>
{ i = '[EMAIL PROTECTED]' },
'.example.com' =>
{ s => 'sel2007', d => 'example.com',
key => loadkey('/var/db/dkim/sel2007-ex.c.key.pem'),
},
'.example.org' =>
{ s => 'test', # missing d comes from a key, e.g. sub.example.org
key => loadkey('/var/db/dkim/foo234.key.pem'),
},
'.ijs.si' =>
{ s => 'jakla2', d => 'ijs.si',
dx => 30*24*3600, # relative expiration time
key => loadkey('/var/db/dkim/jakla2.key.pem'),
},
'.' => # fallback for missing attributes
{ c => 'relaxed/simple', a => 'rsa-sha256' },
} );
Details are still subject to change.
DKIM verification is done for all mail (it is now significantly faster
with my contribution to Mail::DKIM 0.30, no reason to conditionalize it),
results are available for further decision making, or can end up in
notifications and logging. Whitelisting based on DKIM identity is still
on a to-do list, conceptually should follow the whitelist_from_dkim
semantics from a SpamAssassin DKIM plugin, i.e. matches on From and identity,
syntax is still a puzzle.
Mark
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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/