Anton Aylward wrote:
On 08/23/2014 11:06 AM, Per Jessen wrote:
Anton Aylward wrote:
On 08/23/2014 04:51 AM, Per Jessen wrote:
Same with SA - just add/remove rules such as:
whitelist_from whitelist_from_rcvd whitelist_from_dkim whitelist_from_spf
Yes I have a couple of those but the use-case example have it in the SA config and not a end-user maintainable text file.
FYI, spamd is perfectly capable of using rules from an end-user home directory.
*sigh*
Please: I'm not saying that isn't so.
Your last paragraph above sounds like that's what you thought when you wrote it. You seem to be saying that "the SA config" is not an end-user maintainable text file. I just wanted to say that it can be. Sorry if I've misunderstood.
What I am saying is that if you run spamd then it starts perl when you start the daemon, reads the application (and compiles it if you haven't precompiled it), reads the system rules (and compiles them if you haven't precompiled the) and sits waiting.
It is a shared resouce and is not at this point reading the per user config. As I understand it, when you run spamc what happens is that spamd forks off a child process to deal with the per user, per message processing. That child reads the per user setting of which you speak. It reads them and compiles them.
Right.
What has been saved is the heavy overhead of perl startup and compiling the basic system rules.
Yup.
Whether you consider this 'dynamically reading the whitelist' or not depends on your outlook. I think it involves more than the formail/egrep, but that's my opinion.
It quite clearly is 'dynamically reading the whitelist'. The per-user config containing the whitelist directives is read by the spawned spamd child, dynamically. Whether it involves more or less than formail/grep is, well, irrelevant. I mean, we can discuss spamassassin performance if you want, but it means doing the measurements, comparing rulesets etc, and I'm simply not really concerned about it. I'm sure my SA setup can be tuned and pimped, but as long as it runs very well on these ancient Pentium IIs, it's just not a priority.
As I say, all this forking, exec'ing, loading the whitelist code, compiling same, etc is going to vary with they type (as well as the speed) of the CPU.
Sure, a faster CPU will do those bits faster. -- Per Jessen, Zürich (16.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org