Extending amavisd-new - patching, hooks, etc... How should we do this?

[Tom Johnson via amavis-users]

Hi Mark and List-

I'm playing around with an idea to expand white and blacklisting - allowing things similar to the spamassassin whitelist_from_ dkim, blacklisting unless the sender's mail server used TLS, etc. - In other words, adding some checks to the wblist code.   I'd then like to change the category for the quarantined mail, so mail that failed dkim could be displayed in a quarantine differently from mail that was simply blacklisted, for example.

I'd also like to pull dkim signing keys from a database, and do a few other things that will better help us support a huge number of different domains. 

I can see a couple ways I can do this, and I'd love your feedback.  I figure I can :


 1.  Just use custom hooks.  We'd have to jump thru more hooks, though.   But it means the easiest update path when you come out with new additions. 


  2.  Monkey patch the existing code - replacing the code that retrieved a dkim signing key, for example (although, honestly, while I know how to do something like that with Python, I've no idea how to do it in perl - if there's a way to replace a variable or a function call in an internal amavisd module with a bit of code included from, say, a config file. )

3. Patch amavisd-new itself.  This would be most efficient, but I hate having to re-patch every new version you do, and worrying about incompatibilities that night crop up.  Of course, if you were interested in the patches for possible inclusion into the core software, we would be happy to share them. 

What's your suggestion?  If you're interested in the general ideas we're thinking about, I can elaborate further, if you want to consider adding the features to the core amavisd-new.   

Writing this out also makes me think that we could accomplish a lot more if perhaps there were some additional custom hooks in a few different places  - such as one somewhere around where we would go retrieving dkim keys from a database, so the rest if your signing code could use them.

And maybe some way to add additional categories, and a more standard way of configuring things to add different *_by_ccat categories and associated quarantine types, delivery methods, subject maps, etcetera, so a post-filtering hook could further categorize a message and have the standard code handle notifications, quarantine, delivery, etcetera.  

Here's an example: I have some users who want to say "only accept mail from this domain of the server connected via tls".  This strikes me as a variation on wblisting - an entry in the wblist table that tells our code to blacklist only if there was no tls - abut of "blacklist if (condition)" logic.   It would be great to then give it a different category or subcategory so that we could display it in a different tab in our quarantine.  Or notify the recipient and/or admin when it happens.  I could see doing all this in a big custom hook, but it would be a lot cleaner if I had a hook that let me just set a major or minor ccat, and had everything was handled by your incredible base code.  Maybe this is already possible, and I'm just missing something.  

Hence my query to you - what's the best way to do this? And do you think this is of general interest to the community?  

Thanks-

Tom