Bryan Hoover wrote: BH> Craig R Hughes wrote: BH> BH> > SA when it was BH> > first built was not expecting to be used in a detached-daemon BH> > environment where BH> > its stderr was disconnected -- so when we disconnect it in spamd, it's BH> > only BH> > polite to let SA continue to communicate with the outside world BH> > (unless the user BH> > specifically tells it not to by modifying syslog to drop the BH> > messages). BH> > BH> BH> Ok, how 'bout, spamd, being a client of SA, ought to be able to control BH> SA's output? From this modular, decoupled design perspective, SA should BH> provide a hook through which clients such as spamd could get reports - BH> to do with them as they wish. It's up to spamd whether it wants to be BH> "polite," and use the reports (whether received by capturing stderr, or BH> a hook), and spamd could have switches so the user could tell it what to BH> do in this regard.
Spamd is not a client of SA, it's a client of spamd, through the well-define SPAMD/SPAMC protocol. Your web browser doesn't report the log messages of every web server you visit, does it? C _______________________________________________________________ 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