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. 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. What has been saved is the heavy overhead of perl startup and compiling the basic system rules. 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. 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. Advances in how perl deals with all this will change the balance. I don't believe there is a 'one size fits all'. That's very much a simplistic approach typical of the way Microsoft delivers, never mind what they actually market. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org