Craig R Hughes wrote: > SA when it was > first built was not expecting to be used in a detached-daemon > environment where > its stderr was disconnected -- so when we disconnect it in spamd, it's > only > polite to let SA continue to communicate with the outside world > (unless the user > specifically tells it not to by modifying syslog to drop the > messages). >
Ok, how 'bout, spamd, being a client of SA, ought to be able to control SA's output? From this modular, decoupled design perspective, SA should provide a hook through which clients such as spamd could get reports - to do with them as they wish. It's up to spamd whether it wants to be "polite," and use the reports (whether received by capturing stderr, or a hook), and spamd could have switches so the user could tell it what to do in this regard. Bryan -- Labor exploitation hurts us all - Sign the petition: http://www.zazona.com/h1bpetition/P/facts.html Proud ugly web site owner: http://www.wecs.com http://www.wecs.com/bio_ailinks.htm; http://www.wecs.com/spam.htm http://www.wecs.com/resume.htm _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
