On 5/4/20 3:59 PM, Martin Gregorie wrote:
The list of such passwords might get rather long, so using a database both makes maintenance easier, as you spotted, and also keeps a lot of junk out of the rule sets.
I absolutely agree. I like the idea of keeping data outside of configuration files.
One Perl module and one or two rules triggering it seem a lot easier to maintain than a whole heap of rules containing unreadable junk but of course ymmv unless, of course you write code to autogenerate the rules, but it still sounds like a good way to inflate the ruleset to no good purpose.
Agreed.I think $DatabaseTechnology's main benefit is keeping the password data outside of the configuration files.
As I write this, I may have thought of another idea.
However, I've long realised that not everybody is as keen on databases as I am.
I have absolutely nothing wrong with a database per say. I just want to make sure that it's the proper thing and that the proper type of database is used for a given need.
select count(*) where log.key = md5(key);You can move the md5 generation into the SQL server. Of course, you'd want to be mindful of the communications channel between SpamAssassin and the SQL server.
I'm not sure how to have SpamAssassin iterate all the words in the message through this routine.
If it requires a custom SpamAssassin module, then it might be better to do calculate the MD5 hash in SpamAssassin and avoid the security implications between SpamAssassin and SQL server.
Yep, not really a serious suggestion.
;-) -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
